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