Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-05
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
15:52:46 sdague mriedem: on https://review.openstack.org/#/c/415511 ... could you put the body snippets of what the resources end up looking like? Mostly just because REST changes are much easier to historically review in specs when it shows actual sample response
15:52:57 mriedem mordred: anyway, yeah a bug for not having os-used-limits documented in the api-ref would be good
15:53:10 mriedem sdague: sure
15:53:17 sdague mriedem: the spec works for me otherwise
15:53:29 openstack Launchpad bug 1654316 in OpenStack Compute (nova) "total* fields in limits example response undocumented" [Undecided,New]
15:53:29 mordred mriedem: https://bugs.launchpad.net/nova/+bug/1654316
15:54:16 mordred sdague, mriedem: while I'm bothering you - do you happen to know off the top of your head if glance/neutron have equiv limits api calls?
15:54:29 openstackgerrit Matthew Booth proposed openstack/nova: libvirt: Add create_from_image and create_from_func to Backend https://review.openstack.org/333244

Earlier   Later