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