Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-05
12:41:47 diga_ gibi: brb
12:46:44 openstackgerrit Zhenyu Zheng proposed openstack/nova: Add query parameters white list for server list/detail https://review.openstack.org/408571
13:07:07 openstackgerrit Chris Dent proposed openstack/nova: [WIP] Structure for simply managing placement-api-ref https://review.openstack.org/409340
13:08:00 cdent sdague: if you get a chance to look at that ^ to sanity check that would be awesome. It's not done, but I want to make sure I'm not heading down a bad path. You'll also likely have some insight on how to make the testing it tries to do happen in the right place.
13:12:57 sdague cdent: looking
13:13:05 cdent s
13:13:05 cdent awesome, thank
13:16:56 johnthetubaguy sfinucan: ah, good spot
13:19:04 sdague cdent: yeh, that catch looks generally good, though the gate docs target actually doesn't run tox -e docs, so that's not going to fail in the gate when it's failing locally
13:19:14 cdent yeah
13:19:19 cdent (mentioned that in the commit message)
13:19:44 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance-exists notification https://review.openstack.org/403660
13:20:01 cdent it not failing is fine for now since there aren't any docs, but it would be nice to flip a switch at the bottom of the stack after all existing routes are docced
13:20:26 cdent s/bottom/top/ <- dan's ordering
13:22:01 johnthetubaguy sfinucan: I think we just move them all
13:30:19 sdague cdent: well, it causes the local tox rule to fail
13:31:12 cdent sdague: yeah, what I mean is: it would be nice to make the lack of docs to cause a docs failure (somehow), after all the existing routes are documented
13:38:20 mdbooth sfinucan: Thanks.
13:40:52 openstackgerrit Gleb Stepanov proposed openstack/python-novaclient: Add evacuate host method https://review.openstack.org/349179
13:41:36 sfinucan johnthetubaguy: I agree
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

Earlier   Later