Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-19
10:07:08 sean-k-mooney i vaguely rememebr talking about it a week or two ago that we would have to do something to handel this edgecase
10:07:55 kashyap aspiers: No problem; I myself will be off next week
10:09:10 sean-k-mooney gibi: even if its not rc potential which i kind of agree with i think this should be backportable shortly after GA
10:11:10 gibi sean-k-mooney: when the bound port is deleted in neutron nova gets the notification and detaches the port from the server. I don't know how the periodic is involved here
10:11:49 gibi sean-k-mooney: moreover I till not conviced that why the admin cannot detach the port in nova first and only delete it after in neutron
10:12:40 gibi detach + delete works properly with bandwidth
10:19:48 sean-k-mooney gibi: when a bound port is delete neutron send a notification to nova which the periodic jobs will recive
10:20:19 sean-k-mooney gibi: this also does not require admin acess
10:20:57 sean-k-mooney a tenant can simple do a openstack port delete to cause this issue
10:21:42 aspiers kashyap: you wanted me to split out the addition of getDomainCapabilities() from the <sev> parsing, right?
10:21:54 kashyap aspiers: Yes, please
10:22:05 aspiers kashyap: the problem is, that code doesn't parse anything else in the output
10:22:07 sean-k-mooney gibi: but you are right that this should be done by a nova interface detach in general
10:22:33 aspiers kashyap: so the first patch would introduce nonsensical code
10:23:11 sean-k-mooney we should however be able to process the network-status event we get form neutron and heal the placement allocation regardless of why it was done so its not something i would worry too much about
10:23:24 aspiers kashyap: the only thing it parses is <sev> under <features>
10:23:53 aspiers kashyap: so splitting it would result in 3 new LibvirtConfigObject classes which do absolutely nothing
10:24:03 kashyap Hmm
10:24:41 aspiers I could make it parse something else just for the sake of it
10:24:45 kashyap Why would it be "nonsensical code" to split out a logically separate part?
10:24:49 aspiers Not sure whether that makes sense though
10:25:23 aspiers Because that separate part is non-functional noop code
10:25:35 aspiers There'd be nothing to test
10:26:16 gibi sean-k-mooney: I disagree. Why end user wants to delete a bound port instead of deatching it?
10:26:29 gibi sean-k-mooney: what is the use case for this?
10:27:10 sean-k-mooney gibi: its something that we have supported for many releases. there is not a defined usecase but neutron has never prevented it and until now nova has alreays correctly detached the port
10:27:39 sean-k-mooney the only other fix we could do is modify neutron to make deleteing a bound port illegal
10:28:00 sean-k-mooney we could do that but that is a seperate issue
10:28:05 aspiers kashyap: unless you can think of something to test?
10:28:18 aspiers but if it's not parsing anything I can't really see how
10:28:40 gibi sean-k-mooney: to support bandwidth cleanup at bound port delete is not a trivial thing. It adds complexity for someting that has no clear use case and I don't like that
10:29:26 kashyap aspiers: /me needs to fully re-load this context; but if you think it is not helping in anyway (even for review), then leave it as-is
10:29:37 kashyap aspiers: And note this reasoning somewhere in the commit message or the change
10:29:45 sean-k-mooney gibi: that is true but the only way to prevent needeing to handle this is to modify the neutron api to prevent deletion of bound ports which will require a spec and my have unintended sideffects
10:30:12 sean-k-mooney anyway we could fix it in the periodic job but that does not mean we have too
10:30:49 aspiers kashyap: I've split out the move of machine type calculation to utils.py
10:30:54 aspiers kashyap: which already helps a bit
10:30:56 gibi sean-k-mooney: I'm not sure we can easly fix it in the periodic job. Also I think it would make sense to discuss why neutron allows deleteing a bound port
10:31:01 kashyap aspiers: Yeah, that helps
10:31:21 aspiers kashyap: take a look at https://review.openstack.org/#/c/633855/11/nova/virt/libvirt/config.py
10:32:01 aspiers kashyap: if I remove parsing of <sev>, then LibvirtConfigDomainCapsFeatures becomes a noop (no features ever get parsed and added to self._features)
10:32:12 aspiers and in that case LibvirtConfigDomainCaps is also a noop
10:32:38 aspiers parse_dom() would do absolutely nothing
10:32:42 sean-k-mooney gibi: yep we porablly should bring it up in the cross project session
10:33:05 gibi sean-k-mooney: OK, I'm adding it to the etherpad
10:33:09 sean-k-mooney gibi: the asymitry has always annoyed me that we can detach port via neutron but not attach them
10:33:29 aspiers kashyap: like I said, I could make it parse something simple like <path> and/or <arch> just so that there is something to test
10:33:58 kashyap aspiers: Dealing with 4 pings, please bear with me.
10:33:59 sean-k-mooney gibi: but yes to your original point this proably does not need to be fix in the RC and can be "fixed" what ever way we decided in train and backported if needed
10:34:01 aspiers kashyap: that would give just enough excuse to split it out, but whatever I parsed would not be consumed by anything, at least until you start using it
10:34:08 aspiers kashyap: haha sure :)
10:34:57 gibi sean-k-mooney: yeah. I don't want to rush this fix as honetly I don't see how can this be easily fixed
10:35:38 sean-k-mooney gibi: if we block it in the neutron api that wont be backportable but the osc-placement plugin can always be used to fix it by hand if needed
10:36:02 cdent "how can this be easily fixed" the story of nova's life
10:36:32 sean-k-mooney cdent: well you can always just delete the vm and that will make everything better :)
10:37:04 gibi cdent: especially that we "need to fix" even if we don't know what is the use case
10:37:08 cdent that's the other half of the story: "we're using this cloud as a home for our pets"
10:38:01 sean-k-mooney cdent: of cource clouds and nice and fluffy places for our pets to live with totally no sharp edges
10:38:19 cdent made by magical open source bunnies!
10:38:50 gibi sean-k-mooney: no edges?! :) we want EDGE in the cloud :D
10:39:34 sean-k-mooney gibi: hehe ture but hopefully said edges wont be sharp :)
10:39:49 gibi we need fluffy edges!
10:40:35 sean-k-mooney new goal for summit. get "fluffy edges" into someones marketing deck
10:44:06 cdent fluffy edges sounds like a pretty good term for dynamically scalable edge nodes
10:48:41 kashyap aspiers: "Not consumed by anything" is okay so long as it (a) helps with clarity; (b) makes way for future patches to cherry-pick it for a particular use case
10:55:21 aspiers kashyap: yeah but needs to be testable still!
10:56:14 kashyap aspiers: Agreed :-) Don't let this block you.
11:03:37 openstackgerrit Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952
11:09:54 kashyap mdbooth_: When you get a moment, since we always return a non-None 'disk_cachemode' here: https://review.openstack.org/#/c/641981/10/nova/virt/libvirt/driver.py@443
11:10:12 kashyap mdbooth_: Are you implying to remove the check there?
11:10:35 mdbooth kashyap: No, that comment was wrt the release note
11:10:50 mdbooth Because we never return non-None there, we never use the qemu default
11:10:57 mdbooth So to the qemu default is irrelevant
11:11:07 kashyap Ah, guessed as much.
11:11:13 kashyap You wrote it in reference to the help text
11:11:18 kashyap Okay, elided the irrelevant bit.
11:11:19 kashyap Thanks!
11:11:31 mdbooth s/release note/docs/
11:16:53 openstackgerrit Gorka Eguileor proposed openstack/nova master: Fix unnecessary locking when connecting volumes https://review.openstack.org/614190
11:22:35 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable https://review.openstack.org/641981
11:22:35 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode https://review.openstack.org/643376
11:22:36 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode https://review.openstack.org/643377
11:23:17 sean-k-mooney kashyap: you are not enableing writeback by defualt when none is not available are you?
11:24:01 kashyap sean-k-mooney: That's exactly what it's doing; please read the commit message. I spent 3 hours writing it.
11:24:04 kashyap https://review.openstack.org/#/c/641981/
11:24:22 sean-k-mooney kashyap: if none is not an option we shoudl default to the safet alternitive either directsync or writethrough and only use writeback if there is no other option
11:24:27 kashyap FWIW, : I ran the patch by QEMU Block Layer maintainer over an e-mail thread.
11:24:38 kashyap sean-k-mooney: No, that is wrong. See the commit message and the comment in the code, again.
11:24:44 sean-k-mooney i just saw the ping. i had not opened it yet
11:28:25 sean-k-mooney kashyap: i had under stood that writback did not honer guest fush commands. is that not the case?
11:28:40 sean-k-mooney if it does the ok
11:28:44 sean-k-mooney *then
11:32:58 kashyap sean-k-mooney: It does honour it
11:33:02 kashyap sean-k-mooney: Also see: http://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=e7b64eaad8
11:33:06 sean-k-mooney ok ya looking at the docs it does
11:33:30 kashyap Nod
11:34:09 sean-k-mooney i had tought there was still an edgecase with virtio scsi not informing the guest os that it was in writeback mode and that this only worked with virtio-block but maybe not
11:34:18 sean-k-mooney i could be tinking of discard instead of flush
11:36:36 sean-k-mooney kashyap: anywya i trust your and the qemu maintiners knoladge of this better then my own. its been a while since i dug into the cahce modes in any detail
11:44:16 sean-k-mooney kashyap: ah i found the ceph note i was missremembering. when using caching with RBD you expcitly have to use writeback cache mode not that you sould not use cach=writeback. http://docs.ceph.com/docs/master/rbd/qemu-rbd/#running-qemu-with-rbd the last time i looked into this was determing the correct way to use qemu safely with ceph storage with caching which at the time was virio-scsi for

Earlier   Later