22:00:36 <juggler> #startmeeting Containers
22:00:39 <openstack> Meeting started Tue Jul 28 22:00:36 2015 UTC and is due to finish in 60 minutes.  The chair is juggler. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:46 <openstack> The meeting name has been set to 'containers'
22:01:08 <juggler> hello all
22:01:12 <apmelton> o/
22:01:21 <yuanying-alt> o/
22:01:27 <eghobo> o/
22:01:31 <juggler> o/
22:01:32 <Tango> o/
22:01:37 <daneyon> o/
22:01:40 <mfalatic> o/
22:01:42 <hongbin> o/
22:02:20 <juggler> Glad you all could be here...let's proceed...
22:02:30 <juggler> #topic
22:02:33 <jay-lau-513> jay-lau-513
22:03:20 <juggler> heh...what's the next directive :)
22:03:36 <madhuri_> o/
22:04:13 <juggler> one moment, please...
22:04:15 <adrian_otto> Adrian Otto
22:04:16 <mfalatic> . #cakeforall
22:04:24 <mjbrewer> o/
22:04:30 <yuanying-alt> Annoucement?
22:04:32 <jay-lau-513> o/
22:04:35 <travisn> o/
22:04:51 <juggler> #topic Announcements
22:05:12 <adrian_otto> I have asked juggler to help out with meetings
22:05:19 <adrian_otto> so this is a practice run
22:05:22 <juggler> Any announcements all? :)
22:05:34 <juggler> a very practice run... :)
22:05:39 <suro-patz> o/
22:06:20 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-07-28_2200_UTC Our Agenda
22:07:03 <adrian_otto> ok, juggler let's advance topics
22:07:41 <juggler> #topic Container Networking Subteam Update
22:08:06 <juggler> #link http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-07-23-18.05.html Previous Meeting
22:08:22 <adrian_otto> daneyon: care to offer us a summary?
22:08:36 <daneyon> sure
22:08:55 <daneyon> 99% of the meeting was focused on discussing the network spec
22:09:40 <daneyon> we discussed the objections... most from the neutron community
22:10:07 <daneyon> we are at an impasse where we need to figure out the next steps
22:10:16 <daneyon> we can standardize on libnetwork
22:10:36 <daneyon> however, kubernetes has it's own pluggable network model
22:10:49 <daneyon> we don;t need to support the k8s pluggable network model
22:10:55 <adrian_otto> (leveraging libnetwork is the preferred approach from our neutron community perspective)
22:11:24 <daneyon> we could get flannel (our current k8s network implementation) to work with Docker's libnetwork by using the native bridge driver
22:11:33 <daneyon> it needs to be validated
22:11:40 <jay-lau-513> daneyon: Does there are any huawei guys contact you for libnetwork integration proposals?
22:11:58 <daneyon> adrian_otto i agree on leveraging, but do we want to standardize on it.
22:12:03 <jay-lau-513> daneyon: we discussed this in a local meeting and they want to work with you for the solution
22:12:31 <hongbin> jay-lau-513: who are the huawei guys
22:12:48 <jay-lau-513> hongbin: from libnetwork team
22:13:04 <jay-lau-513> hongbin: they want to contribute to magnum
22:13:14 <daneyon> their is a lot of push towards the Kuryr project, but the project has no specs or detailed doc's on what it is or what it will be
22:13:23 <daneyon> their is a lot of misunderstanding around Kuryr
22:13:30 <adrian_otto> agreed.
22:13:52 <adrian_otto> The remarks in our subteam meeting and the content in the Kuryr readme did not match
22:14:21 <adrian_otto> so that means that there is somtheing more ambitious planned that has not yet made it into docs
22:14:32 <daneyon> are we ok with not supporting k8s's pluggable network model? if goog joins and wants to support k8s pluggable network, then we come full circle???
22:15:07 <adrian_otto> daneyon: we need a solution that works across different Bay types
22:15:32 <daneyon> adrian_otto in the m net spec, i asked the kuryr team to create a spec for their project. they are starting whip together code, but no spec. that concerns me
22:15:33 <adrian_otto> until users tell us otherwise, it's probably not wise to fixate too much on the features on one bay type
22:15:42 <eghobo> daneyon: I though flannel supports kub model, doesn't it?
22:16:08 <juggler> Sounds like some additional discussion is needed...
22:16:18 <juggler> #action Libnetwork team / daneyon to coordinate meeting for possible integration solution
22:16:42 <adrian_otto> we have the Thu subteam meetings already
22:16:46 <daneyon> adrian_otto and libnetwork (for now) can do that. I think it could become a problem if goog has different views/plans for the ks pluggable net model. The k8s team has suggested combining the k8s/libnetwork models, but nothing has happened
22:17:33 <adrian_otto> daneyon: let's cross that bridge when we come to it. Let's proceed with the information we have now.
22:17:36 <daneyon> adrian_otto it will be super helpful to know who from goog will be contrib to magnum and what their view is on this topic
22:18:01 <adrian_otto> daneyon: I'd like to know that too. I expect to hear from them soon.
22:18:01 <daneyon> adrian_otto or do we just move forward and if goog wants something different, then they need to reimplment?
22:18:19 <adrian_otto> daneyon: yes.
22:18:23 <daneyon> in the mean time, maybe i shift the focus a bit on the following:
22:18:44 <daneyon> 1. Get more involved in kuryr to make sure things are moving in the right direction
22:18:54 <adrian_otto> good.
22:19:14 <juggler> #topic AI Review
22:19:24 <daneyon> 2. test flannel with libnetwork's native bridge driver... this is what would be needed if we decide to standardize on libnetwork
22:19:55 <daneyon> If we can't get ^ working, then we need to patch libnetwork or flannel or not standardize on libnetwork.
22:19:58 <adrian_otto> both are appropriate on an immediate basis
22:20:44 <hongbin> works for me
22:21:02 <daneyon> adrian_otto OK, I will do both then
22:21:07 <adrian_otto> thanks daneyon. Let's revisit it in the subteam, and continue advancement there.
22:21:28 <adrian_otto> thanks for advancing topics, juggler. Please indicate the AI's to review
22:21:34 <daneyon> adrian_otto et all... should we continue the net subteam meetings?
22:21:37 <tcammann1> o/ sorry I'm late
22:21:42 <daneyon> if so, i'll update the wiki
22:21:49 <adrian_otto> daneyon: yes
22:21:57 <juggler> will do! ... just patiently waiting for daneyon to finish thoughts...
22:21:58 <adrian_otto> welcome tcammann
22:22:08 <juggler> #topic AI: 1) adrian_otto to verify Magnum team has enough support to integrate with Magnum
22:22:27 <juggler> adrian_otto could you provide us a status on this AI?
22:22:34 <adrian_otto> madhuri_: do you agree you have what you need?
22:22:39 <tcammann1> Was barbican right
22:22:41 <adrian_otto> I marked this as complete
22:22:45 <adrian_otto> Barbican
22:23:04 <adrian_otto> yes, I entered the action incorrectly last week
22:23:08 <madhuri_> Yes for storing cert
22:23:13 <madhuri_> But not as a CA
22:23:27 <juggler> #action daneyon to update the wiki for net subteam meeting
22:23:46 <apmelton> adrian_otto: madhuri_: what's the issue with 'as a CA', I was planning on taking this up
22:23:53 <adrian_otto> is this an involvement problem, or a software problem?
22:24:09 <apmelton> was it something barbican just can't do well at the moment, or a magnum resource issue?
22:24:19 <madhuri_> Dogtag installtion on Ubuntu has some bug now
22:24:21 <adrian_otto> apmelton: thanks for helping out with this, we really need to break through some friction here
22:24:28 <madhuri_> according to Adee
22:24:49 <adrian_otto> doortag is an open source software for cert management
22:24:51 <madhuri_> And also the snakeoil plugin with devstack is not working
22:25:01 <madhuri_> Sorry Dogtag
22:25:12 <tcammann1> Aren't we using storing certs, why do we still need barbican?
22:25:12 <apmelton> madhuri_: I can take a look at snakeoil asap
22:25:13 <adrian_otto> Dogtag
22:25:18 <tcammann1> *db ^
22:25:32 <madhuri_> Thanks apmelton
22:25:35 * adrian_otto screams quickly
22:25:47 <adrian_otto> we really don't want secrets in the magnum db.
22:25:54 <adrian_otto> We are falling back to this as a last resort
22:26:06 <madhuri_> adrian_otto: That part is independent
22:26:16 <madhuri_> And can be implemented now
22:26:21 <tcammann1> I feel we should look into using Anchor as a CA if Barbican cannot support this
22:26:43 <madhuri_> The issue is with the CA part in Barbican not the storage part
22:26:52 <adrian_otto> Barbican seems to depend on a bunch of other software that just does not work
22:27:07 <madhuri_> +1 adrian_otto
22:27:17 * tcammann1 thought this might happen :(
22:27:45 <adrian_otto> ok, so let's revisit this later in the agenda
22:27:50 <juggler> #action apmelton to review snakeoil plugin and assist madhuri with integration
22:27:59 <madhuri_> Sure adrian_otto
22:28:20 <juggler> #topic AI: 2) tcammann to move heat-coe-templates repo to project attic, and to relay our resolution on the ML thread: http://lists.openstack.org/pipermail
22:28:21 <adrian_otto> I'd like madhuri and apmelton to work together to come up with some options and present them on our ML so Magnum team members can offer input
22:28:25 <adrian_otto> does that seem reasonable?
22:28:36 <apmelton> sure
22:28:40 <juggler> please ignore that last URL...will be repasted
22:28:48 <juggler> http://lists.openstack.org/pipermail/openstack-dev/2015-July/068381.html
22:28:55 <adrian_otto> tcammann1: it would be good if you could also participate there
22:28:59 <madhuri_> +1 from me
22:29:14 <juggler> tcammann: might you have feedback on this action item?
22:29:16 <tcammann1> sure, maybe sync up at the midcycle?
22:29:43 <tcammann1> juggler: the review is up for review by infra, and I sent out a mail on the ML on the subject
22:29:48 <tcammann1> I'll find the link to the review
22:29:51 <adrian_otto> we should collect midcycle topics before we adjourn today.
22:30:03 <tcammann1> https://review.openstack.org/#/c/205146/
22:30:13 <juggler> thanks tcammann
22:30:36 <juggler> #topic Blueprint/Bug Review
22:30:48 <juggler> #topic #link https://blueprints.launchpad.net/magnum/+spec/hyperstack Power Magnum to run on metal with Hyper
22:31:16 <adrian_otto> so on this topic, I raised a number of concerns on our ML
22:31:17 <juggler> Xu, do you have input on this blueprint?
22:31:29 <jay-lau-513> Not sure if Xu on line or not
22:31:45 <jay-lau-513> I have some comments for this and want to discuss with team
22:31:45 <juggler> go ahead adrian_otto
22:31:56 <adrian_otto> proceed jay-lau-513
22:32:38 <jay-lau-513> I heard that Hyper is now integrating with Kubernets, once they finished integraiton with k8s, I think that we can create a new k8s bay with hyper in Mangum
22:32:50 <jay-lau-513> this is solution 1
22:33:20 <adrian_otto> yes, that's an option
22:33:25 <jay-lau-513> Solution 2, is if hyper can be a kind of framework on top of mesos, then it would be another mesos bay
22:33:59 <jay-lau-513> because hyper can use mesos do resource scheduling to decide where to deploy the pod/container, just like what marathon+mesos+docker doing now
22:34:20 <jay-lau-513> hongbin has finished marathon+mesos integration, I think it is pretty similar with hyper+mesos
22:34:24 <eghobo> jay-lau-513: you probably mean executor
22:34:36 <jay-lau-513> eghobo yes
22:34:58 <jay-lau-513> I do not think we need a nova hyper driver just like other nova compute drivers
22:35:50 <adrian_otto> fair enough. I read though that particular ML thread, and I understand that it's not a perfect fit there either.
22:36:13 <adrian_otto> in all honesty, I just think this is interesting, and want to find a place where we can welcome adding it
22:36:17 <jay-lau-513> because magnum cannot leverage those drivers, the nova hyper driver will be managed by nova to create pod/containers and the nova team do not like this, as it is kind of another nova docker driver
22:36:27 <adrian_otto> but I'm not willing to set the full strategy for it myself
22:36:49 <juggler> is additional research needed to determine which of these 2 solutions is optimal?
22:36:50 <adrian_otto> because we already have secure multi-tenancy by nature of using Bays
22:37:14 <adrian_otto> juggler: we have had this on the agenda now for 3 continuous weeks, and the Hyper team is not showing up.
22:37:25 <jay-lau-513> adrian_otto, yes, if hyper can follow our bay/baymodel design thinking, then it should be ok
22:37:32 <juggler> ah
22:37:37 <adrian_otto> so I'm planning to drop it from the next agenda, and we can follow up on the ML for this.
22:37:58 <adrian_otto> I agree with jay-lau-513 that it can be integrated as a bay type, and that's probably the best fit
22:38:39 <adrian_otto> this would be worth covering at the imdcycle
22:38:43 <adrian_otto> Midcycle
22:38:53 <adrian_otto> #link https://wiki.openstack.org/wiki/Magnum/Midcycle
22:39:05 <juggler> #action adrian_otto to table Hyper discussion to the ML or MidCycle
22:39:16 <adrian_otto> I should have mentioned during the announcements section a reminder that this is coming next week
22:39:30 <jay-lau-513> adrian_otto I think that I can discuss with Hyper guys locally, as they are in china and we are in same time zone
22:39:36 <adrian_otto> #link https://etherpad.openstack.org/p/magnum-liberty-midcycle-topics Midcycle Agenda
22:39:46 <juggler> thanks adrian
22:39:59 <juggler> proceeding to the next blueprint:
22:40:05 <juggler> #topic #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/070583.html New Discussion about Hyperstack
22:40:07 <hongbin> jay-lau-513: Better to ask them to join the midcycle
22:40:17 <adrian_otto> ok, will do.
22:40:27 <jay-lau-513> hongbin where does the midcyle will be held?
22:40:36 <juggler> Peng any feedback?
22:40:37 <adrian_otto> #idea invite Hyper team to Midcycle meetup
22:40:37 <jay-lau-513> hongbin can they join remotely
22:40:51 <adrian_otto> juggler: we covered this, advance to the next please
22:40:52 <hongbin> jay-lau-513: I think everyone can join remotely
22:41:01 <jay-lau-513> hongbin ok, cool
22:41:18 <juggler> ok
22:41:21 <juggler> #topic #link https://blueprints.launchpad.net/magnum/+spec/objects-from-bay Obtain the objects from the bay endpoint (sdake)
22:41:49 <jay-lau-513> hongbin I think that huawei has many guys interested in magnum, you can probaly lead them to contribute ;-)
22:41:52 <juggler> sdake... please proceed
22:42:35 <tcammann1> sdake and I intend to sync up on this at the midcycle
22:42:49 <tcammann1> no progress so far
22:43:00 <hongbin> jay-lau-513: Sure, I would talk to them
22:43:22 <juggler> #action sdake/tcammann to sync up on https://blueprints.launchpad.net/magnum/+spec/objects-from-bay at MidCycle
22:43:47 <juggler> thanks tcammann....that is progress
22:43:48 <juggler> !
22:43:56 <juggler> #topic #link https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes Secure the client/server communication between ReST client and ReST server (madhuri)
22:44:14 <juggler> any feedback madhuri?
22:44:24 <madhuri_> Patches for review online
22:44:39 <madhuri_> We are implementing the solution with no dependency now
22:44:40 <juggler> great
22:44:55 <madhuri_> I have also updated the spec for clear picture
22:45:09 <adrian_otto> I'm not thrilled about the ordering, because I want to follow the principle of secure-by-default
22:45:27 <madhuri_> adrian_otto: Yes we will definitely do it
22:45:28 <adrian_otto> I'm not happy about internal cert and key storage in the magnum db
22:45:39 <madhuri_> I made a comment around yuanying-alt patch
22:45:49 <adrian_otto> but madhuri_ has assured me that we will have secure storage implemented in Liberty as well
22:46:22 <juggler> would you like an action-item towards that goal adrian?
22:46:26 <madhuri_> I have slow progress due to many dependent patches stll waiting to be merged
22:46:40 <madhuri_> That's why I would like cores to help reviewing it soon
22:46:49 <madhuri_> So that I can proceed fast
22:47:01 <adrian_otto> and our gerrit work queue is clogged up what seems like by about a year.
22:47:07 <juggler> madhuri do you anticipate how soon?
22:47:09 <hongbin> adrian_otto: I want to discuss the insecure alternative
22:47:23 <adrian_otto> ok, we are sort on time today
22:47:36 <adrian_otto> but let's cover that now, and then skip to Open Discussion
22:47:41 <madhuri_> We can discuss on #opensrack-containers
22:47:49 <adrian_otto> madhuri_: ok
22:48:02 <madhuri_> Ok
22:48:02 <juggler> #topic The Insecure alternative
22:48:14 <juggler> proceed hongbin
22:48:34 <hongbin> I think it is better to support an optional insecure bay
22:48:53 <hongbin> because most provisioning tool provision a insecure k8s
22:48:56 <adrian_otto> my initial position is the opposite
22:49:01 <hongbin> like ansible, juju ...
22:49:04 <madhuri_> We can have that support but by default we will have secure option
22:49:30 <hongbin> users are used to play with an insecure k8s
22:49:32 <madhuri_> +1 adrian_otto
22:49:38 <adrian_otto> madhuri_: why not be a bit more opinionated, and only support secure.
22:49:58 <tcammann1> Almost all tools that make TLS connections support the insecure option, including all the openstack clients
22:50:11 <adrian_otto> why is that?
22:50:13 <madhuri_> adrian_otto: I think we should support both and let user have their choices to play around
22:50:14 <tcammann1> It should be off by default
22:50:33 <adrian_otto> I agree that if we do offer the feature that it be off by default
22:50:39 <adrian_otto> but should we have the feature at all
22:50:46 <adrian_otto> who is really going to use that?
22:50:51 <tcammann1> Because TLS can be tough to debug and manage for small proof of concept work
22:50:56 <adrian_otto> seems like additional maintenance burden for us
22:51:15 <hongbin> Yes, a use case is debug
22:51:24 <madhuri_> Yes we do need to have differrent test for both
22:51:26 <adrian_otto> tcammann1: ok, that's a compelling reason
22:51:46 <hongbin> Maybe better for developers
22:51:52 <tcammann1> It'll be a small maintaince burden compared to supporting TLS
22:52:04 <madhuri_> Agreed
22:52:05 <adrian_otto> we have to support TLS.
22:52:20 <adrian_otto> the question is whether to also support insecure mode
22:52:22 <tcammann1> I'm not disagreeing with that :)
22:52:35 <adrian_otto> ok, let's do this
22:52:37 <apmelton> is the idea that we're trying to reduce barrier to entry for deploying magnum?
22:52:38 <tcammann1> For parity with the rest of OpenStack we should
22:52:41 <adrian_otto> let's implement both
22:52:46 <adrian_otto> insecure off by default
22:52:55 <madhuri_> Ok it is already in my todo list
22:52:58 <adrian_otto> and tech debt ticket to remove the insecure option later
22:53:00 <apmelton> so that an operator whos curious about magnum can spin it up, and try it out really quickly without having tons of dependencies?
22:53:13 <adrian_otto> we can debate the merits of that tech debt ticket at our midcycle.
22:53:15 <madhuri_> Yes apmelton
22:53:16 <tcammann1> Yep +1 adrian_otto
22:53:17 <adrian_otto> possibly eliminating it
22:53:29 <hongbin> wfm
22:53:30 <eghobo> just side note, even kub cluster-up has https by default
22:53:33 <adrian_otto> ok, cool
22:53:49 <adrian_otto> juggler: let's proceed to Open Discussion
22:53:52 <juggler> #action implement TLS and non-TLS support with insecure off by default
22:54:16 <juggler> #action establish tech debt ticket to remove insecure option
22:54:21 <juggler> #topic Open Discussion
22:54:29 <juggler> proceeding
22:54:36 <juggler> any open comments folks?
22:54:43 <adrian_otto> If you have not recorded your topics in https://etherpad.openstack.org/p/magnum-liberty-midcycle-topics
22:54:45 <tcammann1> Can we add a Magnum UI update to the adjenda for future meetings. There seems to be no progress
22:54:46 <adrian_otto> please do that now
22:55:03 <adrian_otto> yes, I think there is a better way to get updates on the high priority BPs
22:55:21 <adrian_otto> I should email the owners the day before our meeting, and have the status up on our agenda page for reference
22:55:35 <adrian_otto> and our members can read the ones they care about
22:55:39 <juggler> #action item Add Magnum UI update section to the agenda for future meetings
22:55:51 <adrian_otto> and I can call attention to ones that appear to be stalled
22:55:56 <adrian_otto> is that fair?
22:56:08 <adrian_otto> tcammann1: yes.
22:56:10 <madhuri_> +1
22:56:19 <Tango> +1
22:56:25 <hongbin> +1
22:56:27 <juggler> #action All: Record MidCycle topics prior to the MidCycle: https://etherpad.openstack.org/p/magnum-liberty-midcycle-topics
22:56:44 <adrian_otto> and in your respective email responses, you can let me know if you want a position on the agenda for team discussion
22:56:49 <adrian_otto> or just provide the written update
22:57:34 <adrian_otto> that should free up more time for higher value discussion
22:58:06 <adrian_otto> thanks juggler for assisting with chair duty
22:58:29 <juggler> #action Contact adrian_otto for MidCycle agenda discussion topics via e-mail
22:58:33 <juggler> you are welcome
22:58:40 <tcammann1> thanks juggler
22:58:41 <adrian_otto> our next team meeting is scheduled for Tuesday 2015-08-04 at UTC 1600.
22:58:49 <juggler> further discussion will be in our regular channel.
22:58:57 <adrian_otto> any final thoughts before juggler adjourns us?
22:58:58 <madhuri_> Thanks everyone
22:59:04 <adrian_otto> cheers!!
22:59:12 <hongbin> The next meeting is one day before the midcycle?
22:59:18 <adrian_otto> yes sir
22:59:24 <hongbin> Then we still do it?
22:59:28 <adrian_otto> yes.
22:59:30 <hongbin> k
22:59:31 <juggler> correct
22:59:32 <tcammann1> I'll be in the right timezone for that one!
22:59:40 <juggler> thank you for stopping by all!
22:59:45 <juggler> #endmeeting