Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-01
13:40:46 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/461386
13:40:51 edleafe ...or is it Trump's stupidity...
13:41:14 cdent symptom or disease?
13:42:59 mriedem sdague: alex_xu: if you want to remove nova-cert https://review.openstack.org/#/c/459460/
13:50:17 edleafe Scheduler subteam meeting in 10 minutes in #openstack-meeting-alt
13:53:39 mriedem efried: can you amend the service catalog spec for the glance.api_servers decision?
13:54:06 efried mriedem Sure thing.
13:54:16 mriedem thanks
13:59:57 sdague with the glance api_servers thing, it's unfortunate that we've got all these little bits of topology state sitting in config files, that you need to implement a topology management solution in config management
14:01:08 cdent sdague: there's been some discussion of that should be network and dns controlled, yeah?
14:04:07 sdague cdent: well, that mostly just moves a hard topology problem elsewhere, and I can definitely see not wanting to use networking to hide the addressing for the compute host <-> glance from a troubleshooting perspective
14:04:18 mriedem sfinucan: i'm guessing you have opinions on anything in https://review.openstack.org/#/c/450125/ re-using the nova-manage common code
14:04:45 cdent or even topological service catalogs?
14:06:28 sdague well, you actually need to put rack topology into the system somewhere for that to work
14:08:21 sdague anyway, it's unfortunate. The path out of it isn't super clear.
14:10:02 efried mriedem Is this blueprint an appropriate place to describe the changes in keystoneauth1 to load an Adapter from the conf?
14:11:18 mriedem efried: i don't follow, do you need to add something to ksa?
14:11:40 efried mriedem https://review.openstack.org/#/c/460337/
14:12:15 mriedem in laymans terms please
14:12:18 mriedem why do we need this
14:12:34 mriedem keep in mind i don't have ksa memorized like mordred
14:13:55 efried mriedem Yeah, been taking my lead from mordred here. The Adapter is a thing with service_type, interface, etc. defined on it. Adding a way to load one of _those_ guys from conf gives us a nice consistent way to get the new options into the appropriate conf groups from one centralized place, like we already do elsewhere for auth & session.
14:14:52 efried mriedem Initial patch set was going to add that centralized thingy in nova (https://review.openstack.org/#/c/458257/4/nova/conf/endpoint.py)
14:14:55 mriedem efried: ok is that necessary *now*? i mean, can't we do that cleanup/refactor later after we're using ksa at all?
14:15:18 mriedem i worry about building the perfect solution before we have any solution
14:15:25 efried mriedem Well, see above. It's... okaaayy... but it ain't pretty.
14:15:36 efried mriedem This is overall cleaner tbh.
14:16:07 efried Has traction from ksa cores.
14:16:11 mriedem i thought we were basically going to do the same thing we already do for ironic and placement, but for neutron, cinder and glance?
14:17:07 efried mriedem Yes, that's basically the idea. But we were still going to want a centralized place to define the necessary conf options (service_type, interface, etc.)
14:17:21 efried ksa Adapter was already that place - just needed some loading affordance.
14:18:11 efried mriedem Will make more sense once you see the next nova patch set. I get rid of that endpoint.py thing and just include the ksa loading in the relevant confs.
14:18:32 efried mriedem I have that code change done - was working on UT, but can post it now if you wanna see it.
14:18:33 mriedem honestly i haven't reviewed any of it
14:18:42 mriedem i'm in a meeting too,
14:19:15 mriedem jay and monty have been helping out here, so if there is an ideal path forward that makes this work and is less ugly, and has sufficient buy in from the ksa team to actually make progress before the 3rd milestone, then sure
14:19:16 mriedem go nuts
14:19:59 jaypipes mriedem: mostly mordred. :)
14:20:15 efried mriedem Roger that, going nuts. Since others have been engaged, I've been trying not to bug you with it, cause I know you're a busy dude.
14:21:52 efried mriedem So the question remains. I can leave the spec fairly vague in terms of where the centralized conf options are defined if you prefer. But at this point I feel like the design is pretty well hammered out, so I'd rather be explicit if possible.
14:22:39 mriedem the spec needs to be amended for the glance.api_servers thing anyway
14:22:48 mriedem if you want to add something high-level in there about ksa changes that's fine
14:24:26 efried mriedem Roger wilco.
14:26:31 openstackgerrit Jay Pipes proposed openstack/nova master: placement: get providers sharing capacity https://review.openstack.org/460798
14:26:32 jaypipes edleafe, cdent: ^
14:26:44 edleafe kewl
14:30:24 jaypipes cdent: since Andrey's on PTO for the next week, you think you could take over all the placement API ref patches and push fixes on them?
14:31:05 cdent a) I had planned to that last week, but didn't reach it, b)I thought he was back today-ish?, c) but if not, yeah
14:32:03 jaypipes cdent: cheers, appreciated.
14:33:04 openstackgerrit Matt Riedemann proposed openstack/nova master: Add compute_nodes_uuid_idx unique index https://review.openstack.org/454887
14:43:44 cfriesen_ I'm running into issues setting up devstack on Ubuntu...hitting an issue with keystone not starting. Anyone else seen this?
14:45:11 sdague cfriesen_: is this somewhere with accessable logs?
14:45:27 cfriesen_ sdague: yes, local dedicated mini-box
14:45:37 sdague cfriesen_: some changes were made in deployment defaults, the issue might be a service collision
14:49:25 cfriesen_ sdague: here's the output from stack.sh: http://paste.openstack.org/show/608527/
14:49:34 cfriesen_ I haven't found anything useful in /opt/stack/logs yet
14:50:16 sdague cfriesen_: what's in /etc/apache2/sites-enabled
14:52:19 cfriesen_ sdague: 000-default.conf keystone.conf keystone-wsgi-admin.conf keystone-wsgi-public.conf nova-placement-api.conf
14:52:30 sdague yeh, so that's the issue I expect
14:52:32 sdague one sec
14:54:30 cdent jaypipes: left some comments on the slides. Overall _very_ good. Some minor nits on naming, and a minor freakout about inbound notifications (dear god no).
14:54:39 sdague cfriesen_: if you pull https://review.openstack.org/461422 and do a ./clean.sh from there before your next ./stack.sh, I think you'll be good
14:54:53 cfriesen_ sdague: okay, will try it out
14:55:28 sdague cfriesen_: I think the issue is that keystone.conf is still configured the old way, and not being updated correctly
15:11:33 cfriesen_ sdague: it got further, but now I get an issue running "openstack project show admin": http://paste.openstack.org/show/608528/
15:19:17 mriedem dansmith: in case you didn't see yet, i went through your series to make discovering host mappings faster - the last change is outstanding
15:19:22 mriedem and i had some questions about upgrades in there
15:19:52 dansmith mriedem: I saw some of them were in the gate on friday yeah, thanks for that
15:20:22 dansmith mriedem: I'm still feeling really terrible and I'm probably only going to be around until I can get the doc to call in an rx for me
15:20:23 sdague cfriesen_: that apache dir?
15:20:30 dansmith but if I have a chance I'll look at that
15:20:39 mriedem dansmith: np
15:20:43 mriedem it's not urgent
15:21:00 cfriesen_ sdague: 000-default.conf keystone-wsgi-admin.conf keystone-wsgi-public.conf nova-placement-api.conf
15:21:05 mriedem 10000mg of z-pack is probably more important
15:21:43 sdague cfriesen_: well, that should at least be right
15:21:53 sdague cfriesen_: pastbin your local.conf?
15:22:16 sdague cfriesen_: sanity checking locally to make sure I didn't bork a thing
15:22:41 cfriesen_ sdague: http://paste.openstack.org/show/608529/
15:23:30 cfriesen_ sdague: the git repos are pointing at my dev box
15:24:01 sdague cfriesen_: yeh, all that should be sane
15:25:54 sdague cfriesen_: after a clean.sh are there any python processes still running that seem odd?
15:25:58 sdague like uwsgi ones
15:26:27 sdague the only thing I can imagine is there is an errant keystone, so it's magic token is different
15:30:30 cfriesen_ sdague: checking
15:33:39 lbragstad johnthetubaguy i took another stab at simplifying https://review.openstack.org/#/c/460344/
15:34:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add online data migration for populating services.uuid https://review.openstack.org/454899
15:34:02 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add Service.get_by_uuid method https://review.openstack.org/461429
15:34:02 openstackgerrit Matt Riedemann proposed openstack/nova master: db api: add get_service_by_uuid https://review.openstack.org/461428
15:34:27 lbragstad johnthetubaguy I'm going to propose a series of follow-on patches with more detail
15:35:31 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add Service.get_by_uuid method https://review.openstack.org/461429
15:35:31 openstackgerrit Matt Riedemann proposed openstack/nova master: db api: add service_get_by_uuid https://review.openstack.org/461428
15:36:02 cfriesen_ on another note...who's the person to talk to around virt.hardware.vcpus_realtime_topology() currently?
15:37:23 cfriesen_ sdague: no python processes running after unstack.sh/clean.sh
15:38:21 sdague cfriesen_: hmm... I don't know, things are starting fine here. How old are your clones of all the projects? Maybe something is required from keystone that I didn't realized
15:41:50 cfriesen_ sdague: it's been a while...and the box itself was upgraded in place from 14.04 to 16.04. maybe I should blow it away and start from scratch.
15:41:51 jaypipes cdent: thanks very much!
15:42:12 cdent the font is... concerning
15:42:15 cdent but you've made the most of it
15:42:49 jaypipes cdent: as I mentioned, it's the Mirantis Boston template...

Earlier   Later