| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-05 | |||
| 17:37:55 | cdent | https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/resource_provider.py#L110 | |
| 17:38:15 | cdent | and the api_ref is set up to list anything, not just the top level things | |
| 17:38:25 | jaypipes | cdent: since when? | |
| 17:38:30 | cdent | since the dawn | |
| 17:38:36 | cdent | we have made expections in the past | |
| 17:38:44 | jaypipes | cdent: why bother having the top-level element at all then? that's just silly IMHO | |
| 17:39:06 | jaypipes | cdent: with no indication of the "level" the attribute is expected to appear at | |
| 17:39:07 | cdent | don’t look at me man, I think the rules on the api-ref are … weird | |
| 17:40:02 | cdent | there has been work done in the nova api-ref (I think?) to indicate path.to.attribute but we’ve not picked it up in placement | |
| 17:41:02 | jaypipes | meh, screw it, I'll just make the damn changes (again, again) | |
| 17:41:28 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 17:42:11 | cdent | jaypipes: I think the descending paths thing was worked on near: https://review.openstack.org/#/c/464277/ but I’m not sure if it got anywhere | |
| 17:42:29 | jaypipes | cdent: so is Takashi asking me to put a required: true line in for parent_provider_uuid/root_provider_uuid but only in the response parameter listings? | |
| 17:43:55 | cdent | my read was that he wants the response body to be fully described and the usual way to do that in the case when it is optional is the request body is to inherit the yaml anchor and changed required: false to true | |
| 17:44:34 | cdent | jaypipes: I think it would probably be okay to punt it to a followup (one that perhaps someone else did) | |
| 17:45:09 | jaypipes | cdent: I just don't know what is being asked of me. | |
| 17:45:11 | cdent | jaypipes: the reasons require: true isn’t marked on those guys is because required is the default, isn’t it? | |
| 17:45:45 | cdent | in that case I’d say let’s punt and do it in a followup so it can be looked at separately and more clearly understood | |
| 17:45:57 | jaypipes | cdent: I think he's saying that the *response* always has parent_provider_uuid and therefore the *response* parameter list should have required: true. | |
| 17:46:04 | cdent | my brain is not in that frame right now so can’t tell you something clear and straightforward | |
| 17:46:23 | cdent | effectively yes | |
| 17:47:30 | cdent | I’ve changed my vote for now, in case that helps move things along | |
| 17:49:46 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 17:49:47 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 17:49:47 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 17:49:48 | openstackgerrit | Jay Pipes proposed openstack/nova master: Scheduler set_inventory_for_provider does nested https://review.openstack.org/520643 | |
| 17:49:48 | openstackgerrit | Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_tree https://review.openstack.org/520663 | |
| 17:49:49 | openstackgerrit | Jay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097 | |
| 17:49:49 | openstackgerrit | Jay Pipes proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 17:49:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098 | |
| 17:49:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187 | |
| 17:49:51 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 17:52:04 | jaypipes | cdent: would you mind looking at https://review.openstack.org/#/c/377215/ and making sure I've added everything you wanted please? | |
| 17:54:52 | cdent | jaypipes: I think your rebase has gone funk as ps70 has the same stuff as ps62 (in the test file), but there were changes in the middle :( | |
| 17:55:29 | jaypipes | god damn this. | |
| 17:57:18 | jaypipes | I am so fucking sick of this bullshit sliced up and frankensteined set of patches at this point. | |
| 17:58:03 | jaypipes | all this to try and get Eric's WIP patches aligned with what's already been merged. :( | |
| 17:58:36 | edleafe | jaypipes: welcome to my world :) | |
| 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: Modify _poll_shelved_instances periodic task call _shelve_offload_instance() https://review.openstack.org/524047 | |
| 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: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 shelve_offload instances https://review.openstack.org/523653 | |
| 18:48:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add instance action record for backup instances https://review.openstack.org/523676 | |
| 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: Convert ext filesystem resizes to privsep. https://review.openstack.org/517516 | |
| 19:34:57 | openstackgerrit | Michael Still proposed openstack/nova master: Move flushing block devices to privsep. https://review.openstack.org/519010 | |
| 19:34:58 | openstackgerrit | Michael Still proposed openstack/nova master: Start moving users of parted to privsep. https://review.openstack.org/519011 | |
| 19:34:58 | openstackgerrit | Michael Still proposed openstack/nova master: Move remaining uses of parted to privsep. https://review.openstack.org/519483 | |
| 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 | |