Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-07
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.
17:28:40 efried cdent I agree with that in principle, but I have to code *something* here.
17:29:22 cdent efried: I assume you saw my comments on your commit messages needing to say more about why you are coding these *somethings*?
17:30:14 efried cdent One of them, which I updated - see if it satisfies: https://review.openstack.org/#/c/521097/
17:31:36 cdent efried: is there a spec or something where the reasons for the reason you gave (ComputeDriver.update_provider_tree) are explained?
17:31:55 efried jaypipes ^?
17:32:24 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: [placement] Fix an error message in API validation https://review.openstack.org/526465
17:33:03 cdent efried: I mean, I’m willing to take it as good simply because you guys are committed to it, but it easier to revie when I have a bigger picture
17:33:28 efried cdent I agree it would be neat to have a spec that calls out ComputeDriver.update_provider_tree.

Earlier   Later