Posted	Nick	Remark
#openstack-nova - 2017-12-07
15:57:08	mriedem	https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L3653
15:57:17	mriedem	so that's the only time (aside from bfv with an existing volume) that we'd reserve
15:57:53	ildikov	ok
15:58:24	mriedem	i believe i have a todo sitting here to document how boot from volume actually works
15:58:29	mriedem	because i explained it once in the mailing list
15:58:48	mdbooth	jaypipes: Yeah. Working on something further down the stack atm.
15:59:08	mdbooth	jaypipes: Wait, are they at the beginning of the stack, too?
15:59:13	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095
15:59:14	openstack	bug 1735407 in OpenStack Compute (nova) "[Nova] Evacuation doesn't respect anti-affinity rules" [Medium,In progress] https://launchpad.net/bugs/1735407 - Assigned to Balazs Gibizer (balazs-gibizer)
15:59:20	ildikov	mriedem: if you have a link to that I would be happy to read it :)
15:59:20	jaypipes	mdbooth: no, second patch in series
15:59:47	mdbooth	Hmm, that was careless.
15:59:51	mdbooth	jaypipes: fixing it now.
16:00:26	ildikov	mriedem: we can have a quick meeting and see what's next
16:01:11	mdbooth	Ah, fixed that locally, didn't realise I'd pushed the old one, sorry.
16:07:26	openstackgerrit	Matthew Booth proposed openstack/nova master: Make BlockDeviceMapping object support uuid https://review.openstack.org/242603
16:09:02	maciejjozefczyk	Hello Guys, im trying to debug why I've faced a problem with scheduling. My instances stucks in 'scheduling' state. After enabling debug on nova-scheduler I've found that a host was selected. On nova-compute side there were 0 info about building an instance. It could be possible that the failure point is nova-conductor?
16:16:57	tasker	morning! couple of questions about nova metadata service: why ( and what for ) are there different dates in the URI? does "latest" coalesce the various other date entries and get all of the latest date from them? does "latest" count as a different date than the others? where is the metadata physically stored ( on disk or in a database )?
16:23:55	mriedem	sdague: efried: i'm surprised our docs don't say anything about configuring [neutron] with a user that has the admin role
16:24:01	mriedem	because we definitely require that
16:24:10	mriedem	for doing thigns with the port binding profile
16:24:29	mriedem	maybe the install guide does, but the config reference doesn't
16:26:36	mriedem	hmm, not here https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html
16:27:19	efried	mriedem This coming from https://review.openstack.org/#/c/509892/ ?
16:28:20	mriedem	no
16:28:23	mriedem	https://bugs.launchpad.net/cinder/+bug/1736773
16:28:25	openstack	Launchpad bug 1736773 in Cinder "attachment-show is including `connection_info` for non-admin callers, it shouldn't" [High,Triaged] - Assigned to John Griffith (john-griffith)
16:31:25	mriedem	https://docs.openstack.org/neutron/latest/install/compute-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service
16:31:35	mriedem	the networking install guide mentions it, but not sure if that 'neutron' user is an admin
16:33:01	mriedem	ah here it is https://docs.openstack.org/neutron/latest/install/controller-install-ubuntu.html#prerequisites
16:33:09	mriedem	"Add the admin role to the neutron user:"
16:33:35	mriedem	so if you've done everything correctly, things might work
16:33:53	mriedem	but i could see people creating a special networking user for nova to talk to neutron which is a service role rather than admin role or something
16:34:03	mriedem	assuming that's fine because the nova config section for [neutron] doesn't mention it
16:36:54	mriedem	https://docs.openstack.org/cinder/latest/install/cinder-controller-install-ubuntu.html#configure-compute-to-use-block-storage
16:38:42	openstackgerrit	Merged openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
16:42:45	efried	wohoo! ^
16:42:54	cdent	amazing
16:43:33	efried	What, you haven't written a script for that yet?
16:44:56	cdent	that would ruin the enjoyment
16:45:06	gibi	getting n-rp REST merged... it is almost like Christmas
16:48:08	mgagne	so I installed osc-placement, how can I use the CLI command? I tried with --os-beta-command and resource commands are not available.
16:48:11	mriedem	jaypipes: done https://review.openstack.org/#/c/465160/9
16:50:32	jaypipes	mriedem: cheers
16:52:39	openstackgerrit	Merged openstack/nova master: libvirt: Re-initialise volumes, encryptors, and vifs on hard reboot https://review.openstack.org/400384
16:54:17	mriedem	ildikov: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115093.html was the ML thread i was thinking of
16:55:21	bauzas	holy fsck, the libvirt driver doesn't know a shit about the compute node
16:55:22	ildikov	mriedem: cool, thanks
16:55:35	bauzas	like, it's not knowing the compute UUID
16:55:43	mriedem	bauzas: why should it?
16:56:18	bauzas	mriedem: since we're now passing the allocations, there will be a list of RP UUIDs with resources in them
16:56:26	bauzas	mriedem: for the moment, it's not a problem
16:56:34	bauzas	mriedem: given we don't support nested RPs
16:57:01	bauzas	mriedem: but once we'll have more than one RP for a compute, then we'll pass all the related allocations to the drivers
16:57:21	bauzas	then, how to know which one is for the root RP for example ?
16:57:22	mriedem	sure, but the fact we don't have something that we've never had a need for before shouldn't be shocking
16:57:36	mriedem	"wait, nova DOESN'T create ice cream?!"
16:58:07	bauzas	mriedem: sure, I understand that, but I thought we would at least know more than just the hostname :)
16:58:15	bauzas	anyway
16:58:25	bauzas	it's not a problem for me, but meh
16:58:47	mriedem	i'm assuming we'd have to pass the cn uuid down through spawn() yes?
16:59:14	mriedem	or have a hook into the driver that the compute manager can call to do whatever things it needs to do so the driver doesn't need to deal with placement directly
16:59:23	mriedem	ala the resource tracker
16:59:27	bauzas	yeah
16:59:32	stephenfin	mriedem: Question on https://review.openstack.org/#/c/507473/ - we're storing in the database but not exposing via the object. That's expected, right?
17:00:19	mriedem	stephenfin: we are, alwaysh have been
17:00:26	mriedem	the InstanceAction object extends the NovaPersistentObject class
17:00:36	mriedem	which has the timstamp fields
17:00:38	mriedem	*timestamp
17:01:02	stephenfin	Damn - I skimmed down to NovaTimestampObject and went no further
17:01:11	stephenfin	Fairs. That's done now
17:02:21	mriedem	thanks
17:07:25	stephenfin	mriedem: Side note - do we have a patch to populate this? Looking for review stuff to avoid more bug fixing https://specs.openstack.org/openstack/nova-specs/priorities/queens-priorities.html
17:09:35	efried	mriedem The plan is to have ComputeDriver.update_provider_tree, which we pass in a ProviderTree object. The driver will likely have to know its own compute node UUID so it can find it in that tree. But when it's done, the report client will take the updated ProviderTree and flush changes back to placement.
17:09:49	efried	bauzas ^
17:10:24	efried	mriedem bauzas There's some rough WIP at the top of the NRP series that gets a start on that. I'm noodling with it some more now.
17:10:36	mriedem	stephenfin: i haven't done it yet
17:11:42	bauzas	efried: ok, gtk
17:11:55	bauzas	efried: so the driver will know the tree, all good with me
17:12:43	efried	bauzas Well, yes, the driver will mostly be responsible for *creating* the tree. What it receives initially will probably just be the compute node provider (and maybe its traits).
17:12:56	bauzas	k
17:13:21	efried	bauzas At that point it'll be responsible for creating nested RPs (e.g. numa nodes, SR-IOV PFs, etc.) and possibly even sharing RPs; and setting up traits & aggregate associations.
17:14:32	bauzas	yeah I remember now that convo
17:18:53	efried	jaypipes cdent Here's a wrinkle: Can sharing RPs be trees?
17:19:02	efried	Hint: it'd be a lot cooler if they couldn't.
17:19:20	efried	I mean, it's clear that nothing is preventing you from doing that today.
17:19:27	efried	I'm saying we should consider whether that's a good idea.
17:23:33	mriedem	cdent: do you think https://review.openstack.org/#/c/518223/ is something we need to backport to pike?
17:24:16	cdent	mriedem: is a nice to have but not a need to have
17:25:27	cdent	efried: I think you and I have different mental models of rp trees. I think it should be theoretically fine for an rp which _happens_ to be part of a tree to be shareable but that it is in a tree shouldn’t be particularly meaningful
17:25:48	efried	cdent Okay, yeah, I think I'm discovering that.
17:26:16	efried	cdent This is coming from me trying to make sure the ProviderTree is fully populated before we hand it off to the compute driver.
17:26:25	cdent	what tree-ness would mean in that context is a path to get to
17:26:59	efried	I have to spider out from the compute RP's tree, grab all the RPs associated via aggregate, and populate the ProviderTree with those guys.
17:27:16	mriedem	cdent: ok
17:27:23	efried	So I was wondering what happens if one of those sharing RPs happens to be a child - do I *also* have to grab his whole tree and populate the ProviderTree with *those* guys.
17:27:39	efried	The answer I'm coming to is: No, I just pretend he's a root.
17:27:45	cdent	yes
17:28:12	cdent	at least at a first pass. it feels like you are working a bit ahead of yourself. solve the problem you have in front of your face, not all the problems you can imagine?
17:28:13	efried	So I may end up with multiple agg-associated sharing RPs that happen to be in the same tree, but they'll appear flattened as roots in the ProviderTree.

Earlier   Later