20:00:26 <sdake_> #startmeeting kolla
20:00:27 <openstack> Meeting started Mon May  4 20:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:30 <openstack> The meeting name has been set to 'kolla'
20:00:59 <sdake_> #topic rollcall
20:01:05 <sdake_> o/ ;)
20:01:10 <daneyon_> hola
20:01:12 <jpeeler> hi
20:01:43 <rhallisey> hi
20:02:11 <sdake_> #topic agenda
20:02:20 <sdake_> #link https://wiki.openstack.org/wiki/Meetings/Kolla
20:02:30 <sdake_> anyone have anything to add to the agenda?
20:03:05 <daneyon_> nada
20:03:25 <sdake_> #topic Last bit of effort for 2015.1.0 before branching
20:03:36 <sdake_> last week we were supposed to branch stable/kilo
20:03:52 <sdake_> but I thought it wasn't ideal we were relasing juno openstack for kilo ;)
20:04:05 <daneyon_> agree
20:04:07 <sdake_> also for a magnum keynote demo, we need kolla operational on Kilo
20:04:22 <sdake_> so I pushed out a week so I could work on a kilo port and see if I could get it working
20:04:38 <sdake_> #link https://review.openstack.org/#/q/project:stackforge/kolla,n,z
20:04:55 <sdake_> anything without a -2 should be reviewed if folks have time
20:05:03 <sdake_> most of the kilo patches are ready for +2/+a at this point
20:05:12 <sdake_> the magnum and heat-api-cfn containers aren't quite ready
20:05:13 <Slower> o/
20:05:24 <sdake_> once the existing reviews get wrapped up, I plan to branch, hopefully today or tomorrow morning
20:05:26 <sdake_> hey slower
20:05:52 <sdake_> can folks commit to being active in the reviews today and tomorrow so we can branch as soon as possible?
20:06:14 <rhallisey> sure
20:06:29 <sdake_> jpeeler daneyon_ ?
20:06:29 <Slower> tomorrow I could
20:06:39 <sdake_> there is always tomorrow :)
20:06:41 <daneyon_> i'll keep it going
20:06:57 <jpeeler> same ^
20:07:08 <sdake_> cool thanks for the commitment guys
20:07:26 <sdake_> any other things outstanding we should try to jam into this 2015.1.0 release?
20:08:07 <sdake_> i suppose the novnc work if harmw gets it done?
20:08:15 <sdake_> sounds like cinder isn't going to make it, correct?
20:08:41 <rhallisey> doubt it will
20:08:46 <sdake_> #link https://blueprints.launchpad.net/kolla/milestone-4
20:08:59 <sdake_> this will be our feature set for 2015.1.0 new features then
20:09:01 <rhallisey> still not sure of the issue in nova-compute
20:09:02 <daneyon_> cinder is a no go
20:09:16 <sdake_> ok well we need cinder at some point so I hope you guys don't give up :)
20:09:55 <daneyon_> me too... lol
20:09:58 <sdake_> #topic New meeting times
20:10:22 <sdake_> #link https://doodle.com/y2kideusi85zm7ghqz6mr62n/admin#table
20:10:52 <harmw> sdake_: just a tiny update on vnc though
20:10:55 <harmw> it's working
20:11:34 <sdake_> nice harmw!
20:11:41 <sdake_> i'll make you a buildprint
20:11:43 <daneyon_> sweet
20:11:44 <sdake_> buildprint
20:11:46 <sdake_> blueprint
20:12:01 <sdake_> and you can use implmenets: blueprint container-novnc
20:12:06 <harmw> yup
20:12:13 <harmw> was aiming for that
20:12:13 <sdake_> or container-nova-novnc I guess it should be
20:12:24 <sdake_> harmw can you make a blueprint now?
20:12:30 <sdake_> and I'll approve it
20:12:52 <sdake_> about meeting times, looks like wednesday is the day
20:13:01 <sdake_> occasionally I will have a conflict on wednesday, and someone will have to run the meeting
20:13:02 <harmw> sure, just not on the spot (gimme an hour or so)
20:13:06 <sdake_> like once every couple months
20:13:35 <sdake_> our next meeting will be 1600 UTC to get the most coverage
20:13:50 <harmw> as long as core people can attend, that shouldn't be an issue
20:13:57 <sdake_> may 13th
20:14:02 <sdake_> sounds good?
20:14:06 <daneyon_> yup
20:14:22 <sdake_> and then the next week will be 2200, but cancelled because of summit
20:14:31 <sdake_> and the next meeting will be 1600 UTC again after summit
20:14:35 <sdake_> then 2200 etc
20:14:37 <sdake_> alternating
20:14:39 <sdake_> make sense?
20:14:52 <harmw> ok, though I'll stick with the 2200
20:15:11 <sdake_> 2200 is really meant for apac
20:15:13 <daneyon_> ok
20:15:26 <sdake_> and we have more contribs interested in participating from apac
20:15:32 <sdake_> we may have to change the meeting channel
20:15:38 <sdake_> I'll send out details to the mailing list
20:15:52 <sdake_> #action sdake to send new meeting information to mailing list
20:15:56 <harmw> ah no, I'm confusing myself here
20:16:11 <sdake_> #topic Continuous Integration
20:16:22 <sdake_> There are three bodies of work so far
20:16:37 <sdake_> the first one just sets up the system with docker/compose - I really like this patch and would liek people to consider merging it
20:16:52 <sdake_> https://review.openstack.org/#/c/178048/
20:17:00 <sdake_> then the gate will run this script followed by tox -e functional
20:17:22 <sdake_> jpeeler's patch https://review.openstack.org/#/c/168598/ will execute the tox -e functional
20:17:27 <sdake_> jpeeler sound good?
20:17:40 <jpeeler> well i have a similar tool - https://review.openstack.org/#/c/168598/8/tools/install_dkr_rpms.sh,unified
20:17:41 <sdake_> jpeeler if you have ideas for the first patch please feel free to review it
20:18:05 <jpeeler> i wish i had seen the other review first
20:18:23 <jpeeler> but my main focus was what's being used in the gate of fedora 21
20:18:45 <sdake_> the cool thing about the first patch is it doesn't depend on fedora or ubuntu - its agnostic
20:18:58 <sdake_> but your work is good too for a fedora only system
20:19:03 <sdake_> but I prefer only merge one installation tool
20:19:15 <sdake_> (that installs for the gate)
20:19:16 <daneyon_> Seems like Zhiwei Chen needs to address Martin's feedback for https://review.openstack.org/#/c/178048/
20:19:22 <sdake_> make sense?
20:19:24 <sdake_> ya its not perfect yet
20:19:30 <sdake_> but I really like how its structured
20:20:02 <sdake_> if we could get some form of CI going prior to summit, that would rock
20:20:08 <sdake_> that way I could mention it
20:20:28 <jpeeler> well on that note, other than dropping my docker rpm script what more needs to be done?
20:20:36 <sdake_> ie. jpeeler and Ahiwei's patch need merging before 15th
20:21:42 <sdake_> jpeeler your patch looks solid but it needs to buidl the containers as the first test case
20:21:52 <sdake_> since i want building to be tested
20:21:55 <jpeeler> you mean not download them?
20:21:59 <sdake_> right
20:22:03 <sdake_> you should build from source
20:22:20 <sdake_> the idea is we will build rom source, and then after the commti is merged, there is a "post pipeline"
20:22:36 <sdake_> the post pipeline will push all of the images for juno/kilo with a tag of the git repo
20:22:42 <sdake_> the push takes about  5 hours
20:23:00 <sdake_> then we have full CI/CD ;-)
20:23:03 <sdake_> \o/
20:23:22 <sdake_> any questions from folks?
20:23:36 <jpeeler> alright i'll look into building the images. not sure tox is the best place for that though
20:24:11 <sdake_> jpeeler the building fails for some images
20:24:13 <sdake_> and those are expected
20:24:29 <sdake_> so the test case needs to parse the build dand make sure the right containers got built
20:24:50 <sdake_> I htink this is a good fit for python
20:24:53 <sdake_> but I could be wrong ;-)
20:24:59 <jpeeler> is that documented somewhere? it's been a while since i've built a docker image manually
20:25:13 <jpeeler> i thought we already had scripts to build the world
20:25:13 <sdake_> tools/build-all-docker-images --release is how you do it
20:25:31 <harmw> maybe use some env/substition magic in the compose files?
20:25:32 <sdake_> it produces an output of things that succeeded and failed at the tail
20:25:48 <harmw> as is done in Dockerfiles
20:26:00 <sdake_> eg:
20:26:01 <sdake_> Rebuilt kollaglue/centos-rdo-k-neutron-base
20:26:01 <sdake_> Failed to process kollaglue/centos-rdo-k-barbican
20:26:02 <sdake_> Rebuilt kollaglue/centos-rdo-k-zaqar
20:26:02 <sdake_> Rebuilt kollaglue/centos-rdo-k-keystone
20:26:04 <sdake_> Rebuilt kollaglue/centos-rdo-k-glance-registry
20:26:04 <sdake_> real	36m36.094s
20:26:22 <sdake_> that needs to be parsed
20:26:23 <jpeeler> maybe we should talk further about it later - i may have too many questions
20:26:35 <jpeeler> i don't see why a container would be failing. surely eventually they will all succeed?
20:26:43 <sdake_> some do not build
20:26:52 <sdake_> swift in particular
20:26:52 <jpeeler> what's preventing that?
20:26:57 <sdake_> not implemented i think
20:27:08 <sdake_> barbican is easily fixed now that packaging is available in rdo
20:27:13 <notmyname> what does swift not implement?
20:27:22 <sdake_> kolla doesn't implement swift
20:27:36 <sdake_> yet we have containers which partially implement it
20:27:41 <sdake_> therefore our build has failures
20:27:45 <jpeeler> rather than parsing the output, i think it'd be better to mark which images shouldn't be tested
20:27:52 <sdake_> and we need to ignore those
20:27:58 <sdake_> that wfm too
20:28:06 <sdake_> however you want to do it
20:28:29 <sdake_> we can talk more offline
20:28:52 <sdake_> #topic Ansible all in one
20:29:06 <sdake_> #Link https://review.openstack.org/#/c/179646/
20:29:14 <sdake_> as you can see, fang has develoepd an ansible all in one installer
20:29:22 <sdake_> this is fantastic :)
20:29:40 <sdake_> i ran it, it indeed starts all of the containers
20:29:46 <sdake_> assuming no containers already exist ;-)
20:30:04 <sdake_> I'd really like for all the core reviewers to take a look at this patch
20:30:11 <sdake_> so you start to get a feel for how ansible works
20:30:33 <sdake_> I think coming out of summit we will have people wanting to deploy kolla, and ansible is our shortest path to that besides tripleo
20:30:53 <harmw> how would this go with the current tools/kolla script?
20:31:00 <sdake_> can the core folks commit to reviewing the ansible script?
20:31:05 <sdake_> harmw it is not a replacement, it is a duplicate
20:31:22 <sdake_> but it lays the foundation for going multinode with kolla
20:31:25 <harmw> which is exacly what I ws thinking
20:31:28 <sdake_> tools/kolla will *never* go multinode
20:31:32 <harmw> nope
20:31:33 <harmw> indeed
20:31:38 <sdake_> tools/kolla is a developer tool
20:31:38 <harmw> good job :)
20:31:52 <sdake_> for testing out containers
20:32:14 <daneyon_> i'll review the ansible patches
20:32:29 <rhallisey> I'll give it a try too
20:32:44 <sdake_> cool recommend actually trying it, its pretty sweet in action
20:32:56 <sdake_> so simple
20:33:00 <sdake_> it needs alot of work
20:33:07 <sdake_> but I think developers are coming to develop it
20:33:30 <sdake_> there are a few people who have contacted me privately who want to contribute to kolla, and I'm going to point them at this part
20:34:47 <sdake_> #topic open discussion
20:35:14 <sdake_> anyone have any open topics to discuss?
20:35:18 <rhallisey> nada
20:35:30 <daneyon_> nope
20:35:32 <harmw> nope
20:36:01 <sdake_> I just wanted to close with a congraluations, it has been a really rough road during Kilo development for Kolla
20:36:10 <sdake_> thanks for not giving up!
20:36:14 <sdake_> we have a rockin system now
20:36:22 <sdake_> and 160 people registered for the kolla talk
20:36:23 <sdake_> that is a sign that people want our work
20:36:30 <harmw> nice work :)
20:36:46 <sdake_> we just have to figure out how to get it to them that doesn't involve tools/kolla on each node ;-)
20:36:52 <sdake_> #endmeeting