20:01:33 <sdake> #startmeeting kolla
20:01:34 <openstack> Meeting started Mon Apr 27 20:01:33 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:38 <openstack> The meeting name has been set to 'kolla'
20:01:50 <sdake> #topic rollcall
20:01:55 <daneyon> hey
20:01:57 <rhallisey> hello
20:02:01 <docaedo> hi
20:02:02 <sdake> o/ folks
20:02:03 <jpeeler> hey
20:02:45 <sdake> #topic meeting time change
20:02:57 <sdake> we have many more contributors from apac
20:03:17 <sdake> but unfortunately they can't attend our irc weekly meeting because its like 4am their time
20:03:35 <sdake> I would like to alternate meeting times between 1600 utc and 2300 utc
20:03:36 <harmw> yea, well 10pm isn't all that funny either
20:03:41 <harmw> :p
20:04:06 <sdake> this should allow ust o increase our development velocity
20:04:07 <harmw> anyway, sdake good point
20:04:20 <sdake> thoughts concerns etc?
20:04:50 <sdake> mstoly looking for feedback from the core team here :)
20:04:58 <rhallisey> I'd vote 1600
20:05:05 <harmw> who is the core team anyway :)
20:05:20 <sdake> we need to alternate to hit all parts of the world
20:05:21 <rhallisey> well alternating can make it harder to follow
20:05:31 <sdake> calendar should solve that problem easily
20:05:36 <daneyon> makes sense to alternate
20:05:46 <sdake> can update channel topic with next meeting scheduled time as well
20:05:48 <rhallisey> ya I'll just have to make a reminder
20:06:01 <sdake> ok here is what i'm going to do
20:06:10 <sdake> I'll send a doodle poll to openstack mailing list
20:06:11 <sdake> with some times
20:06:25 <daneyon> sounds good
20:06:29 <sdake> mon-wed 1400-1700utc and 2200-2400utc
20:06:39 <sdake> please vote on which ones you can make
20:06:45 <sdake> and i'll go with critical mass
20:07:29 <jpeeler> alternating is fine, just may not make the later time if the examples given above are decided on
20:07:31 <sdake> any objections?
20:07:43 <sdake> jpeler what is the latest you think you can make?
20:07:51 <sdake> and rhallisey since you guys are on the east coast
20:08:03 <jpeeler> 22:00 UTC, but don't schedule anything around just me!
20:08:15 <rhallisey> jpeeler, agreed
20:08:20 <rhallisey> aroudn~22
20:08:22 <sdake> well i'd like the current core at the meetings if possible
20:08:43 <sdake> ok i'll set 2200 as the end time
20:08:52 <sdake> rather the later time
20:08:54 <sdake> altnerating
20:09:20 <sdake> #topic kilo branching
20:09:29 <sdake> so there is a problem with kilo branching
20:09:32 <sdake> which is why we are not yet branched
20:09:43 <sdake> I'd ask thatfolks not +2 / +a changes until the branch finishes
20:09:50 <sdake> hopefully today/tomorrow
20:09:56 <sdake> there are a couple feature exceptions I'd like people to consider  though
20:10:26 <sdake> https://review.openstack.org/#/c/177681/
20:10:43 <sdake> to fix the kilo branching, I need to change project-config
20:10:53 <sdake> still sorting out the chnage, but there is a turnaround on that change of 1-2 days
20:11:20 <sdake> can folks either -1 or +2 that change
20:11:25 <sdake> keeping in mind I know its not perfect
20:11:31 <sdake> and we can address perfection in master ;)
20:11:43 <daneyon> ok
20:12:09 <sdake> one more change
20:12:11 <sdake> https://review.openstack.org/#/c/177684/
20:13:36 <sdake> one more change
20:13:38 <sdake> https://review.openstack.org/#/c/170306/
20:14:04 <sdake> can we spend 2-3 minutes now reviewing, and once you have reviweed with either -1, +2, please respond in channel so we can proceed
20:15:21 <daneyon> reviewed and +2's them
20:16:01 <sdake> make sure not to just rubber stamp
20:16:06 <sdake> but actually look at the changes toop lz :0
20:16:09 <sdake> ;) I mean
20:17:17 <harmw> so the current goals is to support both nova-network and neutron?
20:17:31 <rhallisey> sdake, what are you trying to do with the demo
20:17:50 <jpeeler> why is cirros being downloaded and loaded into glance in a network config script?
20:18:09 <jpeeler> maybe not worth refactoring at the current time
20:18:18 <sdake> jpeeler it is really a misnomer, it should be called "init-runonce" or something
20:18:30 <harmw> ^^ agreed
20:18:33 <sdake> but the reason is because it can act atomically
20:18:38 <jtriley> sdake: compose/README.md should probably be updated as to point to the new network setup script as well, no?
20:18:42 <sdake> it clearly needs a refactor
20:18:51 <sdake> jtriely cool -1 and add a comment
20:19:09 <sdake> in my review I noticed there is a "cho" where it should be "echo"
20:19:20 <sdake> so I -1 and set workflow to -1
20:19:38 <sdake> the demo launches 20 virtual machines with neutron ports and neutron floating ips
20:20:24 <sdake> ok after meeting I will udpate any review comments and would appreciate fast reviews so master is in suitable shape for branching
20:20:39 <sdake> #topic continuous integration
20:20:55 <sdake> jpeeler has been working on this a bit, have any status update?
20:21:30 <jpeeler> sdake: some progress has been made, can now call tox to setup docker properly
20:21:31 <sdake> https://review.openstack.org/#/c/168598/
20:21:45 <sdake> I dont think we want tox setting up docker
20:22:01 <sdake> I think we want a script in tests which sets up the environment,and tox should call that script
20:22:20 <sdake> there is another guy from apac - his name escapes me atm
20:22:23 <sdake> but he is also working on this problem jpeeler
20:22:24 <jpeeler> i don't see the difference from what i said
20:22:44 <sdake> jpeeler do you ahve a review for early looking?
20:22:58 <jpeeler> no, but i will soon. it's not really based off your review. couldn't get that going at all
20:23:13 <sdake> it sure would be nice to go into our demo at summit (#6 on the most popular talks yay:) saying we have some basic functional testing
20:23:20 <jpeeler> also, kolla isn't a python project. so i've tried to avoid as much of that as i could
20:23:35 <sdake> I like how testr works
20:23:36 <jpeeler> (while still using all the python test runner stuff)
20:23:42 <sdake> it would be nice if we could write the test cases in python
20:23:58 <jpeeler> yes, that's the plan
20:24:01 <sdake> nice
20:25:06 <sdake> ok any qs for jpeeler?
20:25:20 <sdake> jpeeler if you can get a review up soon that would be great - so poeple can bikeshed it :)
20:25:31 <sdake> just mark workflow to -1
20:25:38 <jpeeler> yeah i know. it's just that i haven't had time to do much
20:26:04 <sdake> jpeeler I intend to continue work on my patch so it would be nice if we could integrate efforts
20:26:37 <jpeeler> sdake: no idea how you could run that patch. got all kinds of errors
20:26:50 <sdake> ya its a work in progress for sure
20:26:55 <sdake> I can integrate into your wip patch
20:27:10 <sdake> lets just get the ideas in the review queue because atm there are 3 people interested in working on it
20:27:12 <jpeeler> sdake: what i'm hearing is, hurry up. so i hear ya
20:27:24 <sdake> and I want image create/start working prior to the 10th of may :)
20:27:54 <sdake> rather image create --release without push and kolla start
20:27:59 <sdake> that would be a good first step in the gate
20:28:10 <sdake> if we could set that as our goal for may 10th that would rock :)
20:28:28 <sdake> we have 3 people wanting to tackle the problem so lets get all our ideas in the review queue
20:28:33 <sdake> jpeeler wfu?
20:28:48 <jpeeler> yeah
20:28:52 <sdake> nice :)
20:29:03 <sdake> #topic kolla final milestone blueprint review
20:29:37 <daneyon> i have been working on #link https://blueprints.launchpad.net/kolla/+spec/cinder-container
20:29:39 <sdake> #link https://blueprints.launchpad.net/kolla/milestone-4
20:29:45 <daneyon> trying to get cinder-volume to work
20:30:06 <rhallisey> daneyon, same
20:30:11 <sdake> nice - I htink that is probably goingto be master material
20:30:20 <sdake> with a target of liberty 1
20:30:24 <sdake> so i'll change that now
20:30:26 <daneyon> i made some progress, able to create a volume but can not attach to a nova instance
20:30:34 <daneyon> rhallisey, any progress on your end?
20:30:58 <rhallisey> daneyon, I went though the docs again and I saw that I was missing a few things
20:31:08 <rhallisey> I added them in, but still not working
20:31:16 <rhallisey> I need to ask a cinder person
20:31:32 <sdake> https://blueprints.launchpad.net/kolla/+spec/compute-operation-neutron
20:31:33 <rhallisey> to try and getting a better understanding of what's going on
20:31:38 <sdake> I think this is done right daneyon?
20:31:43 <daneyon> rhallisey, if you have time i would like to setup a webex and you can see what i'm seeing.
20:31:57 <rhallisey> daneyon, ya that would be great
20:31:57 <daneyon> i don;t think it's a cinder.conf config issue
20:32:11 <sdake> rhallisey please update the review with your new config items
20:32:12 <daneyon> lets coordinate after this meeting
20:32:20 <sdake> so everyone is working from same tree :)
20:32:36 <rhallisey> ya I have a feeling I'm not mouting all the proper directories
20:32:45 <daneyon> sdake https://blueprints.launchpad.net/kolla/+spec/compute-operation-neutron is done
20:33:25 <daneyon> rhallisey we'll talk after the meeting, i don;t think that's the issue either. maybe we can get this done if we combine our brains ;-)
20:33:29 <sdake> daneyon mark it as such so you get credit in stackalytics pls
20:33:43 <rhallisey> sounds good
20:34:25 <sdake> daneyon this is done right? https://blueprints.launchpad.net/kolla/+spec/container-set-compute-operation-neutron
20:34:55 <daneyon> sdake. yes. i just marked as implemented
20:35:43 <sdake> marking https://blueprints.launchpad.net/kolla/+spec/container-set-storage-operation for liberty
20:36:20 <sdake> marking https://blueprints.launchpad.net/kolla/+spec/compose-multios for liberty as well
20:36:24 <daneyon> sdake can you wait till tomorrow to set as Liberty?
20:36:44 <daneyon> rhallisey and I may get it working in the next 24 hrs
20:36:53 <sdake> ok can you changeit back then
20:36:55 <rhallisey> I think we're close
20:37:01 <daneyon> I think this is the last issue before cinder is functional
20:37:04 <daneyon> ya
20:37:26 <sdake> so major features for milestone #4 are neutron and possibly cinder
20:37:37 <daneyon> sounds about right
20:37:38 <sdake> plus we did a whole lot of refactoring to made the code base tidier
20:37:50 <sdake> and fixed a slew of bugs :)
20:38:11 <sdake> next week we will make our announcement release notice
20:38:16 <sdake> live on irc
20:38:25 <daneyon> ok
20:38:37 <sdake> the process is I will branch stable/kilo
20:38:50 <sdake> I will tag rc1 from stable/kilo master
20:39:08 <sdake> we will test this week/next make sure we are golden
20:39:21 <sdake> if rc1 is solid prior to the 10th I'll cut our final release
20:39:32 <sdake> if we have updates to fix bugs after the branch, there could be an rc2/rc3 etc
20:39:39 <sdake> each commit will result in a new rc
20:39:50 <sdake> make sense to folks?
20:39:52 <daneyon> will rc1 fixes go directly into stble/kilo branch or get backported from trunk?
20:40:06 <sdake> they get backported from trunk
20:40:11 <daneyon> ok
20:40:32 <daneyon> sounds good
20:40:52 <sdake> #topic improving process goingforward
20:41:02 <sdake> we do a whole lot of work
20:41:22 <sdake> but its really difficult for me to track the work because we are not using implements blueprint and closes bug tags in the git log
20:41:41 * rhallisey is guilty of that all the time
20:42:04 <jpeeler> i was wondering when that would come up
20:42:06 <sdake> for liberty I'd like folks to -1 reviews any non-documentation changes that don't have a closes bug or implements blueprint documented
20:42:30 <sdake> for documentation changes I don't think we need to document "improving quickstart guide" as the docs are a continual evolution
20:42:51 <sdake> since this is a big change for how we operate, I'd like a unanimous vote from the core
20:42:54 <sdake> +1 is my vote
20:43:11 <jpeeler> it's time, +1
20:43:14 <rhallisey> +1
20:43:17 <rhallisey> it is
20:44:08 <daneyon> +1
20:44:15 <sdake> cool well thats all the cores here
20:44:20 <sdake> i'll sync up with mandre tonight
20:44:28 <sdake> but lets assume he will vote +1 and operate under this model
20:44:38 <sdake> just after liberty dev starts
20:44:44 <sdake> i.e. may 10th and later
20:44:50 <sdake> until may 10th proceed as you currently do
20:45:10 <sdake> i'd like to point out daneyon does a real nice job of documenting his changes :)
20:45:14 <sdake> so not everyone is guilty
20:45:20 <sdake> but I'm guilty as well
20:45:23 <sdake> the only way it works is if everyone suffers the pain :)
20:45:31 <daneyon> sdake thx
20:45:49 <sdake> #topic open discussion
20:46:21 <sdake> so for folks not staying up until midnight, we have a large contingent of apac folks who look to be devs
20:46:25 <sdake> so we will likely get more help :)
20:46:26 <sdake> yay :)
20:46:38 <rhallisey> ya I've been talking to some of them
20:46:45 <daneyon> it would be nice ot somehow tackle sync'ing commits with kollaglue images during the L cycle
20:47:01 <sdake> daneyon I agree
20:47:26 <sdake> we may hae to do it out of band, since the ci jobs havea 1 hour limit and push takes 5 hours on my machine/network
20:48:07 <jpeeler> are people not pushing image changes?
20:48:10 <daneyon> ok
20:48:27 <sdake> jpeeler its more like we want a fresh push per commit
20:48:29 <daneyon> i am, but their needs to be syncronization
20:48:54 <sdake> compose-multios will fix alot of the problems we have with overwriting other poeples images/etc
20:48:56 <daneyon> what if you push to latest before your review is merged and you intro a bug?
20:49:12 <daneyon> the image should be built locally and pushed by ci when the assoc patch is merged
20:49:21 <xarses> I'd like to ask some questions around some of the design principles you guys have (probably in #kolla after this) so I can wrap my head around some things
20:49:34 <sdake> xarses we will be there :)
20:49:43 <daneyon> jpeeler do u see where i'm coming from?
20:49:53 <jpeeler> daneyon: yep! just hadn't really thought about it
20:50:09 <sdake> the big problem is the gate has a 1 hour timeout
20:50:37 <jpeeler> i personally wouldn't love per commit pushes. doesn't each push add a new fs layer to download?
20:50:43 <sdake> we can setup a vm somewhere which reads the changes and commits them via a docker push
20:51:01 <sdake> jpeeler we would push with --no-cache
20:51:20 <sdake> which eliminates that problem
20:51:25 <jpeeler> ah didn't know about that, cool
20:51:40 <daneyon> what if we pushed to our own registry, then that could help?
20:52:04 <sdake> you mean setup a registry in openstack-infra?
20:52:06 <sdake> sounds painful :)
20:52:10 <daneyon> ya
20:52:45 <daneyon> sdake can you help me understand what would be painful?
20:53:01 <sdake> setting up a new service in openstack-infra - no idea how to do that
20:53:25 <sdake> this is a conversation we need to have at summit
20:53:36 <daneyon> I guess we can explore the diff options in more detail when we get pass Vancouver
20:53:36 <sdake> pehraps I can get the infra guys to give us a session on the topic
20:53:40 <jpeeler> we could turn the problem upside down and create a git wrapper to checkout to a certain commit that works with image in the registry
20:53:49 <daneyon> sdake not a bad idea
20:54:32 <sdake> another simpler option is to allow us a post-commit hook to push via infra
20:54:35 <sdake> not sure if that is possible
20:54:40 <sdake> but they have a "push tarballs" job
20:54:50 <sdake> maybe that could be a psuh images job
20:55:24 <xarses> daneyon: sdrake, can't you guys use auto-builds from the docker registry?
20:55:27 <daneyon> sdkae i was looking at docker-hook to do something like that
20:55:31 <sdake> sdake, no r in my name :)
20:55:48 <daneyon> haha
20:55:56 <sdake> xarses we investigated that early on, problem with that is we would need a repo per dockerfile
20:55:58 <sdake> which is like 20 repos
20:56:00 <daneyon> do u go by sdkae too?
20:56:02 <sdake> and we would have to keep that in sync
20:56:42 <xarses> sdake: the last time i was playing with it, I was able to do a couple in diff branches, but it looked like multiple could be done in the same repo & branch
20:57:09 <sdake> i think the best course of action is to investigate how post tarballs work
20:57:14 <sdake> and do the same but with docker
20:57:33 <sdake> maybe there is no timelimit on that
20:57:58 <sdake> let me try to get a session from the infra guys
20:58:11 <sdake> see if they have bandwidth for it in their schedule
20:58:34 <sdake> if not I may be able to steal one of the magnum sessions
20:58:40 <sdake> since its semi-related to magnum as well
20:58:50 <sdake> magnum has 12 sessions
20:59:40 <sdake> meeting time out thanks guy :)
20:59:41 <sdake> s
20:59:43 <sdake> #endmeeting