Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
16:49:18 sean-k-mooney gibi which it does hand has always supported
16:49:18 gibi sean-k-mooney: so if neutron rejects that then reubild does not need to be changed due to bandwidth
16:49:52 gibi sean-k-mooney: it should not be supported to min bandwidth any more without making sure that the placement allocation is updated
16:50:10 gibi sean-k-mooney: otherwise we end up in resource inconsistencies
16:50:18 mriedem cfriesen: there are examples in https://docs.openstack.org/nova/latest/admin/pci-passthrough.html
16:50:25 sean-k-mooney gibi: sure but doing so was not covered in the spec because it was declared out of scope
16:50:31 gibi sean-k-mooney: exactly
16:50:37 mriedem cfriesen: and https://docs.openstack.org/nova/latest/configuration/config.html#pci.passthrough_whitelist
16:50:42 sean-k-mooney gibi: so in stien it wont be done
16:50:52 gibi sean-k-mooney: so I will ping rubasov tomorrow to make it clear if they will do the reject or not
16:50:58 sean-k-mooney adn we can get out of sync with neutron
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: WIP: Add PrepResizeAtDestTask https://review.openstack.org/627890
21:52:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask https://review.openstack.org/631581
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

Earlier   Later