Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-22
14:21:51 bauzas dansmith: and the nova-status check pre-flight test could warn them if not
14:21:52 mriedem jaypipes: this week the new hotness is submitting a session idea to forumtopics.o.o
14:22:00 mriedem jaypipes: and those get voted on by the TC/UC/Foundation
14:23:30 mriedem if you want i can just submit something generic for placement,
14:23:39 jaypipes mriedem: go for it.
14:23:41 mriedem that will be mostly geared toward ops and devs
14:23:42 mriedem ok
14:23:57 mriedem i'll just take dansmith's cells abstract and s/cells/placement/ :)
14:24:06 dansmith heh
14:26:25 ttx mriedem: FYI http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-22.log.html#t2017-03-22T08:26:04
14:26:42 ttx mriedem: but then I also answered on the ML thread
14:27:16 mriedem yup i'm reading the ML now
14:27:25 dansmith mriedem: I just hit your uuid spec, btw
14:27:33 mriedem ok
14:37:46 jroll bauzas: thanks for the spec merge :)
14:40:06 stvnoyes good morning. I am having a lot of trouble in my devstack env after updating to latest. The error is "Failed to retrieve resource provider record from placement API". It seems to have started with this change: "virt: add get_inventory() virt driver API method". The [placement] info in nova.conf looks ok. any ideas? Thanks.
14:44:52 sfinucan jaypipes: I've what looks like a frickin' essay left in https://review.openstack.org/#/c/364468/ :D
14:46:21 jaypipes sfinucan: I shall respond, then, in haiku form.
14:48:26 cdent jaypipes will respond, in the form of a haiku, we all wait breath held
14:48:50 jaypipes cdent: :)
14:50:17 mriedem bauzas: you've got some unit test failures in https://review.openstack.org/#/c/391060/
14:50:39 mriedem stvnoyes: are you using ironic?
14:51:04 bauzas mriedem: yeah, need to address those
14:51:10 bauzas in a meeting atm
14:52:39 mriedem bauzas: ok, after your meeting, can you update the whiteboard on plans for https://blueprints.launchpad.net/nova/+spec/request-spec-use-by-compute
14:52:55 bauzas roger.
14:53:27 jaypipes sfinucan: done.
14:53:58 openstackgerrit Mikhail Feoktistov proposed openstack/nova master: Remove fstype param from ploop init https://review.openstack.org/444970
14:54:13 jaypipes sfinucan: I'm sure cdent will appreciate my review comment.
14:54:29 sfinucan jaypipes: Ha!
14:54:52 cdent nice
14:55:41 cdent jaypipes did respond, it was indeed an haiku, much celebration
14:55:51 cdent a not an, but close enough
14:56:31 stvnoyes @mriedem: no, no ironic
14:57:24 sfinucan jaypipes: Out of curiosity, where do weighers fit into resource providers?
14:57:53 sfinucan I'm assuming they'll be the same, only querying resources rather than nova-compute hosts directly?
14:58:00 sfinucan ...or something like that
14:59:19 dansmith sfinucan: I see filters as always being a nova only thing (or project only)
14:59:29 dansmith sfinucan: like, placement can replace a bunch of the filters, but not all
14:59:48 mriedem stvnoyes: then that patch would not impact you
14:59:59 mriedem stvnoyes: the only virt driver that implements that get_inventory method right now is the ironic virt driver
15:00:00 dansmith placement may be able to order things a bit, I guess, but the nova will always need some filters and weighers for very nova-specific things
15:01:34 sfinucan Makes sense. I fail to see how affinity groups would fit into the placement model
15:01:51 stvnoyes mriedem: hmm, ok thx. i will dig into it some more. It's got to be something in my env as no one else is seeing this.
15:02:37 jaypipes sfinucan: they don't currenlty.
15:03:32 jaypipes sfinucan: we return just the filtered set of providers to the scheduler and the scheduler pulls a giant ComputeNode.get_all_by_uuids() query and uses that information passed in to the weighers.
15:03:57 jaypipes and yeah, what dansmith said :)
15:13:11 sdague jaypipes: so how does that impact cross service placement if all the rules aren't in placement?
15:13:23 frickler mriedem: it seems you missed to update releasenotes/notes/libvirt-script-with-empty-path*yaml with https://review.openstack.org/448203, will you do a follow-up?
15:13:43 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in cloudpipe.py https://review.openstack.org/448271
15:13:45 jaypipes sdague: sorry, not following you. can you elaborate with an example?
15:14:24 sdague we are in a future where cinder is using placement. And there is a desire for locality between volumes and instances.
15:16:45 jaypipes sdague: if a nova instance is booted with a volume UUID, we would look up the traits and aggregates associated with the provider of that volume and winnow the set of compute node providers based on that list of traits and aggregates.
15:17:05 mriedem frickler: i guess i hadn't planned on updating that release note since it's already released
15:17:12 mriedem frickler: if we mention anything, it would be in a new release note
15:18:02 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in certificates.py https://review.openstack.org/448267
15:19:03 mriedem jaypipes: sdague: this also came up in the dev ML http://lists.openstack.org/pipermail/openstack-dev/2017-February/112903.html
15:19:06 mriedem for that exact use case
15:19:17 mriedem jaypipes: if you have thoughts or details on how to solves that, please reply to that thread
15:19:30 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in admin_actions. https://review.openstack.org/440829
15:19:56 jaypipes mriedem: ok
15:21:20 frickler mriedem: I think the release notes are confusing anyway. 14.0.4 lists the known issue, 14.0.5 doesn't list it anymore, so one could assume it being resolved there already
15:21:43 sneti johnthetubaguy, Can you please review https://review.openstack.org/#/c/396420/. I have just resolved merge conflict.
15:23:06 mriedem johnthetubaguy: on the host power action (shutdown/reboot) API, is the nova-compute service running on a separate host managing the backend hypervisor cluster
15:23:07 mriedem ?
15:23:42 mriedem johnthetubaguy: because otherwise the sync_instance_power_states periodic wouldn't be running if the nova-compute service is dead (because you stopped the host), and we wouldn't update the instance states to show them as shutdown
15:24:07 johnthetubaguy mriedem: not usually, its generally in a VM on that host
15:24:19 johnthetubaguy mriedem: yes, the power status stuff is all broken I suspect
15:24:48 mriedem ok, so if you run that api to stop your host, you effecitvely kill nova-compute managing the guests on that host :)
15:25:04 mriedem reboot would/should eventually come back, the service might be disabled for a time via the servicegroup health check,
15:25:06 johnthetubaguy yep
15:25:18 mriedem but otherwise the instances are never 'stopped' in the nova db status sense
15:25:19 johnthetubaguy I am fairly sure we only added that because the API was there
15:25:23 mriedem ha
15:25:32 johnthetubaguy the start is even crazier, thats just not possible
15:25:33 mriedem yeah i found that literally no backend supports host startup
15:25:43 johnthetubaguy ah, that makes sense
15:25:45 mriedem so we have an API that is just not supported, at all
15:25:57 mriedem there might be out of tree drivers, but...
15:26:03 johnthetubaguy yeah, I guess it must have been the old baremetal thing or something
15:27:22 mriedem ok i can check that old bm driver
15:28:31 mriedem frickler: btw i'll never remember your irc nick for who you are :)
15:28:38 mriedem if only you were just jens or something
15:32:41 frickler mriedem: that is too common here in germany. and I'll change my lastname in summer. I may consider a nick change, then ;)
15:36:25 nkorabli Hi there! I've got a little question about multitenancy in nova:
15:36:53 mriedem johnthetubaguy: even the old bm driver didn't support this stuff https://github.com/openstack/nova/blob/juno-eol/nova/virt/baremetal/driver.py
15:37:03 nkorabli login as demo user and create an instance .
15:37:04 nkorabli login as demo user and try to unshelve the instance shelved by admin user
15:37:04 nkorabli login as a admin user navigate to admin panel and shelve the instance (as admin user is able shelve any instance)
15:37:05 nkorabli expected : instance should be unshelved
15:37:06 johnthetubaguy mriedem: that is a mystery then :S
15:37:07 nkorabli Actual : instance is not shelved but is went to error state.
15:38:28 nkorabli I am sorry, for interrupting, though. But I just was wondering if that (what I've posted above) is expected or not?
15:38:45 openstackgerrit Hironori Shiina proposed openstack/nova master: Ironic: Support boot from Cinder volume https://review.openstack.org/215385
15:39:26 mriedem nkorabli: check your policy, can non-admins users unshelve in your deployment?
15:39:49 cfriesen mriedem: even if they couldn't, presumably it should just return an error message rather than put the instance into error state
15:40:03 mriedem cfriesen: true
15:40:07 mriedem policy fail would be a 403
15:40:13 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in baremetal_nodes.py https://review.openstack.org/448650
15:40:33 mriedem default policy for shelve is admin or owner

Earlier   Later