Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-05
13:43:29 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance.rebuild notification https://review.openstack.org/384922
14:00:07 wznoinsk frickler, we're on it, thanks
14:10:29 johnthetubaguy cdent: I got a bit confused with a bit of gabbi, can you check I am interpreting it correctly please: https://review.openstack.org/#/c/407742
14:10:37 johnthetubaguy ah, oops, he is not here
14:14:48 edleafe johnthetubaguy: I'm kinda fuzzy on that part, too
14:23:40 openstackgerrit Gleb Stepanov proposed openstack/nova: Add _rebuild_instance helper method https://review.openstack.org/376004
14:36:29 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance-exists notification https://review.openstack.org/403660
14:39:42 macsz sfinucan: my gerrit weltschmerz-ism precedes me
14:46:42 openstackgerrit sahid proposed openstack/nova: libvirt: fix uncaugth exception during soft reboot https://review.openstack.org/376350
14:46:43 openstackgerrit sahid proposed openstack/nova: libvirt: make coherent logs when reboot success https://review.openstack.org/416994
14:46:43 openstackgerrit sahid proposed openstack/nova: libvirt: rework _destroy method https://review.openstack.org/416995
14:50:14 mriedem wznoinsk: intel nfv ci having some issues today?
14:52:12 openstackgerrit Jeremy Liu proposed openstack/nova: [2/3]Replace six.iteritems() with .items() https://review.openstack.org/413470
14:52:43 openstackgerrit Marco Voelz proposed openstack/nova-specs: Add port deletion on termination of server https://review.openstack.org/416997
14:53:47 voelzmo @johnthetubaguy remember our conversation about pre-created ports being deleted on VM termination? proposed that to nova-specs for pike: ^^
15:01:46 mriedem voelzmo: just left some comments
15:02:54 mriedem personally i'd consider that super low priority since if you can create the port outside of nova you should be able to delete it too
15:03:45 mriedem the delete_on_termination stuff with volumes has gotten us into problems with cinder state management too
15:03:56 cdent sdague: having two different api-ref's in the nova tree makes for some ick with trying to reuse existing api-ref jobs and job groups. Would you suggest making a standalone placement-api-ref job and annotating it appropriately? Or something else?
15:03:59 mriedem where we can't delete the server because nova can't delete the volume
15:04:14 mriedem cdent: i'd separate them
15:04:26 mriedem it's just different subdirectories and tox targets
15:04:35 mriedem the project-config stuff should be fairly simple too
15:05:30 cdent mriedem: I was referring to the fact that there is a lot of automation already in place for {name}-api-ref that looks for directories of certain names, which falls flat in the face of placement-api-ref, thus the need for newer/separate job
15:07:22 mriedem automation in nova or in project-config?
15:07:33 sfinucan sahid: Had a gawk at https://review.openstack.org/#/c/409261 - one comment left
15:07:37 cdent mriedem: project-config
15:07:58 cdent nothing that can't be overcome relatively easily
15:08:54 sfinucan johnthetubaguy: I just re +2'd that patch we were discussing earlier, if you wanted to do the same https://review.openstack.org/#/c/346869/
15:14:44 sahid sfinucan: ok thanks i will have a look shortly
15:15:16 Guest41100 mriedem: I reordered my set to put these two cleanups in front of the next patch I'm working on so we can get them out of the way: https://review.openstack.org/#/c/410471/6
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 sfinucan: sahid: would be nice to use a namedtuple in https://review.openstack.org/#/c/409260/ rather than a naked old tuple
15:15:48 mriedem mapping to tuples always grosses me out
15:15:57 mriedem Guest57355: ok :)
15:16:08 Guest57355 eff
15:16:16 sfinucan Yeah, I thought a dict but then thought it might be a little...heavy
15:16:16 mriedem i think https://review.openstack.org/#/c/416585/ is also having issues still
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 sdague: that might be, i know we've made some improvements in the nova-manage CLIs since newton
15:24:19 mriedem voelzmo: well, it adds more orchestration logic to nova
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

Earlier   Later