| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 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 | |
| 14:26:13 | lyarwood | mdbooth: IIRC cinderv3 should tell us if the connection is shared or not directly from the volume driver | |
| 14:26:16 | johnthetubaguy | so its the cinder driver that tells the cinder API what should happen | |