Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-05
17:59:03 jaypipes edleafe: how's that? doesn't your series only have like 4 patches in it? are there 7 different branches of that series?
18:00:00 jaypipes cdent: also, it's not ps62. it was fine in ps69 and then ps70 undid all that work :(*
18:01:01 jaypipes clarkb: you had a shortcut for how to essentially revert just the last revision on a series... can you tell me what that was again?
18:01:02 cdent jaypipes: 62 was my reference point as that’s where I made my comments so I compared changes between 62 and 70 and there were none in the test file
18:01:26 jaypipes cdent: look at 69...
18:01:38 edleafe jaypipes: didn't mean to imply that mine was as bad as yours. Just the same set of headaches.
18:01:59 jaypipes edleafe: well, at least you don't have 5 people *actively* pushing stuff in your series.
18:02:05 clarkb jaypipes: `git review -d 123456,1 && git commit --amend #update commit message because gerrit && git review`
18:02:22 cdent jaypipes: yeah, already did, it looks like what I hoped for
18:02:38 clarkb that downloads into a local branch then you edit the commit message so that gerrit doesn't reject it as an existing patchset, then push to gerrit
18:02:39 jaypipes clarkb: ack, thanks
18:04:49 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
18:05:44 jaypipes clarkb: oddly, Gerrit changed the topic of the patch to bp/nested-resource-providers-patch69
18:06:01 clarkb I think that may have been git review being a little too smart
18:06:20 clarkb you can chagne it in the ui if you want (and in the future use git review -t some-topic to override git review)
18:06:21 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
18:06:43 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
18:08:38 jaypipes alex_xu, edleafe, mriedem, dansmith, cdent, bauzas, gibi, melwitt: OK, well if we can focus on getting up to https://review.openstack.org/#/c/385693/ merged, that would be cool. thanks in advance.
18:08:53 cdent ✔
18:14:18 edleafe ✔
18:32:29 mriedem melwitt: jaypipes: ack
18:35:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Add instance action record for shelve_offload instances https://review.openstack.org/523653
18:35:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Modify _poll_shelved_instances periodic task call _shelve_offload_instance() https://review.openstack.org/524047
18:35:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Add instance action record for backup instances https://review.openstack.org/523676
18:48:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add instance action record for backup instances https://review.openstack.org/523676
18:48:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add instance action record for shelve_offload instances https://review.openstack.org/523653
18:53:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add instance action record for backup instances https://review.openstack.org/523676
19:27:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a new check to volume attach https://review.openstack.org/525622
19:31:28 itlinux hello all I wonder if any one can suggest the best way to get sec group disabled.. Thanks
19:34:15 mriedem ildikov: i'm going to update https://review.openstack.org/#/c/330285/169
19:34:52 ildikov mriedem: ok, I hit a rebase issue with it
19:34:57 openstackgerrit Michael Still proposed openstack/nova master: Move flushing block devices to privsep. https://review.openstack.org/519010
19:34:57 openstackgerrit Michael Still proposed openstack/nova master: Convert ext filesystem resizes to privsep. https://review.openstack.org/517516
19:34:58 openstackgerrit Michael Still proposed openstack/nova master: Move remaining uses of parted to privsep. https://review.openstack.org/519483
19:34:58 openstackgerrit Michael Still proposed openstack/nova master: Start moving users of parted to privsep. https://review.openstack.org/519011
19:34:59 openstackgerrit Michael Still proposed openstack/nova master: Convert users of tune2fs to privsep. https://review.openstack.org/519484
19:35:10 mriedem ildikov: yes, and tempest is failing now too, so i'll handle both issues
19:35:11 ildikov mriedem: and not with my laptop for a little while now
19:35:36 ildikov mriedem: I guess Tempest is just because of the revert
19:35:46 ildikov It got landed in the meantime
19:35:55 ildikov mriedem: thank you
19:36:22 ildikov mriedem: and sorry for being a bit unpleasant...
19:40:16 sean-k-mooney2 gus: o/
19:43:48 sean-k-mooney2 gus: QQ if i have two fuctions func1 and func2 and both are decorated as a privsep entrypoint and func1 calls func2 will that dispatch the call to func2 via the unix socket again even though the body of func1 is executing in the privsep deamon process?
19:49:11 sean-k-mooney2 gus: if the privsep entrypoint decorator that was used for func1 and func2 were from a different privsep context im guessing the answer would have to be yes as they may have different capablitys which woudld lead me to belive if they were the same context i would still invoke func2 via the socket.
19:54:44 sean-k-mooney2 mikal: ^^ any input on the above question regarding nested privsep calls?
19:58:19 mikal sean-k-mooney2: huh, we haven't done anything like that. I'm really not sure.
19:58:39 mikal sean-k-mooney2: I guess the decorators aren't magic, and would just apply the contexts in the order the decorators were executed
19:58:56 mikal sean-k-mooney2: and if you didn't get an error from privsep calling itself, then you'd get the context of the innermost call
19:59:09 sean-k-mooney2 mikal: actully we do it in os-vif but i belive its unintentional.
19:59:31 sean-k-mooney2 mikal: i think two decorators were acidentally swapped
20:00:21 sean-k-mooney2 mikal: in the os-vif case both decorators are form the same privsep context so both have the same permissions
20:00:45 mikal Oh, interesting. So its either crash, or work as expected?
20:01:00 sean-k-mooney2 basically i think https://github.com/openstack/os-vif/blob/23c71e083aeb3536c4cf4c46b5c7712b0f7442ee/vif_plug_linux_bridge/linux_net.py#L58 and https://github.com/openstack/os-vif/blob/23c71e083aeb3536c4cf4c46b5c7712b0f7442ee/vif_plug_linux_bridge/linux_net.py#L70 are swapped
20:01:24 sean-k-mooney2 mikal: i think it works as expected but just dispatches twice
20:02:31 sean-k-mooney2 mikal: https://github.com/openstack/os-vif/blob/23c71e083aeb3536c4cf4c46b5c7712b0f7442ee/vif_plug_linux_bridge/linux_net.py#L65 the call to _ensure_bridge_privileged is in a privesep context but _ensure_bridge_privileged is also privaldged
20:06:28 sean-k-mooney2 mikal: im going to try and un nest the calls tomorow but i realised while reviewing https://review.openstack.org/#/c/484386/26/os_vif/privsep.py that the functions that use this new privsep context are only ever invoked form privaldged function in the plugins which have the same capablites CAP_NET_ADMIN
20:07:55 sean-k-mooney2 so 1 that would result in nested context with the same capablites and 2 it would intoduce another instance of the privsep deamon to hanel that context both of which i think are not needed.
20:08:51 sean-k-mooney2 mikal: am im going to head home for the evening but if you have a chance could you take a look and see if it makes sense to intorduce this new privsep context or not?
20:19:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
20:19:40 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
20:21:30 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Allow multi-attach in compute api https://review.openstack.org/271047
20:21:52 mriedem ildikov: i touched up some things in https://review.openstack.org/#/c/267587/ and left some FIXMEs
20:22:57 ildikov Oh, I thought you'll fix up the new attach patch only
20:23:06 mriedem i wanted to rebase the series
20:24:10 ildikov Oh, ok, I left behind the API one on purpose, but will check what you did in a bit :)
20:24:17 ildikov Thanks!!!
20:24:51 ildikov I can look into the Cinder policies and client leftovers too a bit then...
20:41:13 mriedem i'm also going to add unit tests for the new flow to nova.tests.unit.virt.test_block_device in https://review.openstack.org/#/c/330285/170 - we might want to consider splitting out the virt.block_device changes too
20:42:46 mikal mriedem: you had a chance to read my comment on that privsep bug?
20:42:53 mriedem mikal: nope
20:46:03 mikal mriedem: good man. In summary, I have no idea what you people are talking about.
20:46:15 mriedem mikal: that's what you told me yesterday, so ok :)
20:46:32 mikal mriedem: oh, I was expecting you to call me a liar on the bug is all
20:47:04 jaypipes cdent: you have any idea what is causing this tempest.scenario.test_server_multinode.TestServerMultinode.test_schedule_to_all_nodes failure with the "Failed to get resource provider with UUID XXXX" issue that keeps occurring? I think you and efried_cya_wed may have talked aboiut it?
20:47:41 cdent yeah, there’s a bug for it, I’m working on it: https://bugs.launchpad.net/nova/+bug/1736385 basically placement is getting restarted
20:47:42 openstack Launchpad bug 1736385 in grenade "placement is not being properly restarted in grenade (pike to master)" [Undecided,In progress] - Assigned to Chris Dent (cdent)
20:48:11 cdent it’s apparently been a latent problem only exposed because exception handing that efried_cya_wed added
20:48:27 jaypipes cdent: k. is there anything I can do to assist?
20:49:20 cdent I don’t reckon so, the delay has been in getting it to repeat locally, but I’m nearly there, and from there should be able to do some poking
20:49:56 cdent but thanks for offering. If I stall out before the night is over, I’ll dump state on the bug and let you know
20:53:15 jaypipes cdent: k
20:53:33 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
21:12:17 ildikov mriedem: let me know when you had enough and want me to take over and screw up the half thing again before doing anything sane :)
21:13:03 ildikov mriedem: and I owe you a lot, I'm sure we can negotiate, lemme know
21:13:03 mriedem ildikov: i need to fix another functional test, and i'm working on adding the unit test coverage for the new flow changes in test_block_device
21:13:21 mriedem which makes me realize that in the new attach flow in block_device.py, if attachment_complete fails, we don't do any cleanup
21:13:24 mriedem unlike the old flow
21:14:35 ildikov yeah, we moved that around a bit
21:14:43 ildikov so I guess that's why it's uncovered
21:15:32 ildikov the volume is connected though, however the volume state would still be attaching if that call doesn't get to Cinder or fails before the db update
21:20:00 mriedem that's why we handle it in the legacy flow and rollback (terminate the connection and detach the volume so it's "available")
21:22:22 mriedem anyway, i'm just going to leave a note in the code
21:22:37 ildikov I know, was thinking out loud
21:43:13 mriedem we are going to want to break out these block_device.py changes with the unit tests - this gets pretty hairy in the tests
21:43:19 mriedem i'm down to 10 failures
21:45:05 ildikov we should find a superhero name for you
21:45:32 ildikov can do it after my next meeting and breaking out those changes
21:52:28 ildikov and sorry, there were two self.save() calls in the new attach call in block_device.py
21:52:57 ildikov I obviously deleted the wrong duplicate...

Earlier   Later