Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-26
19:58:36 mikal mriedem: ahhh, ok, I shall study before next time
19:58:50 mriedem mikal: anyone that was relying on it and has newer than kilo, and didn't notice, then yeah i guess we don't need it
19:59:04 mriedem that's the assertion in the ML thread and commit to remove it anyway
20:03:35 melwitt does anything ever set 'group_members' in filter_properties? I'm not finding anything https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L205
20:04:42 sdague mikal: I retool your ploop patch with the fixes from the virtuozo folks
20:04:59 melwitt this line is making reschedule fail with "'NoneType' object is not iterable" after a late-affinity-check failure. I don't see how reschedule after late check ever could work
20:08:23 mriedem melwitt: it could be a case of group_members being set on the request spec initially, and then it's transformed into the primitive filter_properties stuff which doesn't include the group_members?
20:08:32 mriedem i've seen some wonky stuff with how the request spec transforms to/from the legacy filter props
20:09:19 mikal sdague: ta, looking at it now
20:09:37 mriedem melwitt: see _to_legacy_group_info ?
20:09:49 mriedem it sets group_updated=True but doesn't include group_members
20:09:51 melwitt mriedem: I don't see that RequestSpec has any group_members in it. I grepped for "group_members" in nova and found nothing that ever sets it
20:10:19 melwitt yeah, I see that. that's the only thing that looks like it could be related
20:10:21 mikal sdague: looks like there is a rebase error there though? The console pty stuff is now in that patch.
20:10:43 mtreinish dansmith: http://logs.openstack.org/57/507657/1/check/gate-nova-python27-ubuntu-xenial/55aebe1/console.html#_2017-09-26_19_42_08_172719
20:10:50 mikal sdague: I shall rectify
20:10:50 melwitt mriedem: late affinity check reschedule just looks totally broken unless I'm blind. which may very well be the case
20:11:00 mriedem melwitt: this added it https://review.openstack.org/#/c/148277/
20:11:43 melwitt thanks
20:12:08 mriedem https://review.openstack.org/#/c/148277/64/nova/scheduler/utils.py@349
20:12:14 melwitt looks like that line in scheduler/utils that sets it is gone now
20:12:36 openstackgerrit Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215
20:12:36 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
20:12:37 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
20:13:06 melwitt trying to find what removed it
20:13:08 mriedem melwitt: https://review.openstack.org/#/c/469037/
20:13:22 mriedem pike ^
20:13:46 mriedem https://review.openstack.org/#/c/469037/6/nova/scheduler/utils.py
20:13:48 melwitt thanks
20:14:50 melwitt okay, so the conductor logic is still relying on stuff being in filter_properties via RequestSpec.from_primitives
20:15:39 mriedem looks like it, left some comments in https://review.openstack.org/#/c/469037/6/nova/objects/request_spec.py
20:15:46 mriedem likely need a functional regression test to show the failure
20:15:54 mriedem then fix on top and backport both to pike
20:16:02 mriedem melwitt: do you have a bug for this?
20:17:42 melwitt mriedem: no, I can open one. wanted to sanity check with yall first
20:17:56 mriedem someone was saying they hit this exact same thing this morning to bauzas
20:18:45 melwitt hah, what a coinky dink
20:19:09 mriedem please keep that sailor talk for at home
20:20:17 melwitt aye aye sir!
20:20:26 melwitt matey
20:20:38 melwitt oh, that's pirate. nvm
20:20:52 openstackgerrit Dan Smith proposed openstack/nova master: Move allocation manipulation out of drop_move_claim() https://review.openstack.org/498947
20:20:53 openstackgerrit Dan Smith proposed openstack/nova master: Make allocation cleanup honor new by-migration rules https://review.openstack.org/498948
20:20:53 openstackgerrit Dan Smith proposed openstack/nova master: Pre-create migration object https://review.openstack.org/498950
20:20:54 openstackgerrit Dan Smith proposed openstack/nova master: Revert allocations by migration uuid https://review.openstack.org/498949
20:20:54 openstackgerrit Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419
20:20:55 openstackgerrit Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420
20:20:55 openstackgerrit Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638
20:21:12 mriedem dansmith: what's the word
20:22:10 melwitt bird bird bird bababir bird's the word
20:30:19 melwitt mriedem: https://bugs.launchpad.net/nova/+bug/1719730
20:30:21 openstack Launchpad bug 1719730 in OpenStack Compute (nova) "Reschedule after the late affinity check fails with "'NoneType' object is not iterable"" [Undecided,New]
20:32:00 efried mriedem sdague https://review.openstack.org/#/c/488137/ should be ready again
20:32:49 melwitt heh
21:07:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Add recreate test for live migrate rollback not cleaning up dest allocs https://review.openstack.org/507677
21:07:50 mriedem dansmith: ^ thus begins another round of these
21:11:50 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: config drive https://review.openstack.org/409404
21:36:24 pino Hi Folks, I'm just getting started on a project that would provide an alternative to using key-pairs for instances: ssh certificates. This requires injecting into the instance (before startup) a host certificate, a user CA public key, and authorized principals file(s); then modifying sshd_config to use them. What's the right way to hook into the co
21:36:25 pino mpute instance lifecycle?
21:37:40 pino I'm just experimenting, but I'm wondering if this would be best built as part of Nova itself, or separately hook into the lifecycle.
21:38:34 jaypipes pino: definitely not part of Nova itself, no. apart from writing files to a config drive, Nova doesn't mess with the VM.
21:39:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove dest node allocations during live migration rollback https://review.openstack.org/507687
21:39:47 pino jaypipes: ok, fair enough... but shouldn't support for ssh certificates be modelled similar to keypair support?
21:41:31 jaypipes pino: honestly, I'm not sure what the diff is between a key pair, with the private part of the pair downloaded to the user and the public part laid down on the VM config drive, and the SSH certificates thing you're describing.
21:41:44 pino And in terms of doing it outside of Nova, do you agree Nova notifications are not the right mechanism? The injection of various files, plus modification of the sshd_config must be done before first boot. Any advice about where, and how to do the hook?
21:41:47 jaypipes pino: I'm not an expert in ssh stuff, apologies.
21:43:00 pino jaypipes: I probably gave too much detail. I'm just looking for some hints about how I can hook into the startup workflow and block it until I've configured the VMs SSH the way I want it.
21:44:13 jaypipes pino: I think cloud-init is more what you are looking for?
21:45:22 mriedem pino: https://docs.openstack.org/nova/latest/user/vendordata.html
21:45:45 mriedem setup an external rest service that provides metadata to the guest when it's created
21:46:24 mriedem example https://github.com/openstack/novajoin
21:47:14 penick pino: I use SSH CA in my environment, maybe I can help?
21:47:21 pino mriedem: I saw that but wasn't sure it was the right approach. I'll take a closer look, thanks for the example.
21:48:02 penick I think I see what you're trying to do, and I think what you're probably going to want is to build a small webservice to create and sign SSH certificates, then tie that in with the nova vendordata stuff to get injected into the instance on boot
21:48:19 mriedem it's a wild penick
21:48:25 mriedem i wonder what the keyword is here
21:48:29 penick I identify as feral
21:48:47 pino jaypipes: I'm looking at cloud-init too... but I want my setup script to run without the user's help (they shouldn't have to do any setup).
21:49:11 pino penick: that makes perfect sense.
21:50:20 pino Ok, so I have a few topics/approaches to study. Thanks!
21:51:40 penick np :)
22:10:23 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for keystone conf & requests https://review.openstack.org/507693
22:26:36 rybridges Hey guys, I have a question. I am trying to inject some default user data into every instance while it is provisioning at this location -> https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L1011 (I am adding an internal patch for this) In my patch, I create the user data, merge it with any existing user data on the instance, and then try to write the new user data to the
22:26:38 rybridges database. I am stuck getting it to write into the database. instance.save(
22:27:18 rybridges instance.save() is throwing stack traces. so I am trying to use the update_instance() method defined in the API class defined here https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L2622
22:27:31 rybridges but that does not seem to actually be saving the user data in the instance for some reason
22:27:51 rybridges it calls build_req.save() in the update_instance() method
22:32:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove dest node allocations during live migration rollback https://review.openstack.org/507687
22:32:48 melwitt rybridges: doing it that way is a bad idea IMHO. if you're looking to have default data injected into every instance, you should look into the vendordata stuff that was linked earlier
22:36:44 rybridges so its not default perse, it will actually change based on some parameters. i just figured it would be easier for people to understand my problem if i said default
22:37:05 rybridges i dont like the vendordata stuff because it requires us to write an external webservice which complicates our deployment
22:37:19 rybridges i would rather just make a small patch which hits an entry point and injects the user data into the instance
22:37:25 rybridges it is much simpler and easier to debug/work with
22:38:14 rybridges i feel like it should not be this difficult..
22:38:27 rybridges to just save the instance and get the user data written to the db
22:39:39 mriedem you know what's going to complicate your deployment?
22:39:53 mriedem constantly rebasing your fork, and when we change the internals that it depends on
22:40:50 rybridges we plan on adding a vendordata service eventually
22:41:08 rybridges also, the rebase is basically nothing
22:41:11 rybridges my patch is 3 lines

Earlier   Later