22:01:41 <sdake> #startmeeting containers
22:01:43 <openstack> Meeting started Tue Jun 30 22:01:41 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:46 <openstack> The meeting name has been set to 'containers'
22:01:50 <sdake> #topic rollcall
22:01:56 <hongbin> o/
22:01:59 <mfalatic> o/
22:01:59 <madhuri> o/
22:02:04 <diga> o/
22:02:05 <brendenblanco> o/
22:02:06 <sdake> \o/ containers pay the bills!
22:02:08 <tango|2> Ton Ngo
22:02:09 <daneyon> o/
22:02:18 <yuanying-alt> yuanying otsuka
22:03:06 <sdake> lets wait couple more minutes for stragglers ;)
22:03:13 <wznoinsk> o/
22:03:39 <sdake> #topic announcements
22:03:53 <sdake> our deadline for release was June 25th, 2015
22:04:08 <sdake> I noticed that nothing has been tagged, probably because adrian is on pto iirc
22:04:17 <sdake> i can't tag the release, i don't have appropriate permissions
22:04:40 <sdake> but I did move all the l1 blueprints that were unfinished and moved all the l1 bugs that were unfixed to l2
22:05:32 <tcammann_> hello
22:05:37 <sdake> and released l1 here: #link https://launchpad.net/magnum/liberty/liberty-1
22:05:42 <sdake> #link https://launchpad.net/magnum/liberty/liberty-1
22:06:06 <sdake> the result is a whole lot of things slipped into l2
22:06:26 <sdake> we are on time based releases here, I think adrian wants to go to feature based, we can discuss when he gets back off the road
22:06:47 <sdake> so nice job onthe work folks :)
22:06:49 <madhuri> +1
22:06:49 <sdake> any questions?
22:08:09 <sdake> #topic liberty 2 milestone review
22:08:20 <sdake> Liberty 2 = July 31, 2015
22:08:25 <sdake> 4 weeks
22:09:08 <sdake> #link https://launchpad.net/magnum/+milestone/liberty-2
22:10:05 <sdake> the goal of this page is green, not blue ;)
22:10:38 <sdake> grey here is definately a bad color
22:11:16 <sdake> anyone that has a blueprint for liberty2 that doesn't think that blueprint will make liberty2, please use the next 5 minutes to say
22:11:37 <sdake> we will stop this exercise at :15 ;)
22:12:48 <tcammann_> still thing https://blueprints.launchpad.net/magnum/+spec/objects-from-bay is gonna make it?
22:13:13 <tcammann_> s/thing/think
22:13:30 <sdake> yes
22:14:11 <sdake> 1 more minute to push out blueprints ;)
22:14:20 <sdake> keep in mind, I moved *14* blueprints from liberty 1 to liberty 2
22:15:06 <tcammann_> I have my doubts about a few, but we shall see :)
22:15:20 <sdake> #topic new blueprint review
22:15:41 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/magnum-as-a-ca
22:16:05 <madhuri> Have anyone read the spec?
22:16:13 <sdake> what is anchor
22:16:23 <madhuri> I and yuanying-alt are working on it
22:16:36 <sdake> woring on which blueprint or anchor?
22:16:48 <madhuri> And for the certs generation we decided to have Magnum as a CA using anchor would be more secure
22:16:50 <tcammann_> I've been fairly involved with the anchor team
22:17:11 <sdake> is anchor a stackforge project?
22:17:13 <madhuri> On seccure Kubernetes bleuprint
22:17:20 <madhuri> It has lots of things to do
22:17:34 <yuanying-alt> https://github.com/stackforge/anchor
22:17:38 <madhuri> Yes stackforge project
22:17:38 <yuanying-alt> this one
22:17:59 <sdake> i am pretty certain we don't want a dependency on a stackforge project in a openstack namespaced project
22:18:25 <sdake> perhaps this is a blueprint for further down the road - like m1 when anchor is in the openstack namespace?
22:18:44 <madhuri> Ok I see
22:19:03 <madhuri> It means we are left with the second implementation
22:19:11 <sdake> which is what
22:19:17 <madhuri> Where user will generate the certs
22:19:28 <sdake> can't bay creation generate the certs?
22:19:39 <tcammann_> They have to be signed by something
22:19:43 <madhuri> Yes that is also a option
22:19:48 <sdake> self-signed
22:20:36 <sdake> madhuri can you start a thread on the ml and see if we are willing to accept a stackforge project as a depeendency in magnum
22:20:37 <madhuri> I think for this release we can go with this implementation
22:20:40 <sdake> my guess is no, but i am not the entire team
22:20:51 <sdake> use [magnum][anchor] tags
22:20:53 <madhuri> Ok Sure
22:21:13 <sdake> so the anchor cats know that not being in the openstack namespace is blocking adoption
22:21:17 <madhuri> You can make it an action item
22:21:35 <madhuri> Ok, I will
22:21:39 <sdake> #action madhuri to kick off thread about cert provided by stacforge project anchor
22:22:07 <sdake> then are we  agreed on the alternative which is self signed bay creation creates teh certs?
22:22:22 <sdake> i guess it depends on outcome of email thread
22:22:29 <madhuri> I think after we decide on the email
22:22:36 <madhuri> And then later we can decide
22:22:36 <sdake> madhuri can you get a blueprint up with that model as well
22:22:45 <sdake> so we are quick to act when we mae a deicision on the ml
22:22:45 <madhuri> Yes
22:23:06 <sdake> #action madhuri to create blueprint on self-signed ca certs via magnum bay-creation
22:23:19 <sdake> 1 minute household problem brb
22:23:20 <madhuri> Ok
22:24:19 <sdake> #link https://review.openstack.org/#/c/194905/
22:24:28 <madhuri> Don't have enough time now to think. Will discuss all pros and cons and then register a bp for it
22:25:06 <madhuri> I added this just to draw attention
22:25:07 <sdake> one q, why is there a spec up for this
22:25:28 <madhuri> I don't wanted to work on something folks wouldn't like
22:25:36 <sdake> did we have a change in process somewhere ?
22:25:43 <madhuri> There were so many options to implement this
22:25:51 <tcammann_> I think it deserves a spec
22:25:53 <madhuri> So I thought writing on it is better
22:26:04 <madhuri> I agree tcammann_
22:26:06 <sdake> specs are very problematic for young projects, i'd reserve them as an option of last resort
22:26:10 <tcammann_> There are a lot of design decisions need to be made on this work
22:26:17 <madhuri> Just to have clear picture
22:26:29 <sdake> i'd highly recommend in the future folks just write the code
22:26:36 <sdake> and forget about writing specs ;)
22:26:52 <tcammann_> Its very hard to grow this piece organically without it going wrong IMHO
22:27:09 <sdake> well maybe its a last resort option
22:27:09 <madhuri> But as far as I have realised it is not useful
22:27:16 <madhuri> I haven't got much response
22:27:33 <sdake> madhuri to have a specs process, we need to prioritize specs reviews above all other work we do
22:27:46 <madhuri> Agree
22:27:47 <sdake> and every core reviewer has to review EVERY PART OF EVERY SPEC
22:27:53 <sdake> this is very heavy handed
22:28:18 <madhuri> Better to discuss in meetingd
22:28:18 <sdake> this is why I am not in favor of a specs process, because it requires alot of work on the part of the ptl to drive the spec to delivery
22:28:30 <madhuri> But time is very less to discuss sch big features
22:28:52 <madhuri> An overhead
22:29:00 <sdake> ok, well everyone sees madhuri has a spec up, I think its important we feel the pain of what a real spec review is
22:29:05 <tcammann_> Maybe an ehterpad is more appropriate
22:29:36 <sdake> #action all core reviewers to review https://review.openstack.org/#/c/194905/
22:29:46 <madhuri> Thanks sdake
22:30:01 <sdake> ok enough lecturing - sorry for that, specs are dangerious, please don't use them unless asked by the ptl
22:30:01 <madhuri> May be tcammann_
22:30:12 <sdake> #topic ui development
22:30:25 <sdake> bradjones around?
22:30:30 <madhuri> But we will have to held meetings other thanIRC meetings to do so. RIght tcammann_ ?
22:30:47 <sdake> just write the code madhuri
22:30:58 <madhuri> Sure
22:31:00 <sdake> it will be rewritetn several times over the next 1-2 years
22:31:11 <sdake> all the ode I originally wrote in magnum - gone almost 100%
22:31:28 <sdake> but if we get bogged down in specs review, no work gets done
22:31:41 <sdake> nova has specs because it is a *mature* project
22:31:45 <sdake> we are a *young* project
22:31:49 <madhuri> Agree
22:31:51 <diga> +1
22:32:06 <sdake> the nova core team is threatening to rage quit unless they nuke the specs process entirely
22:32:13 <sdake> so I expct over time the specs process will be less used ;)
22:32:16 <sdake> but time will tell
22:32:21 <sdake> #topic open discussion
22:32:43 <tcammann_> Was there any progress on the midcycle tango|2?
22:33:21 <tango|2> I have everything lined up, just need a date
22:33:29 <daneyon> I think a doodle poll was going to be released to vote on midcycle times
22:33:47 <tango|2> We can host 30 people for 2 days, lunch + plenty of soda provided
22:34:06 <sdake> I am pretty sure no doodle poll hit the mailing list
22:34:11 <daneyon> has a date been locked in?
22:34:24 <sdake> tango how much lead time do you need
22:34:47 <tango|2> Just one day for the food, beverage :)
22:35:03 <tango|2> Our group owns the meeting venue, so it's flexible
22:35:11 <sdake> where is location
22:35:21 <daneyon> I think Adrian was going to handle the doodle poll. We should see it when he returns.
22:35:29 <tango|2> South San Jose, address is 555 Bailey Ave, San Jose
22:35:36 <sdake> he is gone for a couple weeks iir danyeon
22:35:50 <sdake> tango|2 mail me all logistic information stdake@cisco.com, I'll get a doodle poll up today
22:36:03 <tango|2> ok, will do
22:36:12 <daneyon> thx sdake
22:36:13 <tcammann_> thanks sdake
22:36:14 <sdake> i need the logistics info for the poll
22:36:26 <sdake> i'll leave the poll open for 1 week
22:37:50 <daneyon> Just an FYI... the network subteam had a productive first meeting last Thurs. Most of the work is within this EP #link https://etherpad.openstack.org/p/magnum-native-docker-network
22:37:52 <sdake> any other open discussion?
22:37:58 <sdake> thanks for bringing up the midcycle daneyon ;)
22:38:13 <daneyon> We took several votes on key areas of networking
22:38:15 <sdake> daneyon pro tip put #link on fresh line :)
22:38:31 <daneyon> sdake thx
22:38:57 <daneyon> First, we agreed to generalize the language of the upcoming networking spec.
22:39:53 <daneyon> To focus on an extensible networking model instead of just implementing similar network fuc in Swarm bay types as k8s bay types
22:40:24 <daneyon> We agreed to have the spec released on 7/25, so we have a week to get it into the L2 release
22:40:51 <daneyon> We spent a lot of time addressing the use cases within the EP
22:41:41 <daneyon> Our next meeting is reflected on the Container Meetings wiki for those interested in joining next time
22:42:01 <daneyon> In case you would like to check out the meeting logs:
22:42:03 <daneyon> #link http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-06-25-18.00.html
22:42:20 <daneyon> That's about it.
22:42:43 <tcammann_> Is there a plan to "deal" with the pythonk8sclient, i.e. modernise it and pull it out of Magnum?
22:43:03 <madhuri> Yes
22:43:14 <sdake> what is the plan?
22:43:25 <madhuri> sdake: has to say about it
22:43:36 <sdake> I wasn't aware there was one yet
22:43:40 <sdake> the plan is we are waiting on 1.0 of kubernetes
22:43:46 <sdake> to figure out what t o do at that point :)
22:43:52 <tcammann_> ok :)
22:43:55 <sdake> I think we have enough stuff on our plate not to have to worry about gold plating
22:44:28 <sdake> speaking of that, how is the heat kube thing going tcammann_
22:44:55 <tcammann_> whats that?
22:45:02 <sdake> the work you have been doing
22:45:06 <sdake> is it wrapped up?
22:45:27 <tcammann_> backporting from larsks repo, yes the patches are all up for review
22:45:46 <tcammann_> did you see my mail on the ML about the heat-coe-templates repo?
22:46:06 <sdake> no I have been in kolla release mode for last 2  weeks
22:46:06 <sdake> can you summarize for me plz
22:46:52 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/068237.html
22:47:01 <tcammann_> I don't think we should pull out the templates as a dependency into another repo
22:47:27 <tcammann_> I'm not sure we gain anything as a project or a community with another repo to maintain
22:47:39 <tcammann_> thanks hongbin
22:48:08 <sdake> you need to have a conversation with larsks about that idea ;)
22:48:12 <sdake> enjoy :)
22:48:14 <sdake> any other topics
22:48:36 <hongbin> sdake: I think the discussion should be within Magnum team
22:48:51 <hongbin> The decision is whether to pull templates out of magnum tree
22:49:09 <sdake> you mean permanently fork larks repo
22:49:25 <sdake> feels dirty like zebra to me
22:49:43 <sdake> i guess i'll go catch up on the ml now that we released kolla last night at 10pm
22:49:45 <daneyon> is their also an issue with having a dep on a stackforge project?
22:49:54 <sdake> daneyon not really
22:50:05 <sdake> daneyon that is our repo we can bring into our namespace whenever we want
22:50:13 <sdake> but we just haven't done that yet because we are - overworked ;)
22:50:32 <daneyon> ahh... I thought it was a separate maintainer. thx
22:50:53 <sdake> any other topics
22:51:44 <sdake> thansk for coming folks :)
22:51:47 <sdake> #endmeeting