18:00:13 <sarob> #startmeeting akanda
18:00:15 <openstack> Meeting started Mon Jun  8 18:00:13 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:18 <openstack> The meeting name has been set to 'akanda'
18:00:38 <sarob> agenda
18:01:04 <sarob> #link https://wiki.openstack.org/wiki/Meetings/akanda
18:01:11 <sarob> roll call
18:01:38 <adam_g> o/
18:02:17 <davidlenwell> o/
18:03:10 <markmcclain> o/
18:03:51 <sarob> #topic milestone 1 bp progress
18:03:57 <sarob> #link https://launchpad.net/akanda/+milestone/liberty-1
18:04:03 <arosen1> o/ hiya :) Just lurking
18:04:26 <sarob> arosen1: lurking welcome ;)
18:05:16 <sarob> is ryanpetrello around?
18:06:18 <sarob> markmcclain: any updates on juno backports?
18:06:46 <sarob> markmcclain: i remember it being close, but a few remaining bugs to work out
18:06:46 <markmcclain> ryan's confirmed they mostly work w/o any changes from stable/kilo
18:08:16 <sarob> so branch stable/juno off stable/kilo?
18:08:33 <sarob> that was bounced around
18:08:40 <adam_g> thats the plan
18:09:06 <sarob> so id delete stable/juno branch that exists for a few of the repos first?
18:09:22 <sarob> and create new one
18:09:26 <sarob> s
18:09:42 <markmcclain> yeah.. the old stable/juno branch contains some cruft we removed for kilo
18:09:56 <markmcclain> so the new stable/juno branches would be much cleaner than the old version
18:10:24 <sarob> is that a fungi request?
18:10:56 <fungi> no requests are fungi requests ;)
18:11:09 <sarob> fungi: hah
18:11:16 <fungi> but i'm happy to take care of infra admin requests, sure
18:11:30 <fungi> if you need a branch deleted, i'm happy to
18:11:38 <fungi> just get up with me after your meeting
18:11:43 <sarob> fungi: thx!
18:12:03 <sarob> next up are oslo updates bp
18:12:19 <sarob> #link https://blueprints.launchpad.net/akanda/+spec/oslo-updates
18:12:35 <sarob> adam_g: how goes it?
18:12:56 <adam_g> i switched off of that last week to focus on getting our ci rolling after some infra patches merged, gonna pick it back up today
18:13:27 <adam_g> markmcclain, were you involved with designing the existing messaging layer in the rug or is that something i should pick doug's brain about?
18:13:44 <markmcclain> doug did a lot of the heavy lifting
18:14:04 <markmcclain> I've got good coverage there too
18:15:02 <sarob> #action sarob will branch new stable/juno off stable/kilo once some of the old stable/juno branches are removed
18:15:04 <adam_g> ok, cool. ill have some questions about how we adjust it to fit with oslo.messaging. we do some rabbit specific stuff that will need to change, probably
18:16:37 <sarob> #info adam_g will restart oslo work today
18:17:22 <sarob> documentation updates bp
18:18:28 <sarob> i'll work on collecting the notes from the summit on whats missing
18:18:32 <sarob> in the docs
18:19:00 <sarob> part of it is we need to add a job to update the docs
18:19:14 <markmcclain> we merge the rest update this morning
18:19:20 <markmcclain> I'm guessing the post hook isn't working?
18:20:16 <adam_g> theres a patch up to add those hooks to our project post-job
18:20:35 <adam_g> https://review.openstack.org/#/c/188909/
18:20:56 <adam_g> the actual server-side hook is working, http://akanda.readthedocs.org/en/latest/ is updated after a manual build
18:21:28 <adam_g> should we only worry about the docs in the `akanda` repo, or be maintaining docs in the sub-projects?
18:21:44 <markmcclain> I think 1 set of docs makes the most sense
18:21:59 <adam_g> ATM akanda and akanda-rug both have docs dirs
18:22:08 <sarob> adam_g: yeah, one place makes the most sense
18:22:11 <adam_g> we should move the -rug docs over to akanda then
18:22:18 <sarob> adam_g: yup
18:23:01 <sarob> #action sarob will move akanda-rug docs to akanda repo
18:23:43 <sarob> we can start adding inline comments as part of this bp
18:24:09 <sarob> maybe starting with oslo
18:24:29 <sarob> since the team is figuring it out together
18:25:22 <sarob> adam_g: sound good?
18:25:37 <adam_g> sarob, im not sure what you mean
18:25:44 <adam_g> but it sounds good :)
18:26:38 <davidlenwell> I think what he is trying to say that its going to be a group effort to get inline code docs written into all of our files
18:26:56 <sarob> yeah, that
18:28:12 <sarob> sooo, lbaas support
18:28:22 <davidlenwell> nice segway ;)
18:28:45 * sarob wonders why he mentions my segway
18:29:17 <davidlenwell> a lot of us were just in a video call with the nginx team discussing plans for getting a load ballancer working and ready to use in a production env
18:29:17 <sarob> davidlenwell: whats up with lbaas support
18:30:32 <davidlenwell> I am currently in the process of modifying the worker code that runs on the router vm to act as a shim layer between nginx and the neutron lbaas messages in the message queue
18:31:12 <davidlenwell> along with that I am also still modifying our state machine to support drivers for higher level services in general
18:32:06 <davidlenwell> I'd like to sit down with sarob this week and nail down a timeline and deliverables schedule so that we can better manage the expectations of the nginx crew
18:32:18 <sarob> davidlenwell: we got a rundown from doug on state machine code
18:32:47 <sarob> davidlenwell: one of the meetings soon, you provide an update to the team on the state of
18:32:56 <davidlenwell> sarob: yes.. and I have a patch in flight that modifies that to work with non-router vm's.. however.. now I have to rebase and resplve some conflicts
18:32:58 <sarob> davidlenwell: well, state machine
18:33:13 <sarob> davidlenwell: okay
18:34:03 <sarob> davidlenwell: between the changes adam_g and you are doing, it would be good to be able to update the rest of us
18:34:47 <davidlenwell> I'm not sure if anything adam_g is doing will effect what I am doing.. I don't understand the differences between the rabbit specific things in our code and how oslo messaging works
18:35:10 <sarob> maybe post m1 would be the ideal time
18:35:40 <davidlenwell> for what specifically?
18:35:55 <sarob> no, im not saying that
18:36:18 <sarob> im saying y'all are learning stuff about how stuff works
18:36:34 <davidlenwell> yeah.. lots of discovery things are happening right now
18:36:35 <sarob> so explaining how stuff works would be a good idea
18:36:48 <davidlenwell> its hard to nail down a timeline while we are in this state with how the messaging stuff works
18:36:51 <sarob> so everyone knows how stuff works
18:37:03 <sarob> okay
18:37:09 <sarob> sometime in the future
18:37:15 <sarob> nearish
18:37:32 <sarob> anything else?
18:37:34 <davidlenwell> well as I go and change things I'll make diagrams and write stuff down into code and in docs
18:37:39 <davidlenwell> on lbaas .. no
18:37:45 <sarob> davidlenwell: right on
18:38:55 <sarob> davidlenwell: still on schedule for m1 though?
18:39:20 <davidlenwell> roughly .. we can nail down a specific timeline while I am in the office this week
18:39:32 <sarob> davidlenwell: okey dokey
18:39:42 <sarob> moving on to
18:39:49 <sarob> ci updates
18:40:06 <sarob> adam_g: anything more to add on this?
18:40:19 <adam_g> nope. our devstack jobs are almost there
18:40:26 <adam_g> after a mountain of patches that landed today
18:40:29 <sarob> sweeeeet
18:40:36 <adam_g> should have it running this week on patches and we can start filling out the actual tests after
18:40:41 <markmcclain> awesome
18:41:42 <sarob> any updates on m2 bp?
18:41:48 <sarob> #link https://launchpad.net/akanda/+milestone/liberty-2
18:42:44 <adam_g> none here
18:42:58 <sarob> #info adam_g devstack jobs running this week
18:43:08 <markmcclain> none from me
18:43:54 <sarob> #topic any other business
18:44:27 <sarob> how about the bps
18:44:43 <sarob> still seem like we have the right ones?
18:44:56 <sarob> #link https://blueprints.launchpad.net/akanda
18:45:22 <sarob> we have 9 pushed out
18:46:41 <davidlenwell> beats per second or blue prints?
18:46:46 <davidlenwell> ;)
18:46:57 <sarob> both
18:47:34 <sarob> it seems right to me
18:48:19 <sarob> how about the priorities?
18:48:42 <markmcclain> priorities for now are still on track
18:49:38 <adam_g> its hard to tell without having any context in the blueprints themselves
18:49:55 <adam_g> but based on what i remember from last meeting it looks ok
18:50:08 <markmcclain> adam_g: oops.. meant to say the priorities are still in the right order
18:50:09 <puranamr> markmcclain, the reduce vm footprint bp, is referring to reducing startup time or reducing the image size?
18:50:17 <markmcclain> puranamr: both
18:50:37 <sarob> markmcclain: i kinda assumed thats what you meant
18:50:41 <puranamr> i would like to work with whoever is assigned to,
18:51:19 <puranamr> markmcclain, what is the startup time we are aiming for (rough numbers will do)
18:51:42 <markmcclain> puranamr: it's currently unassigned
18:51:52 <puranamr> yeah i see that :)
18:51:52 <markmcclain> puranamr: as fast as we can make it
18:52:00 <markmcclain> I don't have a hard target
18:52:24 <sarob> puranamr: whats the startup time now?
18:52:36 <sarob> approx
18:52:41 <puranamr> pl speak up some number to start off, lets aim and see how far we can get
18:52:53 <puranamr> sarab, it is order of couple of minutes i think
18:53:01 <adam_g> VM startup time is dependent on too many variables to use as a target
18:53:28 <puranamr> and the vm image size is around 430 M compressed, so what r we thinking here
18:53:36 <sarob> adam_g: yeah, true
18:53:37 <markmcclain> adam_g: right
18:53:56 <adam_g> having nodepool pre-provision VMs for us would help significantly, if we decide to go that route
18:53:59 <sarob> need a baseline of sorts
18:54:03 <sarob> though
18:54:23 <davidlenwell> adam_g:  that is going to drastically effect how the state machine works
18:54:26 <adam_g> i think reducing image size is a more realistic goal
18:54:34 <markmcclain> adam_g: yeah node pool will help
18:54:46 <sarob> so that brings up a good point
18:55:06 <sarob> we need to specs for nodepool and reduce vm footprint bps
18:55:13 <adam_g> puranamr, that 430M is a standard debootstrap'd debian installation. we can probably start to audit whats installed there and pick out packages of stuff we dont need
18:55:15 <davidlenwell> those are very seperate
18:55:25 <adam_g> puranamr, or look at replacing debian entirely with something leaner
18:55:42 <sarob> so we understand how the work breaks down
18:55:43 <puranamr> adam_g, reducing would be a good starting point.
18:55:57 <adam_g> puranamr, have you looked at building your own appliance VM to see how the build process works?
18:55:58 <puranamr> adam_g, Yes that was the question i had, as to why debian
18:56:10 <puranamr> adam_g, yes
18:56:34 <adam_g> puranamr, cool
18:57:17 <sarob> puranamr: so maybe you can take on the vm footprint bp?
18:57:23 <puranamr> actually both are slightly tangential ( i mean size vs startup time) which we need to take up first will help focus us better
18:57:33 <sarob> with leaning on the team for help on contribution
18:57:42 <puranamr> sarob, sure!
18:58:13 <sarob> #action puranamr will take on reduce-vm-footprint m2 bp
18:58:21 <sarob> 2 minute warning
18:58:30 <sarob> any last words?
18:59:01 <puranamr> should we split the bp into two parts
18:59:10 <puranamr> one for size and one for startup times?
18:59:27 <sarob> puranamr: lets start the specs first
18:59:31 <sarob> spec
18:59:33 <puranamr> ok
19:00:00 <sarob> then decide if its too unwieldy
19:00:05 <sarob> all done
19:00:07 <sarob> cheers
19:00:18 <sarob> #endmeeting