18:01:30 <adam_g> #startmeeting astara
18:01:32 <openstack> Meeting started Mon Nov 16 18:01:30 2015 UTC and is due to finish in 60 minutes.  The chair is adam_g. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:35 <openstack> The meeting name has been set to 'astara'
18:01:35 <adam_g> o/
18:02:13 <adam_g> last weeks notes @ http://eavesdrop.openstack.org/meetings/akanda/2015/akanda.2015-11-09-18.01.html
18:04:41 <adam_g> davidlenwell, markmcclain ryanpetrello elo anyona round
18:05:01 <elo> here
18:07:04 <davidlenwell> elo.. this is on my calandar for an hour from now
18:07:20 <davidlenwell> (that was suppsed to be short for hello)
18:07:45 <elo> LOL.
18:07:52 <adam_g> i guess we'll start
18:08:01 <elo> UTC timezone…that was my issue from last week
18:08:27 <adam_g> UTC stops for noone
18:08:44 <adam_g> #topic Outstanding project rename tasks
18:09:05 <adam_g> our devstack job is working again pending a change in neutron, which is still yet to merge
18:09:42 <adam_g> #action adam_g to see https://review.openstack.org/#/c/242775/ gets merged to reopen our gate
18:10:14 <adam_g> other than that, the devstack plugin and all associated config has been renamed at https://review.openstack.org/#/c/242629/
18:10:15 <adam_g> #link https://review.openstack.org/#/c/242629/
18:10:33 <davidlenwell> rad
18:10:39 <adam_g> * markmcclain to start the process of renaming modules akanda->astara
18:10:49 <adam_g> i think markmcclain is at a conference ATM but i know this is something he's still working on
18:10:55 <davidlenwell> so the reason that patch didn't merge is because it soft depends on that neutron patch ?
18:11:09 <adam_g> davidlenwell, yeah, and the neutron patch is taking a while to get reviewed
18:11:15 <davidlenwell> I see
18:11:16 <davidlenwell> okay
18:11:35 <adam_g> * adam_g update horizon rug->orchestrator
18:11:45 <adam_g> i made some progress on this frday, will carry over till next week (shoudl be pushing something today)
18:11:49 <adam_g> #action adam_g update horizon rug->orchestrator
18:11:57 <adam_g> begin migrating docs, renaming references: akanda->astara, rug->orchestrator (davidlenwell
18:12:04 <davidlenwell> I was holding back doc patches because I wasn't sure what was going on with that..
18:12:09 <adam_g> davidlenwell, i saw you migrated the old docs into the new repo
18:12:12 <davidlenwell> I'll push them all up today
18:12:33 <adam_g> davidlenwell, as in, the edits to rename the actual references akanda->astara ?
18:12:39 <davidlenwell> yes
18:12:44 <adam_g> ok
18:12:46 <adam_g> ill carry it over
18:12:50 <davidlenwell> k
18:12:50 <adam_g> #action begin migrating docs, renaming references: akanda->astara, rug->orchestrator (davidlenwell
18:13:15 <adam_g> those are the pending actions that require patches. other than that, #openstack-astara is now open and has bots there
18:13:35 <adam_g> i'll be shutting down the #akanda channel today. that is, making it readonly and hopefully pointing people to the new #openstack-astara
18:13:44 <adam_g> #action adam_g shuts down #akanda for good
18:14:00 <adam_g> #topic Mitaka Development
18:14:08 <davidlenwell> adam_g: you don't want to just leave it empty and chage the topic to point at the astara chanel?
18:14:40 <adam_g> davidlenwell, yes, that. except making it readonly so people have no choice but to move to new channel if they actually want to chat
18:14:49 <davidlenwell> ahh.. okay
18:15:01 <adam_g> #link https://blueprints.launchpad.net/astara/
18:15:19 <adam_g> so ive went ahead and filed skeleton blueprints for all the work items we discussed in tokyo
18:15:45 <adam_g> we should probably start getting these assigned to people, at least for things that are currently in progress
18:16:13 <davidlenwell> oh cool
18:16:32 <markmcclain> awesome
18:16:37 <adam_g> for the non-major things (ie, appliance API v2 API, Neutron flavors), i think we can skip the specs process
18:17:00 <adam_g> ive been working on beefing up functional testing last week, so i'll go ahead and grab the ci-updates-mitaka
18:17:02 <davidlenwell> I'd think a major api version up should have a spec
18:17:15 <adam_g> davidlenwell, doh, yeah, thats what i meant
18:17:30 <davidlenwell> ahh.. I see . that was your list of major things
18:17:31 <adam_g> ... for things that are not major (ie, appliance API V2 API)...
18:18:48 <adam_g> davidlenwell, would you want to take the docs blueprint? if you're going to be adding devstack support for the new features, documenting it while you go would probably make sense
18:18:52 <adam_g> ?
18:18:55 <davidlenwell> yep
18:19:05 <davidlenwell> yeah .. that was my plan..
18:19:10 <davidlenwell> already started on it..
18:19:13 <adam_g> cool
18:19:59 <davidlenwell> I guess I can't assign my self..
18:20:09 <adam_g> hmm
18:20:22 <adam_g> i might need to setup an astara drivers team instead of having everythign owned by me
18:20:47 <davidlenwell> good thinking
18:21:22 <adam_g> ... done
18:21:23 <adam_g> anyway
18:22:02 <adam_g> markmcclain, i take it youre still stuck detangling all of our messy imports as part of the rename effort? ill hold off on your BPs till thats done
18:22:20 <markmcclain> yeah... the circular imports are fun
18:22:47 <adam_g> k
18:23:39 <adam_g> so, as soon as that neutron patch lands we should be good to start flushing through all pending stuff. ill ping reviewers when thats done, hopefully today
18:23:42 <adam_g> moving on..
18:23:46 <adam_g> #topic open discussion
18:23:55 <adam_g> i had one thing to bring up here, looking at horizon last week
18:24:34 <adam_g> we currently configure horizon /w the prefix of the management network, and that is what the dashboard uses to determine where to contact the astara API
18:24:37 <davidlenwell> I was thinking that we could do better in the dashboard
18:25:01 <adam_g> https://git.openstack.org/cgit/openstack/astara-horizon/tree/akanda_horizon/rug_openstack_dashboard/api/rug.py#n23
18:25:54 <adam_g> this assumes 1) horizon has access to the management network 2) its going to be communicating to it via IPv6 3) the API is always going to be listening on the first address from that network
18:26:14 <adam_g> would it make more sense to instead code the canonical address of the API server in config? or even put it into keystone?
18:26:28 <adam_g> i hit this when trying to hack on horizon locally and point it at a remote astara instance
18:26:29 <davidlenwell> use keystone
18:26:37 <egon> +1
18:27:50 <adam_g> yea, that makes the most sense
18:28:01 <adam_g> markmcclain, any objections?
18:28:04 <markmcclain> yeah.. makes sense to horizon be able to discover the location of the server
18:28:33 <davidlenwell> will make it easier to update the setting globally if a node goes down in a multi-rug env
18:29:01 <adam_g> there'd be some associated work needed in astara-orchestrator, ATM it brings up the API server on the management network and doesnt let ops specify its listening address
18:29:04 <adam_g> ill file a bug about this
18:29:24 <adam_g> anyone have anything else to discuss?
18:29:33 <markmcclain> adam_g: I think the admin API is service is something that we need to talk a longer look at
18:30:12 <markmcclain> the original solution was a quick and dirty hack and bakes in many assumptions
18:30:27 <adam_g> markmcclain, yes, if we're advertising its endpoint in keystone we should probably start using keystone token auth on it as well
18:30:41 <davidlenwell> adam_g: +1
18:31:09 <adam_g> i think this could all fall within https://blueprints.launchpad.net/astara/+spec/astara-horizon-mitaka
18:31:17 <adam_g> markmcclain, did you have other ideas for improvements on the API?
18:32:21 <adam_g> as in, expanding it to be more than just an avenue for outsiders to dip into RPC via rug-ctl
18:32:29 <markmcclain> adam_g: yeah I think this is a start
18:32:53 <markmcclain> we could also consider if we want to make to just make this an extension loaded into neutron
18:33:04 <markmcclain> if we did that we'd get a lot of things for free
18:33:14 <davidlenwell> I think that makes a lot of sense
18:33:24 <elo> +1
18:33:33 <adam_g> markmcclain, not a bad idea
18:34:12 <adam_g> IIRC the API currently uses cliff to basically run the CLI. we'd need to break that up and have it issue its own messages on the notifications bus
18:34:16 <adam_g> but its doable fo sure
18:34:22 <markmcclain> right
18:35:30 <adam_g> okay unless anyone has anything else, i suppose we can call it
18:35:44 <davidlenwell> nothing from me
18:36:15 <markmcclain> nothing else from me
18:36:44 <adam_g> cool. cheers
18:36:46 <adam_g> #endmeeting