18:00:33 <sarob> #startmeeting akanda
18:00:34 <openstack> Meeting started Mon Jun  1 18:00:33 2015 UTC and is due to finish in 60 minutes.  The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:39 <openstack> The meeting name has been set to 'akanda'
18:00:52 <sarob> roll call
18:02:15 <sarob> o/
18:02:17 <markmcclain> o/
18:02:28 <rods> o/
18:02:51 <davidlenwell> o/
18:02:53 <ryanpetrello> o/
18:02:55 <adam_g> o/
18:03:29 <sarob> helow helow
18:03:38 <sarob> agenda
18:03:45 <sarob> #link https://wiki.openstack.org/wiki/Meetings/akanda
18:04:06 <sarob> working off summit etherpad
18:04:25 <sarob> #link https://etherpad.openstack.org/p/liberty-akanda-design
18:04:37 <sarob> but summarized on the agenda
18:05:01 <sarob> #topic six month release cycle verses minor releases
18:05:07 <davidlenwell> sarob: make sure you copy the etherpad content some place .. openstack etherpad isn't at all stable
18:05:25 <sarob> davidlenwell: yeah, i have
18:05:31 <davidlenwell> l
18:05:41 <sarob> davidlenwell: im going to create the bp this afternoon as well
18:06:14 <sarob> so i have a few side conversations about minor releases
18:06:44 <sarob> and how the big tent stuff impacts / changes / effects the release cycle
18:08:18 <sarob> im thinking with the changes afoot plus the newishiness of the akanda project
18:08:19 <sarob> we should stick close to what the neutron project is doing
18:08:19 <sarob> as to not make us diff and maybe confusing
18:08:19 <sarob> what y'all think?
18:09:34 <adam_g> im not married to either approach, i just want us to have a release that coincides with the final openstack mileostne, which we can cut and maintain a stable branch from
18:09:44 <markmcclain> ++
18:09:47 <davidlenwell> I think staying behind neutron is our only real option.. but thts my humble opinion
18:10:43 <adam_g> we've already kinda aligned with the dominate versioning scheme (ie, 2015.1) so i think we should just follow that and revisit once other projects begin to migrate from that to something else
18:10:59 <adam_g> i'd hate to have to blaze that trail )
18:11:19 <sarob> anyone else opine?
18:11:40 <sarob> adam_g: fire is bad
18:12:09 <adam_g> the neutron plugin basically couples us to the neutron release cycle, no?
18:12:37 <adam_g> the api changed already in liberty in a way that broke us
18:12:50 <markmcclain> it does in terms of major branches, but do think we need to look at ways to get our features out sooner
18:13:27 <markmcclain> October is both a long and short time away depending on the feature
18:13:50 <adam_g> ya..
18:14:12 <davidlenwell> true story
18:14:17 <davidlenwell> considering how small our team is
18:14:48 <adam_g> it sounds like we need a hybrid approach
18:14:58 <sarob> so we work to release new features in each milestones
18:15:01 <sarob> adam_g: yeah
18:15:30 <markmcclain> adam_g: I think for this cycle yes
18:15:36 <markmcclain> for later cycles we should revisit
18:16:40 <sarob> sound like generally agreement to stay with current release style for this cycle
18:16:41 <adam_g> is it possible to have non-release tags in our repository for our own use?
18:17:17 <sarob> adam_g: so tags that we do not create packages off of?
18:17:18 <markmcclain> no idea what pbr will do with it
18:17:20 <adam_g> ie, we follow the liberty cadence for 2015.2, but also add tags to signify minor releases?
18:17:54 <adam_g> sarob, yea, i guess.
18:17:59 <adam_g> probably not an option
18:19:36 <clarkb> adam_g: markmcclain yes anything that isn't a version is ignored
18:19:43 <clarkb> at least it was prior to the semver updates
18:20:00 <markmcclain> clarkb: oh cool..thanks for clarifying
18:20:55 <sarob> so how would that work exactly?
18:22:06 <adam_g> sarob, just gives us hte ability to create tags that are meaningful to us as a project but not the rest of the world/infra
18:22:08 <sarob> setup.cfg meta version would be like 2015.2 or like 2015.2 foo
18:22:29 <adam_g> sarob, im talking strictly git tags
18:22:35 <sarob> adam_g: ah, okey so nothing to do with packagign
18:22:42 <sarob> adam_g: right
18:22:49 <adam_g> just an idea
18:22:57 <sarob> adam_g: im good with that
18:23:16 <sarob> most don't review tags too deeply
18:23:26 <sarob> move on?
18:23:38 <adam_g> with the multiple repos it would be handy for synchronization
18:24:02 <adam_g> sure
18:24:32 <markmcclain> yeah.. tags would be nice
18:25:38 <sarob> #topic summit bp prioritization
18:26:20 <sarob> so i went through the etherpad
18:26:31 <sarob> #link https://etherpad.openstack.org/p/liberty-akanda-design
18:26:43 <sarob> in the agenda
18:26:49 <sarob> and summarized them
18:28:08 <sarob> prob should add lbaasv2 api
18:28:33 <davidlenwell> on that subject.. wanted to pose a question to the group..
18:28:47 <davidlenwell> what do we think about running lb on the same vm as the router?
18:29:24 <markmcclain> davidlenwell: for some workloads that makes lots of sense
18:29:28 <ryanpetrello> yea
18:29:32 <ryanpetrello> ^
18:29:44 <markmcclain> for others it could be bad
18:29:47 <davidlenwell> sure.. probably optionally
18:30:20 <markmcclain> if the flavor framework lands
18:30:22 <adam_g> good use case for containers
18:30:40 <davidlenwell> containers are a nogo.. lb's will be comprimised
18:30:50 <davidlenwell> can't be trusted
18:30:54 <adam_g> davidlenwell, eh?
18:31:29 <davidlenwell> sure .. this was a long discussion early on in octavia..
18:31:45 <davidlenwell> an lb with a public ip is a target
18:32:15 <davidlenwell> if its in a container .. that means you are leaving the host more vulnerable
18:32:33 <adam_g> davidlenwell, so by that logic we shouldn't be adding that into the router vm either?
18:32:50 <davidlenwell> probably not
18:33:02 <adam_g> davidlenwell, i meant having VMs that host containers, with the ability to move containerized things between VM hosts
18:33:12 <davidlenwell> ahh .. well that does make sense
18:33:14 <adam_g> but anyway
18:33:37 <davidlenwell> okay.. we can move on now..
18:33:48 <sarob> okay
18:34:45 <sarob> so im thinking lm1
18:35:15 <adam_g> huh?
18:36:11 <sarob> liberty m1, last week of june
18:36:37 <sarob> bp as targeted for completion by m1
18:36:45 <adam_g> ah
18:36:52 <sarob> :)
18:37:04 <sarob> ive had all my coffee
18:38:04 <sarob> rug managd ssh key, doc updates, lbaasv2, juno backports, ci updates
18:38:07 <sarob> for m1
18:38:19 <davidlenwell> sounds reasonable
18:38:21 <ryanpetrello> sounds reasonable to me
18:38:30 <sarob> rest for m2, last week in july
18:38:37 <markmcclain> makes sense
18:39:15 <sarob> any missing bp in the agenda?
18:39:29 <adam_g> oslo updates
18:39:46 <markmcclain> good call those are a must
18:39:51 <adam_g> oslo.messaging migration is going to be a pretty significant change
18:40:04 <adam_g> the way we use kombu directly doesn't fit well into the existing oslo.messaging abstraction
18:40:25 <markmcclain> yeah.. was concerned about that
18:40:27 <adam_g> im working on that now, will hopefully ahve some patches up this week
18:41:48 <sarob> so the m2 bp would be
18:41:51 <sarob> m2 oslo, vm footprint, appliance HA, nodepool, appliance provision driver, octavia integ, rug reboot circuit breakers, VPNaaS with openVPN
18:41:56 <davidlenwell> after lunch with doug last week.. I can see how it would be more challenging than we thought
18:42:12 <davidlenwell> nodepool is going to be a big change in how the state machine works
18:42:54 <adam_g> sarob, if it matters i think oslo stuff can go to first milestone, once messaging is done the remaining stuff is minimal
18:43:10 <sarob> adam_g: im good with that
18:43:37 <ryanpetrello> yea, I'd say we should really spend some time thinking on the nodepool route
18:43:49 <ryanpetrello> as davidlenwell mentioned, it's going to be a *very* notable change
18:43:50 <adam_g> definitely needs a spec
18:44:02 <sarob> ryanpetrello: and working with ironic peoples
18:44:08 <davidlenwell> I'm already working on better diagrams of the state machine
18:44:15 <adam_g> sarob, what for/
18:44:38 <sarob> adam_g: how they dealt/dealing with state mgmt
18:44:55 <adam_g> most of the stuff in sarob's list for m2 is spec-worthy
18:45:22 * sarob says specs all around!
18:45:53 <markmcclain> yeah the m2 stuff is much bigger than the concise things in m1
18:46:02 <sarob> sooooo
18:46:08 <sarob> #info m1 bp rug managd ssh key, doc updates, lbaasv2, juno backports, ci updates, oslo
18:46:30 <sarob> #info m2 vm footprint, appliance HA, nodepool, appliance provision driver, octavia integ, rug reboot circuit breakers, VPNaaS with openVPN
18:47:07 <adam_g> cool
18:47:50 <sarob> ill start working up launchpad
18:48:14 <sarob> y'all want to start a spec patch or two,
18:48:26 <sarob> i wouldnt argue with it
18:50:02 <sarob> #topic any other random bits of business
18:50:40 <adam_g> my infra patches have started to land and theres a devstack job running in our experimental queue. will hopefully have that passing and voting soon
18:50:50 <markmcclain> nice
18:51:20 <ryanpetrello> \o/
18:51:57 <adam_g> granted its not going to be testing much after devstack, so we should think about what we want to run for tests
18:52:39 <sarob> any ideas?
18:53:13 <adam_g> we can identity some subset of tempest to run
18:53:16 <adam_g> to start with
18:53:19 <markmcclain> right
18:53:24 <adam_g> and then start to fill out akanda.rug.tests.functional
18:53:46 <markmcclain> did you see the review floating around for ovn.. where they're using a regex to controll which tests run vs updating the job def?
18:54:04 <adam_g> markmcclain, havent seen it but ive done similar things for ironic
18:54:15 <markmcclain> cool
18:54:56 <adam_g> one issue with regex is that new tests can slip into tempest that will fail against our deployment, but pass the regex, get run and block our gate :\
18:55:16 <markmcclain> yeah.. that's def a risk
18:55:19 <davidlenwell> that sounds unreliable
18:55:27 <adam_g> we can figure something out
18:55:47 <adam_g> not sure how different the akanda deployment is to reference and if we'd have that problem often
18:56:18 <markmcclain> we should be transparent except for any agent stuff
18:57:44 <sarob> anything else?
18:58:27 <markmcclain> not that I can think of
18:58:52 <sarob> #info adam_g has a devstack job running in our experimental queue
18:59:21 <sarob> okay ill call it then
18:59:34 <sarob> cheers!
19:00:03 <sarob> #endmeeting