18:01:13 <adam_g> #startmeeting akanda
18:01:14 <openstack> Meeting started Mon Nov  9 18:01:13 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:16 <adam_g> o/
18:01:19 <openstack> The meeting name has been set to 'akanda'
18:01:35 <markmcclain> shouldn't we be using astara now?
18:01:38 <adam_g> https://review.openstack.org/243235
18:01:39 <adam_g> :)
18:02:09 <adam_g> good lead into
18:02:30 <adam_g> #topic Outstanding project rename tasks
18:02:57 <adam_g> so all of our project repos have been renamed
18:03:33 <adam_g> as expected, this wreaks havoc on our gate jobs
18:03:41 <adam_g> i think https://review.openstack.org/#/c/241559/ fixes it, at least it looks like its passing okay
18:04:32 <adam_g> im going to WIP that and comb over logs and make sure its doing what it should, then we should hopefully be able to merge it
18:04:44 <markmcclain> oh.. I added +2/A
18:04:53 <adam_g> yeah, just saw
18:05:03 <adam_g> im honestly surprised it passed
18:05:59 <adam_g> oh wait
18:06:04 <adam_g> im looking at the wrong things
18:06:13 <adam_g> https://review.openstack.org/#/c/242629/
18:06:25 <adam_g> thats the patch we need to get working before anything else will merge
18:06:52 <adam_g> it looks like its not currently running any jobs
18:07:08 <adam_g> #action adam_g to get astara CI functional again after rename
18:07:24 <adam_g> then we need to go through and start renaming code and packages
18:07:32 <markmcclain> let me know if I can help out with it
18:07:33 <adam_g> der, s/packages/modules
18:08:02 <adam_g> markmcclain, do you want to take the action of starting that process?  a first step would be to rename the top-level modules in the repos from akanda->astara
18:08:19 <adam_g> we managed to get the user-facing console scripts renamed already
18:08:22 <markmcclain> yeah.. I'm happy to take it on
18:08:34 <markmcclain> I know how not to do it :)
18:08:37 <adam_g> #action markmcclain to start the process of renaming modules akanda->astara
18:09:02 <adam_g> someone needs to re-doodle the ASCII art MOTD in the appliance
18:09:26 <markmcclain> I'll take it on
18:09:27 <adam_g> i will defer to the artist of the original (whoever that is)
18:10:06 <adam_g> so a question regarding the rename.. it looks like we dropped 'rug' in favor of 'orchestrator'?
18:10:16 <markmcclain> adam_g: looks like it was rods
18:10:42 <markmcclain> yeah just to be more clear what the processes were doing
18:10:47 <adam_g> im thinking we should be doing some aesthetic cleanups in various places if thats the case.. specifically the Horizon dashboard and dos
18:10:48 <adam_g> *docs
18:10:54 <markmcclain> ++
18:11:16 <adam_g> #action adam_g update horizon rug->orchestrator
18:11:21 <adam_g> and doc updates will be another on going task
18:11:28 <adam_g> davidlenwell, want to help there?
18:13:32 <adam_g> the crickets say YES
18:13:33 <adam_g> #action begin migrating docs, renaming references: akanda->astara, rug->orchestrator (davidlenwell)
18:13:58 <adam_g> markmcclain, anything else rename related you can think of?
18:14:11 <adam_g> im sure more things creep up as we go but those are some good next steps for this week i think
18:14:23 <markmcclain> yeah... these are a good starting point
18:15:15 <adam_g> #topic Mitaka development
18:15:55 <adam_g> so we released our liberty one week after neutron. in that time, i pinned our master jobs to run against stable/liberty of other projects
18:16:14 <adam_g> there seemed to be a change shortly after neutron mitaka released that broke our notification system
18:16:40 <adam_g> i tracked this down on friday to a change in oslo.messaging 2.6.0+, which is used in mitaka g-r now
18:17:19 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1513630
18:17:19 <openstack> Launchpad bug 1513630 in neutron "notifications are not being recevied since mitaka" [Undecided,In progress] - Assigned to Davanum Srinivas (DIMS) (dims-v)
18:17:38 <adam_g> oh looks like dims is helping with that, thanks dude.
18:17:59 <davidlenwell> o/
18:18:06 <dims> adam_g :)
18:18:07 <adam_g> once we straighten that out ill remove the pinning and we'll start running our mitaka against the rest of the world's
18:18:22 <markmcclain> ok.. makes sense
18:18:39 <adam_g> so looking forward
18:18:42 <adam_g> we came away from tokyo with: https://etherpad.openstack.org/p/akanda-mitaka-planning
18:19:24 * adam_g goes to find mitaka release schedule
18:19:31 <davidlenwell> reading scrollback.. adam_g yes I can help with the horizon changes
18:19:46 <adam_g> davidlenwell, no, i signed you up for doc updates :)
18:19:50 <davidlenwell> oh
18:19:52 <davidlenwell> okay
18:21:12 <adam_g> ive noted the currently proposed mitaka release schedule at the top of that etherpad
18:21:27 <adam_g> do we comfortable following that this time? we had trouble last cycle, and wonder if we should come up with our own schedule again
18:21:48 <adam_g> whichever we decide, we need to stick to that and land things by the milestones and not batch things up again for the final week
18:22:08 <markmcclain> right.. I'd like to align with the bigger cycle
18:22:14 <adam_g> same here, it looks doable
18:22:57 <davidlenwell> adam_g: +1 sticking to the upstream cycles seems the most logical ..
18:23:44 * adam_g starts weighting some of things we proposed in tokyo into buckets by milestone
18:24:35 <adam_g> actually no, i change my mind
18:24:51 <adam_g> we tried doing this last cycle and ended up with everything bumping and getting targetted to the RC
18:25:02 <adam_g> because we didnt properly scope things.
18:25:18 <markmcclain> yeah.. should we make sure there are the blueprints and bugs
18:25:33 <adam_g> i can say the most urgent (and possibly lowest hanging fruit) thing on the roadmap is devstack support for the new features we added in L
18:25:47 <adam_g> then we can start exercising those as part of our testing.
18:25:52 <markmcclain> agreed
18:26:06 <markmcclain> I'd like to see tempest up there too
18:26:08 <adam_g> yeah
18:26:27 <adam_g> should we start putting names next to things in etherpad so we know whos driving what until there are blueprints/bugs assigned?
18:26:56 <adam_g> also note: im moving rootwrap out of 'minor features' and into the main list. we really need to get on board with that
18:26:56 <markmcclain> yeah that makes sense
18:27:15 <markmcclain> that's mainly for the appliance right?
18:28:04 <adam_g> markmcclain, there, and we do some sudo'ing in astara-orchestrator as well
18:28:32 <markmcclain> yeah.. I guess to connect to the mgt networks
18:29:00 <adam_g> i know of some distributions whos' security teams will NACK inclusion of our packages because of unconstrained sudo use
18:29:03 <adam_g> anyway
18:29:13 <adam_g> ryanpetrello, you still up for helping improve the ceilometer support?
18:29:28 <adam_g> markmcclain, you've got containers PoC'ing?
18:29:34 <markmcclain> yep
18:29:42 <adam_g> i can take a look at VRRP/ha appliacnes
18:29:59 <adam_g> do we want to bump VPNaaS to stretch goals or keep it in the main bucket?
18:30:21 <adam_g> it sounded as if  FWaaS would be a more likely candidate at this point
18:30:22 <markmcclain> yeah.. I'm happy to help with VRRP stuff
18:30:23 <davidlenwell> that should be pretty low hanging fruit
18:30:27 <markmcclain> I've got a few thoughts on it
18:30:39 <davidlenwell> vpn
18:30:50 <adam_g> davidlenwell, low hanging fruit? how so?
18:31:00 <adam_g> (compared to FWaaS)
18:31:21 <davidlenwell> compared to fwaas vpn is a stable api that should meet our needs.. fwaas is in major flux right now
18:31:50 <adam_g> davidlenwell, oh, okay. so do you want to sign up for that? i was under the assumption you had already started working through fwaas
18:32:08 <adam_g> ill take on SFC, at least watching it and seeing where it develops this cycle.
18:32:11 <davidlenwell> I started a discovery spike on fwaas..
18:32:24 <davidlenwell> so yes.. I'll put my hand up for vpn
18:32:54 <adam_g> flavor support?
18:33:01 <adam_g> this is really two things
18:33:09 <davidlenwell> can you elaborate ?
18:33:19 <adam_g> we need pluggable backends for our adv. service drivers
18:33:22 <adam_g> (first step)
18:33:32 <adam_g> ie: loadbalancer needs to support different types of LBs
18:33:56 <adam_g> so the first thing is extended the abstraction in both astara-orchestrator and astara-appliance to support that
18:33:57 <davidlenwell> ahh . so rather than making an entirely new driver
18:34:03 <davidlenwell> you make a sub driver?
18:34:07 <adam_g> yea
18:34:22 <adam_g> the second thing is mapping that to neutron flavors
18:34:50 <davidlenwell> sounds like a little bit of an over abstraction
18:34:57 <markmcclain> so I think part of that is a bit of tweaking to how we integrate with neutron
18:35:12 <markmcclain> we could have neutron send us the driver for a flavor
18:35:18 <markmcclain> and make the orchestrator a bit dumb about it
18:35:19 <davidlenwell> like .. wouldn't it be less complex to just have seperate drivers for different types of lb's
18:37:52 <adam_g> davidlenwell, theres two layers of abstraction: one for the neutron adv. service API -> astara-orchestrator internal API (ie, the current top-level loadbalancer driver), and another for astara-orchestrator -> backend appliance
18:38:23 <davidlenwell> oh I see what you are saying
18:38:41 <markmcclain> there's also a bit of upstream coordination too
18:39:04 <markmcclain> https://review.openstack.org/#/c/223232/5
18:39:10 <adam_g> markmcclain, right, in either case we need some better way of managing multiple types of loadbalancers.
18:40:20 <adam_g> markmcclain, actually so that points to something that needs to be on our radar for mitaka wrt LBAAS.  we dont map cleanly in the 'provider' aspect of LBAAS
18:40:35 <adam_g> right now we can enable astara LBAAS via the nooplogging provider
18:41:02 <markmcclain> right.. I'm thinking we'll need a proper driver for Mitaka
18:41:11 <adam_g> if we went ahead and added our own astara provider, we'd still only have a single service level for multiple types of things we may be managing
18:41:31 * adam_g adds soemthing to the etherpad
18:41:48 <markmcclain> so with flavors you can pass metadata to that is handed down to the driver
18:41:57 <markmcclain> so that flavors can be differentiated
18:42:51 <adam_g> right but, at first glance, that patch you mention directly maps those to LBAAS providers
18:43:19 <adam_g> anyway, we can discuss this later
18:43:30 <adam_g> markmcclain, ill sign us both up for this/
18:43:42 <markmcclain> sounds good
18:44:10 <adam_g> davidlenwell, you have any interest in beefing up our devstack plugin to handle deploying new liberty features? (Pez, multiple RUGs, lbaas?)
18:44:23 <davidlenwell> yeah.. I was actually thinking I could handle that
18:44:41 <adam_g> cool
18:44:46 <davidlenwell> it will be good for bug testing too
18:45:04 <adam_g> we'd like to have that done soonish so we can start testing that stuff, so please schedule accordingly
18:45:16 <davidlenwell> I can make it a priority this week
18:45:19 <adam_g> k
18:45:33 <adam_g> ill sign up for the func. testing + tempest stuff unless someone else really wants it
18:45:56 <davidlenwell> (crickets)
18:46:15 <adam_g> the appliance API v2 thing is going to need a proper spec and some brain time
18:47:04 <adam_g> im going to leave that untagged atm
18:47:11 <davidlenwell> oh.. that reminds me .. where are we putting specs after the move?
18:47:12 <markmcclain> yeah.. I think that's smart
18:47:25 <adam_g> markmcclain, it sounded like you had an idea for TLS or was that ryanpetrello ?
18:47:34 <markmcclain> I've got one
18:47:46 <markmcclain> I can write it up as a bug (wishlist) item
18:47:48 <adam_g> davidlenwell, we can put them into astara.git for now
18:48:06 <adam_g> davidlenwell, im going to put up a patch that imports what was akanda.git/docs/ soon
18:48:14 <adam_g> we can just manage specs there?
18:48:18 <davidlenwell> ahh.. okay.. I could do that too if you like
18:48:23 <davidlenwell> yeah .. for now thats fine
18:48:40 <adam_g> markmcclain, cool
18:48:41 <davidlenwell> it makes those files end up in tar balls ...
18:49:07 <davidlenwell> with the releases .. but if that doesn't bother you it doesn't bother me
18:49:26 <markmcclain> aren't the files based on sdist?
18:49:32 <adam_g> davidlenwell, im fine with that, we could exclude them from release tarballs if we really want
18:49:52 <adam_g> i dont really wanna manage another astara-specs repo, we have enough repos :)
18:50:07 <davidlenwell> should I import the old stackforge/akanda/docs into the main repo as well?
18:50:16 <markmcclain> yes
18:50:25 <davidlenwell> or just piece by piece as I fix the docs?
18:50:30 <davidlenwell> like as seperate commits?
18:50:38 <adam_g> davidlenwell, i'd say import the whole thing and then make changes
18:50:46 <davidlenwell> okay
18:50:58 <adam_g> it'd be great if you could append 'Co-authored by' tags for the committer history of that dir
18:51:13 <adam_g> and a link to the openstack-attic repo where it its been retired to
18:51:20 <adam_g> that way we preserve some of the history
18:51:21 <davidlenwell> k
18:51:46 <davidlenwell> might be able to import the entire history ..
18:52:09 <davidlenwell> its git after all .. merging repos and keeping history is a thing
18:52:18 <markmcclain> that's sounds like some really gross git stuff
18:52:35 <davidlenwell> yeah it does induce vomiting
18:52:35 <davidlenwell> ;)
18:53:09 <adam_g> so for this coming week...
18:53:13 <adam_g> #action adam_g to get mitaka open for business /w functional CI
18:53:43 <adam_g> #action davidlenwell to get old docs imported, devstack plugin support for new features added
18:54:17 <adam_g> markmcclain, did you want to get cracking on something or will the code renaming be keeping you busy for now?
18:54:32 <markmcclain> code renaming will give a me a bit to do
18:54:41 <markmcclain> I expect we'll find some strange things
18:54:52 <markmcclain> (we did when we renamed quantum>neutron)
18:55:20 <adam_g> yeah, i imagine it will be fun
18:55:23 <davidlenwell> does it make sense to stack the devstack work on top of the name changes?
18:55:59 <markmcclain> We should be able to work in parallel
18:56:06 <adam_g> davidlenwell, no, this is about adding new support to our plugin to do the liberty new features.
18:56:19 <adam_g> https://review.openstack.org/#/c/242629/ addresses renaming
18:56:25 <markmcclain> if I do things right we should avoid most merge conflicts
18:56:32 <davidlenwell> okay
18:56:45 <adam_g> oh, conflict-wise it should be fine to happen in parallel, ya
18:57:27 <adam_g> #topic open discussion
18:57:33 <adam_g> anything else?
18:57:39 * adam_g needs coffee
18:57:43 <markmcclain> nothing from me
18:58:01 <davidlenwell> nothing from me
18:58:05 <elo> nope
18:58:05 <adam_g> cool
18:58:08 <adam_g> #endmeeting