Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
16:40:39 gibi sean-k-mooney: I will ping rubasov tomorrow about it, he is leading the neutron work
16:41:21 sean-k-mooney gibi: anyway this is why assumed rebuild would be out of scope until the migration stuff was done as i assuem someone nova or neutron would have to do this type of validaion
16:41:28 gibi sean-k-mooney: https://review.openstack.org/#/c/595243/2/specs/stein/approved/bandwidth-resource-provider.rst@110 here I state in the spec that changing rule is out of scope https://review.openstack.org/#/c/595243/2/specs/stein/approved/bandwidth-resource-provider.rst@110
16:42:05 gibi sean-k-mooney: but rebuild is not the good time to check, the port might changed without anybody calling rebuild on the server the port is bound to
16:42:20 sean-k-mooney gibi: yes i am aware its out of scope but its required for rebuild and move i think
16:43:06 sean-k-mooney gibi: anyway i dont think it should be a blocker for this in stien
16:43:27 sean-k-mooney its just another edgecase to be address in train
16:43:45 gibi sean-k-mooney: move will use the actual state of the port not because it wants to use the updated value but because neutron is considered the source of truth in case of port resource request so nova does not store such request
16:44:41 gibi when somebody try to change a QoS rule on a boun port, neutron should check if there are enough resource before it accepts the rule change
16:44:43 sean-k-mooney gibi: sure is it not logical that rebuild should also use the actual state of the port for the same reason
16:44:48 mriedem i assume this is already a problem in the neutron api which is much more loosey goosey about making changes to bound ports, unlike cinder's strong enforcement of not making changes to attached volumes
16:44:58 sean-k-mooney gibi: yep we discussed that in dublin
16:45:03 mriedem e..g in neutron am i able to change port binding details about a bound port?
16:45:28 sean-k-mooney mriedem: the other qos type dont consome resouces
16:46:07 sean-k-mooney e.g. max bandwith and dscp marking can be changed on the fly
16:46:08 gibi sean-k-mooney: in generan nova will not be able to prevent the user to change a port in a way that leads to inconsistencies so neutron should do the check
16:46:25 sean-k-mooney gibi: yep im not arguing it should try
16:48:20 cfriesen sean-k-mooney: is this still correct as far as the formatting of the PCI whitelist or is there a newer doc somewhere? https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/pci-passthrough-sriov.html
16:48:45 gibi sean-k-mooney: but re-allocation during rebuild only needed if neutron allowed the bound port to change.
16:48:48 sean-k-mooney there is a new dock but let me check
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

Earlier   Later