Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
16:36:24 mriedem correct
16:36:42 gibi sean-k-mooney: so it is not special for banwidth
16:36:45 mriedem because all of the nfv stuff added in juno didn't take rebuild into account
16:36:47 sean-k-mooney https://bugs.launchpad.net/nova/+bug/1763766
16:36:48 openstack Launchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow resource consumption changes on image rebuild" [Medium,Triaged]
16:37:03 mriedem s/rebuild/any other operation besides delete/
16:37:07 sean-k-mooney true but the bug cfriesen pointed to would cover it^
16:37:23 cfriesen mriedem: and resize
16:37:34 mriedem "any other operation besides delete"
16:37:35 gibi sean-k-mooney: OK, so you suggest to fail rebuild if the port's resource request changed
16:37:43 sean-k-mooney gibi: yes
16:37:51 gibi sean-k-mooney: that would need nova to store such request
16:38:00 gibi sean-k-mooney: to have something to compare with
16:38:10 mriedem ummm
16:38:17 sean-k-mooney gibi: it could compare it to the existing placement allocation
16:38:22 gibi sean-k-mooney: I'm more like the idea that neutron rejects the change of a qos rule if the port is bound
16:38:29 mriedem that seems pretty shitty for nova have to do that enforcement,
16:38:33 gibi sean-k-mooney: with multiple port, that comparision is really ahrd
16:38:35 gibi hard
16:38:38 sean-k-mooney gibi: that was brought up before
16:38:51 mriedem neutron should be responsible for not allowing bw policy changes on attached ports
16:39:02 sean-k-mooney gibi: it would be a change in the neutron behaivor but not one that they said the were against
16:39:17 mriedem gibi: yes i agree with what you said,
16:39:23 sean-k-mooney mriedem: well this is special for min mandwith
16:39:25 mriedem "I'm more like the idea that neutron rejects the change of a qos rule if the port is bound"
16:39:37 gibi sean-k-mooney: I reacall that this was stated in the spec
16:39:37 sean-k-mooney there is no reason max bandwith of dscp cant change
16:39:43 openstackgerrit Merged openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677
16:40:15 sean-k-mooney gibi: i raised this before yes but i dont think we made a decision to actully modify neutron to do it
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

Earlier   Later