| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-21 | |||
| 16:51:21 | sean-k-mooney | gibi: that is a neutron api change and would need a neutron spec right | |
| 16:51:36 | gibi | sean-k-mooney: let me check what the neutron spec states about this | |
| 16:52:00 | mriedem | going back to what i said earlier, "here is a thing you can do to create a server, but don't ever touch it after that" :) | |
| 16:52:36 | gibi | sean-k-mooney: neutron spec states it is out of scope too https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html#out-of-scope | |
| 16:52:39 | sean-k-mooney | mriedem: you mean treat your instances like cattel and not pets | |
| 16:52:46 | gibi | sean-k-mooney: I will clarify with rubasov what does it mean | |
| 16:53:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Share snapshot image membership with instance owner https://review.openstack.org/630769 | |
| 16:53:41 | sean-k-mooney | gibi: i had assumed that it would be addressed at some point in the future | |
| 16:53:49 | mriedem | i don't see why disallowing making min bw allocation changes on a bound port is tied up in os-vif migration | |
| 16:53:50 | sean-k-mooney | but yes good to check | |
| 16:54:04 | mriedem | seems like an unnecessary dependency | |
| 16:54:10 | sean-k-mooney | its not | |
| 16:54:11 | gibi | sean-k-mooney: yeah supporting the update is future, but rejecting it to prevent incosystencies might be in the current scope | |
| 16:54:15 | sean-k-mooney | does the spec say that? | |
| 16:54:26 | mriedem | i would think, "don't give users a loaded gun to f up resource tracking in their system" as not a feature | |
| 16:54:33 | mriedem | sean-k-mooney: yes | |
| 16:54:42 | mriedem | "This is out of scope in this spec and should be done during the work related to os-vif migration tasks [5]." | |
| 16:54:57 | gibi | yeah I don't see the reason there too ^^ | |
| 16:55:11 | mriedem | in fact it would a bug in neutron | |
| 16:55:16 | sean-k-mooney | mriedem: it was proably related the use of os-vif for port negociation or something its likely out of date | |
| 16:55:59 | sean-k-mooney | mriedem: again changing qos policy is ment to be allowed in neutron | |
| 16:56:20 | sean-k-mooney | mriedem: and sice min bandwith was best effort before there was noting to validate | |
| 16:56:39 | sean-k-mooney | so the only thing that would have added such a check are these specs | |
| 16:57:09 | mriedem | sure i get it | |
| 16:57:17 | mriedem | in the before times it was the wild west and you get lucky | |
| 16:57:44 | sean-k-mooney | they declared the check/supprot out of scope so i would assume we keep the status quo by default. | |
| 16:57:50 | gibi | sean-k-mooney: I think keeping the resouce view consistent is important enough that this can be reported as a bug agains neutron as soon as nova create/delete support in nova merges | |
| 16:57:53 | mriedem | like mlavalle said on the call on friday, why even go to the trouble of adding placement to this to guarantee minimum bandwidth if we're not going to enforce it and make sure we calculate it properly | |
| 16:58:06 | mriedem | gibi: agree | |
| 16:58:21 | sean-k-mooney | gibi: sure | |
| 16:58:28 | mriedem | if we're going to punt on keeping the system in check, then we shouldn't even add the feature | |
| 16:58:48 | sean-k-mooney | not agruing we should punt | |
| 16:59:20 | mriedem | i have to move on from this | |
| 16:59:39 | sean-k-mooney | jsut taht we had said we would not do it in the spec. if we and to bring it into scope then greate but its another depency for adding support to nova | |
| 16:59:48 | sean-k-mooney | ok | |
| 17:02:09 | gibi | mriedem, sean-k-mooney: thanks for the discussion. talk to you tomorrow | |
| 17:05:04 | cfriesen | sean-k-mooney: am I understanding this right that the "physical_network" name in the pci whitelist will be correlated against the neutron provider network for the passed-in neutron port? | |
| 17:05:53 | sean-k-mooney | cfriesen: it correaltes to the the neutron physenet | |
| 17:07:09 | sean-k-mooney | cfriesen: so yes it corralate to the provider:physical_network in the neutron network object | |
| 17:07:43 | cfriesen | cool, thanks | |
| 17:25:42 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589 | |
| 18:13:47 | sean-k-mooney | hi so quick question. _rollback_live_migration in the compute manager does not currently appear to ever call the virt driver on the source node | |
| 18:14:41 | sean-k-mooney | i assume it would be ok to add a _rollback_live_migration_at_source to the base driver interface that was a noop and implement it for the libvirt driver? | |
| 18:15:27 | sean-k-mooney | we have have rollback_live_migration_at_destination but that dose not help me. | |
| 18:35:34 | cdent | jaypipes: I believe this is for you: http://existentialcomics.com/comic/273 | |
| 18:43:56 | sean-k-mooney | cdent: if only that was the calibar of converstations at a typical bar discussing such matters hehe | |
| 18:44:14 | cdent | i might actually go to bars if that were the case | |
| 18:45:15 | edleafe | sean-k-mooney: I prefer this: http://theincidentaleconomist.com/wordpress/wp-content/uploads/2014/11/sportsball.jpg | |
| 18:47:09 | sean-k-mooney | it is good but i can feel the heat of the browns burn in cdents link from here and i dont even follow american football | |
| 19:00:08 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589 | |
| 19:38:28 | jaypipes | cdent: that is friggin brilliant. | |
| 19:44:40 | cdent | jaypipes: isn't it delightful? | |
| 19:49:19 | jaypipes | cdent: it is indeed. | |
| 19:49:50 | cdent | jaypipes: you may be the Übermensch | |
| 19:58:19 | jaypipes | cdent: heh | |
| 20:03:41 | sean-k-mooney | https://review.openstack.org/#/c/631829/ well this is new. all post_failures and all i have check apparently passed... | |
| 21:52:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add TargetDBSetupTask https://review.openstack.org/627892 | |
| 21:52:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask https://review.openstack.org/631581 | |
| 21:52:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtDestTask https://review.openstack.org/627890 | |
| 21:52:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtSourceTask https://review.openstack.org/627891 | |
| 22:05:45 | zzzeek | mriedem: am I allowed to +2 + workflow my own sqlalhcemy-migrate patch ? | |
| 22:06:10 | mriedem | zzzeek: which one? the mysqlclient one? | |
| 22:06:20 | zzzeek | the "quote=force" one | |
| 22:06:27 | mriedem | i just approved it | |
| 22:06:50 | mriedem | i would like to avoid self approvals, but on that project i think a single +2/+W is probably OK given it's basically just you and me | |
| 22:07:28 | zzzeek | mriedem: that's what i was asking :) | |
| 22:07:46 | zzzeek | er where is verified coming from on that ? is there another zuul job ? | |
| 22:08:46 | mriedem | zuul will run the gate queue jobs on it | |
| 22:09:19 | mriedem | jobs for that project are defined here https://github.com/openstack-infra/project-config/blob/fcc974bf4c0dc324f93a2aec0520e6e4889c106d/zuul.d/projects.yaml#L8106 | |
| 22:21:45 | mriedem | zzzeek: fyi i'm proposing a release for sqla-migrate https://review.openstack.org/632180 | |
| 22:22:23 | zzzeek | mriedem: OK so if this does include the quote=force change, note that I bumped the minimum sqlalchemy vresion to 0.9 | |
| 22:22:49 | mriedem | yup that's why i did a minor version bump | |
| 22:23:14 | zzzeek | mriedem: OK if that's what we need then that's great | |
| 22:23:20 | zzzeek | sqla 0.9 is like 5 years ago | |
| 22:29:04 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add description about sort order in API ref guideline https://review.openstack.org/627282 | |
| 22:35:09 | jaypipes | mriedem: so I think I remember what that rebuild bug/issue I was asking you about last week was... | |
| 22:35:44 | jaypipes | mriedem: if we rebuild to same host but change the image from the original image, we do a full select_destinations-code-path again, right? | |
| 22:37:02 | jaypipes | mriedem: but we include a single destination host when doing the select_destinations(), yeah? In order to basically determine if the original destination host is still a match for the new image? | |
| 22:38:34 | jaypipes | mriedem: if this is the case, we're seeing a problem where we're getting NoValidHost back from the scheduler because the amount of resources "used" for the original host doesn't account for the original instance. In other words, we erroneously double-up the amount of requested resources when attempting to ask the scheduler if the original host is still a fit. | |
| 22:39:28 | jaypipes | mriedem: or rather, that we're not correctly subtracting the amount of used original instance resources from the amount we request in the "recreate" scheduler request. | |
| 22:39:51 | jaypipes | gawd, this stuff is hard to talk about in any sort of reasonably clear language, sorry :( | |
| 22:47:22 | melwitt | jaypipes: correct that we go through the scheduler for rebuilds, as of queens. fwiw, it looks like it will say NoValidHost when filters fail https://bugs.launchpad.net/nova/+bug/1744325 but I don't recall issues with doubling up allocations for rebuilds before | |
| 22:47:24 | openstack | Launchpad bug 1744325 in OpenStack Compute (nova) pike "If a rebuild is refused by the scheduler, the instance's imageref is not rolled back" [High,Fix committed] - Assigned to melanie witt (melwitt) | |
| 22:48:05 | melwitt | (that bug shows brief explanation of rebuild going through scheduler and what happens when there's a failure to schedule) | |
| 22:50:32 | mriedem | jaypipes: pretty sure that's been fixed by cfriesen and/or hongbin | |
| 22:50:38 | mriedem | maybe you don't have the backport | |
| 22:50:39 | jaypipes | melwitt: thx Melanie :) as you know, we're on Ocata currently for VMs and I'm seeing that the "solution" internally is "don't change the image when rebuilding"... | |
| 22:51:50 | jaypipes | Have I mentioned I hate the fact that rebuild is basically a crutch because people can't stand to lose their IP addresses because they hard-code them everywhere? :( | |
| 22:52:37 | melwitt | heh, yeah, good ol rebuild | |
| 22:53:03 | melwitt | so, if this is ocata, you wouldn't be going through scheduler for rebuild right? | |
| 22:54:17 | jaypipes | melwitt: yeah, it's been backported. | |
| 22:54:35 | melwitt | ah ok. I'm looking for a bug fix like mriedem mentioned | |
| 22:54:40 | jaypipes | melwitt: well, at least according to https://bugs.launchpad.net/nova/+bug/1744325 (and we have that code merged in our local ocata branch) | |
| 22:54:41 | openstack | Launchpad bug 1744325 in OpenStack Compute (nova) pike "If a rebuild is refused by the scheduler, the instance's imageref is not rolled back" [High,Fix committed] - Assigned to melanie witt (melwitt) | |
| 22:55:46 | melwitt | jaypipes: here we go https://review.openstack.org/561015 | |
| 22:55:49 | melwitt | good memory mriedem | |
| 22:57:00 | jaypipes | melwitt: that's it! thank you! | |
| 22:57:05 | melwitt | \o/ | |
| #openstack-nova - 2019-01-22 | |||
| 00:13:53 | openstackgerrit | Merged openstack/os-vif master: do not always plug ovs ports. https://review.openstack.org/631829 | |
| 04:55:00 | openstackgerrit | Merged openstack/os-vif master: Cleanup device at the end of 'test_iproute_object_closes_correctly' test https://review.openstack.org/629112 | |