Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-01
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: db api: add get_service_by_uuid https://review.openstack.org/461428
15:34:02 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add Service.get_by_uuid method https://review.openstack.org/461429
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: db api: add service_get_by_uuid https://review.openstack.org/461428
15:35:31 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add Service.get_by_uuid method https://review.openstack.org/461429
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...
15:42:54 jaypipes nothing I can do about that.
15:42:56 cdent yeah, I know
15:43:08 cdent that's why I think it is great that you've "made the most of it'
15:43:21 sdague cfriesen_: the 403 typically means there is a credentials mismatch with the keystone server
15:43:34 sdague cfriesen_: if you want to keep debugging it, that's the thread to follow
15:43:40 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Use plain routes list for os-floating-ips endpoint instead of stevedore https://review.openstack.org/461431
15:44:21 sdague it must be part of the cleanup, because it works in clean environments
15:45:23 cfriesen_ jaypipes: you +2'd this https://review.openstack.org/#/c/356383/ last year....just wondering why we have the implied "0-" as part of the mask. This means if the admin specifies "hw:cpu_realtime_mask=1" they actually get all the cpus, which seems odd.
15:46:48 jaypipes cfriesen_: how DARE you question my judgment!
15:46:58 jaypipes cfriesen_: heh, j/k :) will take a look.
15:47:38 cfriesen_ jaypipes: thanks...I also notice that this option doesn't seem to be documented in the manuals anywhere
15:47:48 cfriesen_ so I might have to fix that
15:47:59 jaypipes cfriesen_: that would be awesome if you did. ++
15:48:36 cfriesen_ jaypipes: I've got another manual fix under review for what happens when flavor/image specify different things for cpu policy, cpu thread policy, mempage size
15:48:59 jaypipes cfriesen_: link me and I'll add it to my queue.
15:49:08 cfriesen_ jaypipes: cool, will do
15:49:18 jaypipes danke
15:54:03 cdent jaypipes: the new hotness on placement+uwsgi can be teased out of the results of https://review.openstack.org/#/c/456717/ but it's not immediately apparent without doing some digging so I'm not sure if it is worth it. May be easier/more simple for the sake of the presentation to say "it's just a simple wsgi app, run it with anything!"
16:02:43 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Use plain routes list for os-floating-ip-pools endpoint instead of stevedore https://review.openstack.org/461436
16:11:21 dansmith mriedem: hmm, looks like I never uploaded the patch set that fixed the setting mapped=1 thing
16:11:34 dansmith mriedem: and it's not in my local tree since I pulled from gerrit over this at some point
16:11:47 dansmith that method looked quite different in that version
16:13:30 openstackgerrit Matthew Treinish proposed openstack/nova master: Remove cloudpipe APIs https://review.openstack.org/459470
16:13:38 mtreinish mriedem: ^^^ part 2 to close out the spec
16:13:45 mriedem mtreinish: excellent
16:15:16 openstackgerrit Matthew Treinish proposed openstack/nova master: Remove cloudpipe APIs https://review.openstack.org/459470
16:15:36 jaypipes mriedem: looks like another unit test would be affected by the compute_nodes.uuid unique index: http://logs.openstack.org/87/454887/4/check/gate-nova-python27-ubuntu-xenial/e5b8b91/testr_results.html.gz
16:15:45 jaypipes mriedem: I blame dansmith ;)
16:15:50 mriedem gah
16:15:51 mriedem ok
16:24:00 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Use plain routes list for os-floating-ips-bulk endpoint instead of stevedore https://review.openstack.org/461439
16:28:55 jaypipes cfriesen_: reviewed. good stuff.
17:23:32 cfriesen_ but anyone that actually cares should probably specify which they want, so I'm not too worried about it.
17:23:41 jaypipes cdent, edleafe: maybe it would help if I just push the remainder of the patch series so you can see the end result.
17:23:49 openstackgerrit Dan Smith proposed openstack/nova master: Make discover_hosts only query for unmapped ComputeNode records https://review.openstack.org/427903
17:24:19 dansmith mriedem: I was thinking, we could make the scheduler call the host discovery on SIGHUP, which may be more straightforward (i.e. you have to SIGHUP the scheduler to notice new hosts
17:24:25 edleafe jaypipes: I sure hope so :)
17:24:35 jaypipes edleafe: thanks for the encouragement.
17:24:42 cdent jaypipes: could be, but it is also very useful for the rest of us who are not in your brain to actually talk about it and figure out the larger context of what's going on. For example my latest comment is basically about what "typical" is.
17:24:57 cdent think of this as an educational opportunity™
17:25:08 cdent a union of souls over one page
17:25:55 jaypipes cdent, edleafe: are you essentially asking me to add a "agg_ids" argument to _get_providers_sharing_capacity() that would winnow the resulting provider ID list to only the aggregates that have been previously selected in ResourceProviderList.get_all_by_filters()?
17:25:59 openstackgerrit Chris Friesen proposed openstack/nova master: Tweak the cpu_realtime_mask handling slightly https://review.openstack.org/461456
17:26:11 cfriesen_ jaypipes: what would you say to something like this?
17:26:59 edleafe jaypipes: no, not if you are then going to use that in a future join expression.
17:27:20 edleafe jaypipes: there wasn't any indication in the code that this would be happening
17:27:24 jaypipes edleafe: precisely my plan, yes.
17:28:05 jaypipes edleafe: what do you mean there wasn't any indication in the code? you mean the code comments didn't say how I'd be using the result of _get_providers_sharing_capacity()?
17:28:07 cdent jaypipes: I'm not asking for a specific action, I'm simply trying to understand the intent and more importantly the context within which the stuff is going to operate. without that I can't review very effectively
17:28:25 edleafe jaypipes: your since-corrected comments also made it sound like it was going to be "in the same aggregate"

Earlier   Later