Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-22
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 a admin user navigate to admin panel and shelve the instance (as admin user is able shelve any instance)
15:37:04 nkorabli login as demo user and try to unshelve the instance shelved by admin user
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
15:40:39 mriedem so the demo user that created the instance should be able to unshelve it
15:40:53 mriedem the error is probably due to the instance actually failing to unshelve, i.e. spawn on a host
15:41:05 mriedem which is not a policy issue, just an issue
15:41:25 mriedem nkorabli: so check the conductor, scheduler and nova-compute logs for failures
15:41:25 nkorabli oh, alright...
15:41:27 mriedem for the unshelve
15:41:40 mriedem it should be pretty obvious if the instance is in ERROR state
15:42:07 nkorabli Got it! Let me check that..
15:42:18 nkorabli Thanks a lot!
15:44:20 mriedem alex_xu: did you want me to specifically call out that the search-related GET methods for os-hypervisors will not be changed in https://review.openstack.org/#/c/447149/1/specs/pike/approved/service-hyper-uuid-in-api.rst@117 ?
15:45:40 mriedem sdague: johnthetubaguy: dansmith: thoughts on https://review.openstack.org/#/c/447149/1/specs/pike/approved/service-hyper-uuid-in-api.rst@128 and if we change the value of the id key to be a uuid value, or add a uuid key to the response, or completely drop id and just return a uuid key?
15:45:57 mriedem server.id response is a uuid, but aggregates response has both id (int) and uuid
15:46:14 dansmith mriedem: I'm fine eitther way
15:46:20 mriedem ok
15:46:21 dansmith tend to thing re-using id is easier
15:46:22 openstackgerrit Gábor Antal proposed openstack/nova master: Ensure instance is in active state after notification test https://review.openstack.org/448655
15:46:23 dansmith *think
15:46:30 mriedem dansmith: that's what i was originally planning too
15:47:11 mriedem shit, now that i mention aggregates https://developer.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail#host-aggregates-os-aggregates
15:47:16 mriedem /os-aggregates/{aggregate_id}
15:47:19 mriedem is the primary key int
15:47:30 mriedem dansmith: have you gotten to aggregates in your multi-cell api series yet?

Earlier   Later