Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-05
15:15:31 yingjun The flavor versioned notifications patches are all ready, the first patch got a +2 from mriedem, it would be much appreciated if any other core could take a look at that :)
15:15:34 yingjun link: https://review.openstack.org/#/q/topic:bp/flavor-notifications+status:open
15:15:48 mriedem mapping to tuples always grosses me out
15:15:48 mriedem sfinucan: sahid: would be nice to use a namedtuple in https://review.openstack.org/#/c/409260/ rather than a naked old tuple
15:15:57 mriedem Guest57355: ok :)
15:16:08 Guest57355 eff
15:16:16 mriedem i think https://review.openstack.org/#/c/416585/ is also having issues still
15:16:16 sfinucan Yeah, I thought a dict but then thought it might be a little...heavy
15:16:19 sfinucan namedtuple works
15:17:17 dansmith mriedem: yeah I just pushed another attempt
15:18:58 sdague dansmith: you want to do this db create reordering - https://review.openstack.org/#/c/384916/ ?
15:20:04 dansmith sdague: yeah, probably so
15:20:35 sdague ok, want to throw a +1 on that for posterity?
15:20:39 sdague Then I'll +2 it
15:21:05 dansmith sure
15:21:16 dansmith sdague: thanks
15:21:17 voelzmo @mriedem thanks for the comments. I understand that from a nova perspective it is undesirable that you cannot delete the server when cinder cannot delete a volume, or that it ends up in some intermediate state. But that's the tragedy of distributed systems, right?
15:21:31 mriedem dansmith: sdague: why do i feel like we already went through this ordering change once already
15:22:10 dansmith mriedem: I had the same feeling, but I think it must have been another detail.. just creating the database shouldn't be a problem
15:22:15 voelzmo @mriedem So that means, if – for some reasons – you would need to clean up manually afterwards, you wouldn't be worse off than right now, correct?
15:22:32 voelzmo whereas, when everything goes right, you would be better of, as things are cleaned up automatically
15:22:42 voelzmo so imho, this would still be an improvement
15:22:44 mriedem voelzmo: well http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#api-scope
15:23:02 mriedem voelzmo: unless we totally screw it up and you can't delete one resource or the other because of state management bugs
15:23:07 mriedem doh
15:23:15 sdague I think there was a proposal to move it around before, which I objected to, as I thought the tools should be resilient
15:23:23 sdague the tools are now resilient
15:23:34 sdague the reorder ends up removing a warning
15:23:54 voelzmo @mriedem are you arguing this change would make nova a proxy?
15:24:19 mriedem voelzmo: well, it adds more orchestration logic to nova
15:24:19 mriedem sdague: that might be, i know we've made some improvements in the nova-manage CLIs since newton
15:24:26 mriedem in some already gorpy code in the neutronv2 api in nova
15:24:53 mriedem this is probably less of a problem for ports because they don't have the same state issues tied to servers as volumes do (i think)
15:25:02 mriedem so nova can just delete them w/o issue
15:25:10 voelzmo right
15:25:47 mriedem however, i still see it as super low priority since if you can create the port and provide it on server boot, then i don't see what the issue is with removing it after server delete too
15:26:30 mriedem for the very basic flows, nova creates a volume or a port for you and cleans those up afterward, we want users providing ports and volumes at server create time for more advanced cases
15:26:53 mriedem and to not get involved in cleaning those up (or not, depending on what the user specified)
15:26:59 voelzmo @mriedem so you're arguing, we should also remove the deletion of the boot volume from nova?
15:27:09 voelzmo and users should do that themselves?
15:27:19 mriedem voelzmo: not directly no...but it's not a bad idea
15:28:11 mriedem honestly the major bug around delete_on_termination with volumes is out of my head right now, but there is a thread about it in the ML somewhere i could find if needed, and a bug and several patches related to problems with it
15:28:20 mriedem i'm sure hemna and scottda remember details there too
15:29:22 scottda mriedem: I'd have to think on that one. But I do recall we had issues....
15:29:23 smcginnis It was the whole discussion that nova is not an orchestration layer, it's just another component of the cloud, so why should it coordinate all actions. IIRC.
15:30:18 voelzmo @mriedem Not sure if deleting a thing and therefore also deleting things associated with it is already orchestration. But that might be nitpicking on the definition of words.
15:31:12 voelzmo The case I'm making is: I have to use pre-created ports to know their mac addresses up front, although I don't care about ports as separate entities once the VM is gone
15:31:16 scottda It might be that it's bad to automatically delete a persistent volume when deleting the VM that boots from it....user might want more control. I'll have to dig back for details...
15:31:21 voelzmo same as with boot volumes, thus the analogy
15:31:47 smcginnis If "deleting a thing" where the thing is from somewhere else, that's orchestration.
15:31:50 voelzmo and I'm not arguing to take control away from the user, I'm adding a new case in which you can give up that control if you like
15:32:08 voelzmo all existing cases of "more control" still exist and remain even the default
15:32:42 voelzmo What's even worse: The thing we're arguing about used to work like I'm proposing until the "bugfix" in Kilo
15:32:52 mriedem scottda: yes that's my assumption on the original use case for delete_on_termination with volumes - nova creates the volume, but you want it leftover after the server is deleted
15:33:15 mriedem voelzmo: well before kilo we had the other bug that nova would delete pre-created neutron ports when the server was deleted
15:33:20 mriedem which was also a nasty bug that pissed everyone off
15:33:24 voelzmo I can also create the volume upfront and provide it to boot_from_volume
15:33:33 voelzmo and still have nova delete it on VM deletion
15:33:48 voelzmo @mriedem that's the bug I'm talking about :)
15:33:53 mriedem voelzmo: i know
15:36:55 mriedem voelzmo: to be clear, i'm not totally against the idea, i'm just hesitant to add more stuff like this into nova
15:37:09 mriedem anyway, we're not close to pike specs anyway yet, so it'll simmer for awhile
15:37:29 mriedem either way, welcome :)
15:37:33 voelzmo @mriedem understood, thanks for the comments. I thought it will most likely not make it into ocata, so I just submitted it directly to pike
15:37:56 sahid sfinucan: mriedem ok no problem will update the code based on your comments
15:37:59 sahid thanks for the reviews
15:41:28 macsz mriedem: there was no meaningful response from the operators on https://review.openstack.org/#/c/397800/ (ML: http://lists.openstack.org/pipermail/openstack-operators/2016-November/012087.html ). do you think we can go forward and remove -2? I will address comments from PS2 today
15:42:54 mriedem macsz: can you follow up with johnthetubaguy or mikal to make sure rax isn't using that hook mechanism before we yank it?
15:44:10 mriedem macsz: i'll also fish in the operators channel one last time today
15:44:23 mordred mriedem: morning sir! in http://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail the example response shows a bunch of fields starting with total - but they are not in the documented set of responses
15:44:24 macsz mriedem: sir, yes, sir!
15:44:28 mordred mriedem: any idea which is correct?
15:45:03 mriedem http://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#id215 ?
15:45:29 mriedem mordred: let me dig
15:45:32 wznoinsk mriedem, yes, trivial, we're working on a permanent fix while workarounded and recheck in-flight (via zuul cli rather than gerrit)
15:45:41 mordred mriedem: thanks!
15:45:42 mriedem wznoinsk: thanks
15:46:30 mriedem sdague: reminder ping on https://review.openstack.org/#/c/415511/
15:46:42 openstackgerrit Rafael Folco proposed openstack/nova: DELETE all inventory for a resource provider https://review.openstack.org/416669
15:48:43 sdague mordred: I think the total* fields are real, just not documented
15:48:59 mordred sdague: awesome. should I file a bug?
15:49:07 sdague mordred: sure
15:49:12 mordred \o/
15:49:32 mriedem mordred: os-used-limits
15:49:36 mriedem that's the thing that provides those
15:49:58 mriedem https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/used_limits.py#L42
15:50:25 mriedem if i'm reading that gorp correctly, os-used-limits extends the limits API
15:50:52 mordred gotcha. so it used to be an extensoin - is now likely a part of the limits api due to miroversions yeah?
15:50:57 mriedem and adds the used limits (totals) to the response object from the limits controller
15:51:08 sdague mordred: yeh
15:51:19 mriedem mordred: well it's still an extension, but :)
15:51:20 mordred also - should I expect that the floatingips and security group fields will go away with proxy removal?
15:51:22 sdague mriedem: so, for good form on https://review.openstack.org/#/c/415511
15:51:24 mordred mriedem: :)
15:51:41 sdague mordred: yes, the code drops those at 2.36
15:51:45 mordred oh. duh. yah - I see that now
15:51:46 mriedem floatingip and security groups will work with microversion < 2.36
15:51:47 mordred awesome
15:52:10 mriedem after we drop nova-net, those won't work for nova-net backed systems at any microversion
15:52:19 mriedem because the code will literally be gone

Earlier   Later