Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-28
12:16:03 johnthetubaguy andymccr: if you configure the compute nodes to have the api-db point to the placement API, you might get what you want
12:16:04 johnthetubaguy its not officially supported right now, but thats probably what you want
12:16:06 johnthetubaguy oops
12:16:15 johnthetubaguy I mean placement-api conf has api-db point to placement-db
12:16:21 johnthetubaguy andymccr: ^
12:16:38 johnthetubaguy thats assuming all the tables are created in there now
12:16:53 johnthetubaguy but doing api-db sync on a node that has api pointing to placement
12:17:02 johnthetubaguy api-db pointing, that is
12:20:23 andymccr johnthetubaguy: not really looking to work around it until its ready i guess :) hoping there is a decent migration path though so its unobtrusive - just wanted to make sure i wasnt doing something bogus since the configuration is still in the sample conf with an explanation and recommendation that it is used.
12:20:39 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add use-local-scheduler spec https://review.openstack.org/438936
12:20:48 johnthetubaguy andymccr: its worth avoiding the migration path
12:21:05 johnthetubaguy andymccr: but we sure will have to write one
12:21:30 johnthetubaguy andymccr: BTW do you like the idea in this spec: https://review.openstack.org/438936 Basically give you less services you need to install and run
12:23:53 andymccr johnthetubaguy: reading - from our perspective fewer containers == better, if they aren't required it definitely makes sense to me
12:24:37 johnthetubaguy andymccr: cool, yeah, placement has changed the need for the separate process
12:51:15 breton hi
12:52:07 breton is it a known problem that having role admin in any project i can edit flavors for all users?
12:56:57 frickler breton: admin anywhere is admin everywhere, yes
12:57:43 breton ok, 968696 then
12:58:17 frickler yes, was about to paste that bug link ;)
12:59:22 alex_xu johnthetubaguy: sdague, just checked, there isn't any API work in the priority tasks, but i guess there still have some work can be tracked by the API team? so probably we can talk about that in the tomorrow api meeting
13:07:23 _samdeep Hi All
13:07:57 _samdeep I want to fetch instance properties inside a filter
13:09:01 _samdeep but I am unable to get it using
13:09:13 _samdeep objects.Instance.get_by_uuid(spec_obj.obj_context, spec_obj.instance_uuid)
13:09:30 _samdeep any idea how to get these details?
13:11:22 johnthetubaguy alex_xu: wasn't the policy docs included?
13:11:39 johnthetubaguy alex_xu: but yeah, we can keep meeting to keep the other stuff moving anywys
13:16:28 alex_xu johnthetubaguy: yeah, anyway if you and sdague have any plan or something you want me help on, let us talk that in the meeting
13:16:54 johnthetubaguy alex_xu: there was the API concepts guide that needed finishing, and a few other loose ends
13:17:07 johnthetubaguy alex_xu: we should go through that as a team at the next meeting I guess
13:17:21 alex_xu johnthetubaguy: yea
13:17:54 sdague alex_xu: yeh, I think the thing is that when we got there most of the mindset had been around policy and the limits setting api going into keystone
13:18:19 sdague I honestly think that limits in keystone would be something that we should keep api team focus on this cycle
13:18:54 alex_xu sdague: what is limits in keystone, i probably didn't follow that in the ptg
13:19:21 openstackgerrit John Garbutt proposed openstack/nova master: Add device_id when creating ports https://review.openstack.org/431545
13:19:24 sdague the new idea on how hierarchical quotas is going to work is that we're going to store limits in keystone
13:19:32 openstackgerrit John Garbutt proposed openstack/nova master: Stop leaking ports on port_create timeout https://review.openstack.org/347183
13:19:37 sdague so the entire hierarchy is efficiently mapped there
13:19:54 sdague brb
13:20:06 alex_xu ah, i probably have some memory about that
13:20:53 alex_xu I remember we said keystone need to tell nova about the hierarchy
13:21:36 alex_xu anyway i will grab the etherpad to get more context before meeting
13:26:21 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add prep-for-network-aware-scheduling-pike spec https://review.openstack.org/432489
13:32:11 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop using mox in compute/test_hypervisors.py https://review.openstack.org/326814
13:39:59 zioproto johnthetubaguy, I am about to build ubuntu packages on top of commit 2e05c82b807624b8420df4c94d68b75563b230d2 . Is that a good candidate for new stable/mitaka tag ?
13:40:36 johnthetubaguy zioproto: unsure, I would ask lyarwood about that
13:43:02 zioproto lyarwood, ping me when you are here :)
13:43:39 lyarwood zioproto: https://review.openstack.org/#/c/438570/ but I'd wait until the tag lands
13:44:32 sfinucan macsz: I wonder if it's time to look at switching back to nose, now that it supports parallel testing? :P https://review.openstack.org/#/c/435111
13:44:46 zioproto great that is the correct commit
13:45:20 lyarwood zioproto: right but I'd wait until the tag lands in the repo to build, we've already respun that to include an additional commit in the last 24 hours
13:45:29 lyarwood zioproto: it shouldn't be long until that lands tbh
13:48:12 zioproto thanks
13:55:09 bauzas johnthetubaguy: I do wonder, do we need to change some modules if we're just changing where a conf opt is set ?
13:55:24 bauzas johnthetubaguy: like the one you made about moving default_schedule_az
13:55:35 johnthetubaguy bauzas: its still looked up by doing CONF.xxx_xxx
13:55:42 bauzas yeah I know
13:55:46 johnthetubaguy bauzas: if the tests pass we should be fine
13:56:02 bauzas but I do wonder if we weren't explicitely saying "this or that"'
13:56:08 bauzas oh wait
13:56:12 bauzas that's a global opt
13:56:15 johnthetubaguy its not moving group, right
13:56:20 johnthetubaguy its just in the default group
13:56:21 bauzas we're only do that for groups
13:56:23 bauzas yeah
13:56:27 bauzas nevermind then
13:57:02 bauzas johnthetubaguy: FWIW, saw your spec about local scheduler, will review it soon
13:57:37 lyarwood hmmm is gerrit still messed up for anyone?
13:58:10 johnthetubaguy mine seems OK now, but its worth a shift-F5 maybe?
13:58:25 johnthetubaguy bauzas: that the one we discussed at the PTG
13:58:39 bauzas johnthetubaguy: yeah I remember
13:58:40 johnthetubaguy although I don't remember quite when we covered it
13:58:57 lyarwood ah there we go
13:59:00 bauzas tbh, sometimes my French tricks me during summits
13:59:08 bauzas but I was pretty following that convo
13:59:26 bauzas s/summits/f2f
14:08:34 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Fix races with nfs volume mount/umount https://review.openstack.org/383859
14:08:34 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Pass instance to connect_volume and disconnect_volume https://review.openstack.org/438970
14:20:51 mriedem mdbooth: so you plumbed an instance through for mount/unmount but i don't see where you are using the instance counting to tell when it's OK to unmount the volume in the case of multi-attach?
14:21:10 mdbooth mriedem: In the next patch. I explain in the commit message.
14:21:35 mdbooth mriedem: I could squish them together if you like, but as I explained in the commit message I think it's clearer this way.
14:22:06 mriedem next patch being https://review.openstack.org/#/c/383859/ ?
14:22:18 mdbooth Just makes it a bit easier to read imho, because this is a mechanical change which touches a bunch of files.
14:22:23 mriedem because as i commented in that change, i don't see where you're looking at the set of attachments for the same volume to see when it's fully gone
14:22:35 mriedem also,
14:22:39 mriedem this is jumping the gun a bit
14:22:49 mdbooth mriedem: Yeah, that one
14:23:14 mdbooth mriedem: Originally I thought so, which is why I removed it promptly when it turned out it was problematic.
14:23:27 mriedem i think the plan was,
14:23:43 mdbooth However, I keep hearing multi-attach noises, and this change allows it to work with multi-attach
14:23:50 mdbooth I don't want my code to be a barrier to that
14:23:56 mriedem we don't even call disconnect_volume on the volume driver if cinder is reporting more than one attachment for the same volume/host
14:24:20 lyarwood yeah that's the plan in the cinderv3 spec
14:24:27 mriedem that's in johnthetubaguy's spec somewhere
14:24:37 mdbooth Surely that's wrong, because it depends entirely on the volume driver implementation?
14:25:04 mdbooth If it's a direct attachment to the instance rather than eg a host mount, that's not going to work correctly
14:25:12 lyarwood https://review.openstack.org/#/c/373203/15/specs/pike/approved/cinder-new-attach-apis.rst@196
14:26:01 mdbooth Yeah, I don't think you can do that at the api level. It's a driver thing.
14:26:02 johnthetubaguy I am curious, reading the scroll back

Earlier   Later