Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-19
15:47:12 mriedem _ix: in ocata, you could configure nova to provide a service token for long-running tasks that involved cinder or neutron,
15:47:12 jaypipes sean-k-mooney: yup, got that up in gertty now.
15:47:15 mriedem that was expanded to glance in pike
15:47:24 TheJulia jaypipes: I took the red pill a long time ago.
15:47:29 jaypipes :)
15:47:30 _ix mriedem: This is... Juno.
15:47:40 mriedem _ix: well then you're f'ed :)
15:47:44 _ix Ha!
15:47:49 mriedem _ix: increase the token timeout i guess?
15:47:51 mriedem idk
15:47:59 _ix Is that in the nova.conf of the losing host?
15:48:06 mriedem yeah
15:48:17 mriedem but that service token stuff relies on things in keystone too
15:48:23 mriedem so you likely can't backport any of that to juno
15:48:42 mriedem TheJulia: yeah, >= 8.0 is wrong
15:49:19 TheJulia mriedem: any objection to just saying pike release?
15:49:41 mriedem ironic doesn't have a "pike" release does it? i thought ironic was too cool for such naming and boundaries
15:49:46 mriedem hence the release with intermediary tag
15:50:07 _ix mriedem: Is an 80gb ephemeral considered large?
15:50:18 mriedem _ix: 80gb is pretty large
15:50:36 _ix I suspected as much. Seems like the 20gb ephemerals migrated without issue.
15:51:06 jangutter sean-k-mooney, jaypipes: thanks. I think it's wise for the Mellanox CI to have the final say.
15:51:07 TheJulia mriedem: well, we've not cut 9.0 yet, so saying 9.0.0 is technically invalid as well
15:51:13 mriedem jaypipes: you have a handle on https://review.openstack.org/#/c/483565/ today?
15:51:28 mriedem TheJulia: that's why i said, >8.0
15:51:56 TheJulia ahh, yeah, that actually works
15:52:00 mriedem if there is 8.0.1 or 8.1 then idk
15:52:02 TheJulia because there is not an 8.x
15:52:05 mriedem ok
15:53:34 jaypipes mriedem: yeah.
15:53:52 jaypipes TheJulia: do you ever wish there was a --ffs-only option? :)
15:53:57 openstackgerrit Merged openstack/os-vif master: Add support for VIFPortProfileOVSRepresentor https://review.openstack.org/483921
15:54:11 TheJulia jaypipes: many times
15:54:17 _ix mriedem: I'm not seeing anything regarding timeout options for keystone_authtoken. Any other ideas?
15:54:49 TheJulia jaypipes: only reason I don't have an alias to bring the repo to the current state of master is because I may loose my current mental state of where things are at
15:54:56 ralonsoh stephenfin: hi. Can you take a look at https://review.openstack.org/#/c/449257/ and https://review.openstack.org/#/c/451777/? It could be a pity not to have this for Pike
15:55:03 jaypipes TheJulia: yup, same.
15:55:23 _ix mriedem: It also has a large volume attached in addition. Perhaps I need to detach before attempting to migrate?
15:56:08 mriedem _ix: the volume should be fine
15:56:24 mriedem nova will detach the volume on the source host and attach it on the target host
15:56:32 _ix Maybe a red herring, but the 401 appears to becoming from cinder?
15:57:19 mriedem _ix: at this point debugging a juno problem is beyond the realm of time i can spend on this
15:57:33 _ix mriedem: I understand. I appreciate the time you did give me.
15:57:36 mriedem what i can tell you is,
15:57:42 mriedem if the call is coming from within the house, get out
15:57:51 _ix To be fair, we're preparing for an upgrade in the coming months!
15:57:55 mriedem good luck
15:58:10 _ix Thanks.
15:58:16 jaypipes edleafe: hi! would you mind providing your opinion on ralonsoh's os-traits patch here? https://review.openstack.org/#/c/483451
15:58:35 jaypipes edleafe: I suppose I could go either way, but would appreciate another opinion.
15:58:40 jaypipes alex_xu: you too ^^
15:59:27 edleafe jaypipes: ok, will look in a bit
15:59:39 jaypipes edleafe: cheers
16:00:51 cdent can I look too jaypipes or is it seeekrit?
16:01:04 jaypipes cdent: of course!
16:01:07 cdent ;)
16:03:29 mriedem cdent: not sure if you saw my comment on https://review.openstack.org/#/c/484162/
16:03:37 mriedem i tried backporting to ocata and the test needs some changes there
16:03:40 mriedem since we don't have 1.7
16:04:05 mriedem i got past that but there was one more failure in the allocation request which i couldn't dig into
16:04:24 cdent mriedem: i did yeah, but haven’t had a chance to react. if you have some wip code and want me to pick it up I can do that
16:04:41 mriedem i might, se
16:05:06 cdent I also so your comments on the dansmith’s functional test now being a real failure. I’m not sure if I own that by default now or if dan wishes to return to that. either is fine with me.
16:05:12 cdent s/so/saw/
16:06:09 mriedem let's just ignore it for now
16:06:21 mriedem cdent: https://review.openstack.org/485263
16:06:55 cdent cool, will inspect, thanks
16:08:55 mriedem bauzas: it would be good if you could start going through this series https://review.openstack.org/#/c/408955/ - takashin has been really patient with rebases and that's been around a few releases now, but hasn't gotten review
16:10:08 bauzas mriedem: I did it a couple of times but I can do other cycles, for sure
16:10:20 openstackgerrit Merged openstack/nova master: Updated from global requirements https://review.openstack.org/484218
16:11:14 openstackgerrit Sylvain Bauza proposed openstack/nova master: Accept any scheduler driver entrypoint https://review.openstack.org/484828
16:11:25 bauzas mriedem: sean-k-mooney: ^
16:12:06 bauzas mriedem: sean-k-mooney english grammar nits welcome
16:13:50 bauzas jianghuaw: thanks for updating https://review.openstack.org/#/c/450122/20/specs/queens/approved/virt-add-support-for-vgpu.rst
16:14:14 bauzas jianghuaw: jaypipes: I had thoughts on that whether it was requiring nested RPs
16:14:26 jaypipes bauzas: yes, it does.
16:14:37 bauzas jianghuaw: jaypipes: tbh, I don't think we really need to wait for nested RPs if we can use custom RCs
16:14:48 openstackgerrit Ed Leafe proposed openstack/nova master: WIP - Migrate Ironic Flavors https://review.openstack.org/484949
16:14:49 bauzas lemme explain
16:15:00 edleafe cdent: Fixed the warning ^^
16:15:29 bauzas jaypipes: if we say that drivers can provide their own resource classes
16:15:53 bauzas jaypipes: and if operators provide custom RCs in flavors for defining how many "foos" we need to consume
16:16:07 bauzas jaypipes: why should we then requiring a parent/child relationship ?
16:16:22 bauzas for example, libvirt is not having a tight parent/child relationship
16:16:39 bauzas it's just providing a list of mediated devices having types
16:17:06 jaypipes bauzas: that's fine for a non-interoperable solution of course.
16:17:20 jaypipes bauzas: as soon as you have custom anything, you throw interop out the window
16:17:28 bauzas jaypipes: I don't disagree with your statement
16:17:51 bauzas jaypipes: I'm just saying that we have all the tooling in place for the feature
16:18:04 bauzas nested resource providers will give us more
16:18:08 sean-k-mooney bauzas: haha the only grammer/spelling corrections that i usally give are wrong. but ill take a look
16:18:28 mriedem bauzas: rather than rely on extra specs,
16:18:42 mriedem we will need to focus priority on actually getting nested RPs done in quens
16:18:46 mriedem for vgpus support
16:18:48 jaypipes bauzas: jianghuaw and I were trying to get GPU traits standardized in os-traits. once we have standard traits, you need resource providers to associate those traits to. and since different vGPU providers (pGPU groups) can have different traits, you need a way of saying "this pGPU group has these traits and this pGPU group has those traits". without nested providers, you can't do that.
16:18:51 mriedem and fpga and everything else
16:19:03 bauzas jaypipes: pGPU group is only a xen thing
16:19:19 bauzas mriedem: again, I don't disagree
16:19:25 mriedem bauzas: then why even bring it up?
16:19:30 jaypipes bauzas: or physical GPU... if you have >1 on a compute node.

Earlier   Later