16:00:07 <hongbin> #startmeeting containers
16:00:08 <openstack> Meeting started Tue Apr 19 16:00:07 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <openstack> The meeting name has been set to 'containers'
16:00:15 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-04-19_1600_UTC Today's agenda
16:00:20 <hongbin> #topic Roll Call
16:00:21 <adrian_otto> Adrian Otto
16:00:27 <muralia> murali allada
16:00:32 <Kennan_> Kennan
16:00:36 <strigazi> \o Spyros Trigazis
16:00:42 <tango__> Ton Ngo
16:00:55 <juggler> o/ Perry Rivera
16:00:58 <dane_leblanc> o/
16:01:03 <eghobo> o/
16:01:51 <hongbin> Thanks for joining the meeting adrian_otto muralia Kennan_ strigazi tango__ juggler dane_leblanc eghobo
16:02:01 <hongbin> #topic Announcements
16:02:08 <hongbin> #link https://review.openstack.org/#/c/300828/ The release module of python-magnumclient and magnum-ui was changed to cycle-with-intermediary
16:02:33 <hongbin> Basically, that means we committed to deliver a final release at the end of the cycle
16:02:54 <hongbin> This will match better with the release schedule of the rest of the community
16:03:02 <hongbin> Any comment for that?
16:03:12 <adrian_otto> it also allows us to tag intermediate releases as well
16:03:19 <hongbin> yes
16:03:45 <hongbin> #topic Review Action Items
16:03:52 <hongbin> 1. hongbin sent a ML to collect opinions from general OpenStack community (including Keystone team) for option #1
16:03:58 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/092155.html
16:04:14 <hongbin> There are many responses in the ML
16:04:23 <hongbin> We will discuss it later in the meeting
16:04:32 <hongbin> 2. hongbin created another BP for adding Chronos to mesos
16:04:38 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/introduce-chronos
16:05:16 <hongbin> Any question for these action items?
16:05:41 <hongbin> #topic Plan for design summit topics
16:05:47 <hongbin> #link https://etherpad.openstack.org/p/magnum-newton-design-summit-topics Etherpad collaborating topics for Magnum Newton design summit
16:06:10 <hongbin> The schedule and room of the design summit was basically finallized
16:06:19 <hongbin> Please check the etherpad for details
16:06:48 <hongbin> At this stage, it is too late to adjust the schedule, unless the majority is not satisfied
16:07:07 <hongbin> Any comment for the design summit?
16:07:27 <hongbin> (Pause for a second)
16:07:48 <muralia> i see that the openstack app has been updated with all magnum sessions too. thats a good way to keep track of them
16:07:58 <strigazi> Is anyone of us going to the Documentation session?
16:08:18 <strigazi> They will probably discuss the install guide doc-spec
16:08:32 <hongbin> strigazi: I am not sure if I am able to make it (haven't checked the time yet)
16:08:42 <strigazi> Do we have a proposal as a team?
16:09:09 <hongbin> #link https://review.openstack.org/#/c/301284/
16:09:29 <hongbin> FYI, the docs team plan to push out documentation of the big-tent projects out of tree
16:10:02 <hongbin> If that happens, Magnum installation guide will not be part of the openstack manual
16:10:04 <strigazi> Wed 11:50am-12:30pm
16:10:21 <hongbin> strigazi: thanks
16:10:36 <hongbin> The docs team will disucss the proposal in the session
16:11:11 <hongbin> If you have opinions on the proposal, I would suggest you to go to their session
16:11:31 <hongbin> OK. Let's advance topics
16:11:37 <hongbin> #topic Essential Blueprints Review
16:11:43 <hongbin> SKIP until we identify a list of essential blueprints for Newton
16:11:49 <hongbin> #link https://blueprints.launchpad.net/magnum/newton List of blueprints for Newton so far
16:12:01 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:12:07 <hongbin> 1. Barbican alternative store
16:12:14 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store
16:12:42 <hongbin> As mentioned in the AI reviews, I sent a ML to collect ideas
16:12:59 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/092155.html
16:13:32 <hongbin> The discussion is about if Keystone team allows us to use the /credential endpoint for storing TLS credentials
16:13:47 <hongbin> Obviously, they didn't say yes or no
16:14:20 <hongbin> Most of the replies are for selling Barbican
16:14:57 <hongbin> If they don't disagree, I am OK to include it as an option
16:15:14 <hongbin> Basically, there are three proposed options
16:15:28 <hongbin> 1. Store TLS credentials in Keystone
16:15:36 <hongbin> 2. Store TLS credentials in Magnum DB
16:15:52 <hongbin> 3. Switch to an non-TLS authentication system
16:16:13 <adrian_otto> I have a question about the #2 implementation
16:16:55 <hongbin> adrian_otto: ?
16:16:57 <adrian_otto> do we need to expose the "fetch TLS credentials" method through the API do it can be accessed from a bay node?
16:17:31 <adrian_otto> or does only the conductor need access to it?
16:18:02 <hongbin> adrian_otto: I think both conductor and bay nodes need to access it (need to confirm though)
16:18:58 <hongbin> Comments?
16:19:23 <adrian_otto> in that case, my preference is #2, #1, #3
16:19:25 <tango__> it seems kubelet needs the credential to talk to kube-apiserver
16:19:52 <tango__> (from the bay nodes)
16:20:10 <hongbin> adrian_otto: To confirm, you seems to prefer #1 in the last meeting. Are you sure?
16:20:17 <Kennan_> it seems to me that native client tools need to use related TLS config to access node services
16:20:58 <adrian_otto> +1
16:21:03 <hongbin> My preference is #3, but I am OK to have #1 or #2 as a short term approach
16:21:17 <adrian_otto> that's the one that the range of different COE's all have in common.
16:21:55 <adrian_otto> there should be a long term plan to deprecate this feature once Barbican becomes common in OpenStack clouds.
16:22:39 <hongbin> Could we make a decision right now, or leave it to design summit?
16:22:41 <adrian_otto> or do as Keystone has suggested and backend the feature on Barbican if it's available in the service catalog.
16:23:33 <adrian_otto> remember that the motivation behind the feature is to allow for lower friction adoption of Magnum in clouds that have not yet adopted Barbican.
16:23:40 <rochaporto> #2 (and later #3 if possible) would be great. and we're finishing the deployment of barbican and will later send feedback on the missing dots and issues we worked out
16:24:11 <hongbin> Could we all agree on #2?
16:24:30 <tango__> Sounds reasonable
16:24:34 <muralia> +1, i like that
16:24:34 <hongbin> Any disagreement?
16:24:40 <redrobot> hongbin as long as barbican backend is still an option, yes #2 would be fine.
16:24:47 <Kennan_> did #2 have HA support ?
16:24:59 <juggler> +1 for #2
16:25:02 <hongbin> Kennan_: Yes, it should have
16:25:12 <hongbin> redrobot: ack. thx
16:25:25 <Kennan_> it seems ok if keystone could hanle that
16:25:49 <hongbin> #AGREED: Magnum will store TLS credentials in DB as short term solution
16:26:07 <hongbin> 2. Introduce Chronos framework for mesos bay (Jay Lau)
16:26:20 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091835.html Discussion in ML
16:26:25 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/introduce-chronos The blueprint
16:26:59 <hongbin> For recap, we were debating two options in the last meeting
16:27:16 <hongbin> 1. Add Chronos to mesos bay (directly)
16:27:37 <hongbin> 2. Support configuration hook for users to add Chronos (or other mesos frameworks)
16:28:02 <tango__> Is there a consensus that Marathon and Chronos are used together in the common case?
16:28:22 <tango__> That seems to be the argument for #1
16:28:35 <hongbin> tango__: My feeling is that they are used togther, but I cannot cite a source
16:29:00 <hongbin> eghobo: any comment from your side?
16:29:07 <Kennan_> it seems depends on user cases
16:29:27 <tango__> If that's the case, then we can start with #1 and treat Marathon + Chronos as the supported frameworks
16:29:40 <tango__> Then proceed to #2 to support other frameworks
16:29:43 <adrian_otto> wait, the #2 approach is a feature tha's useful beyond the scope of this
16:30:15 <hongbin> adrian_otto: I agree
16:30:17 <adrian_otto> so these shoudl not be considered mutually exclusive
16:30:36 <Kennan_> I tend to agree +2 if implementation could cover that, as #2 include #1 use cases
16:30:37 <hongbin> A combination of #1 and #2?
16:30:41 <eghobo> hongbin: i don't have strong opinion, in our case we would like everything run at marathon (to minimize ops), dcos has the same aproach
16:31:11 <adrian_otto> I recognize that running Chronos through Marathon offers benefits beyond running it directly as a framework in Mesos.
16:31:20 <hongbin> Kennan_: ack
16:31:30 <adrian_otto> so if we do offer it in the Mesos bay, it makes sense to set it up that way to begin with.
16:32:00 <tango__> It seems that #1 should be quick and easy to implement, if we want to bundle Marathon + Chronos as a useful use case
16:32:01 <Kennan_> running Chronos on top of Marathon ? adrian_otto:
16:32:31 <adrian_otto> Kennan_: yes, that's what I'm suggesting.
16:32:37 <Kennan_> one question not clear to me, run two frameworks or run one on top of another ?
16:32:49 <Kennan_> it seems not same for these two cases
16:33:07 <eghobo> adrian_otto: also most users (at least in our case) wants both Chronos and Marathon
16:33:23 <adrian_otto> the key advantage is that Marathon can be responsible for making sure there is always a Mesos scheduler active, and that you don't have more than one trying to act at the same time.
16:33:40 <adrian_otto> eghobo: I'm suggesting they are offered together.
16:33:58 <eghobo> adrian_otto: +1
16:34:30 <hongbin> adrian_otto: you are suggesting a combination of #1 and #2?
16:34:34 <adrian_otto> but the logical arrangement is Bay -> Mesos -> Marathon -> Chronos rather than Bay -> Mesos -> Marathon + Chronos
16:34:55 <adrian_otto> and that #2 can be considered a separate feature to allow adding more frameworks.
16:35:17 <adrian_otto> for example, fi you wanted to run Hadoop next to Marathon
16:36:09 <tango__> #2 will take some more work to design, and we can refactor Marathon -> Chronos as the supported framework
16:36:55 <tango__> So maybe we can start with #1 and proceed to #2.   They are not necessaritly mutually exclusive, as Adrian noted
16:37:27 <Kennan_> adrian_otto: it seems run top of chronos is same as option #1(from code implemention point of view)
16:38:04 <Kennan_> typo run chronos on top of marathon
16:38:27 <hongbin> Yes, I think run Chronos on top of Marathon is a good idea
16:38:42 <hongbin> But the key point is who are do the work
16:38:46 <hongbin> Magnum? User?
16:39:28 <hongbin> For example, Magnum could add support for configuring Chronos on top of Marathon
16:39:44 <hongbin> Or, we can leave it to users (by using the configuration hook)
16:40:13 <hongbin> adrian_otto: Do you think Magnum should do the work or leave it to users?
16:40:43 <hongbin> If we cannot decide, I can leave it to design summit
16:41:05 <hongbin> (We have another topic to discuss today)
16:41:06 <Kennan_> #1 is short term solution, and #2 is long term way to go , I think
16:41:35 <tango__> I think both can proceed in parallel
16:41:42 <adrian_otto> I think we should be careful not to bring more into scope for Magnum than we can manage gracefully.
16:41:56 <hongbin> OK, push it to design summit
16:42:03 <hongbin> 3. Magnum potential use cases for Glare to improve images management (Ton Ngo, Nikhil Komawar)
16:42:09 <nikhil> o/
16:42:26 <hongbin> tango__: nikhil : please proceed
16:42:31 <nikhil> tango__: hi
16:42:31 <adrian_otto> so if (re) integrating Chronos upon each release becomes burdensome, we should discuss moving it to a post-configuration hook that the user accepts the burden of keeping up with.
16:42:56 <Kennan_> is this link correct ? https://login.launchpad.net/+id/Fr4nmMm
16:43:00 <nikhil> I was more curious about the cataloging requirements of magnum...
16:43:03 <Kennan_> it seems user ID
16:43:03 <nikhil> Kennan_: no
16:43:04 <tango__> This is a new development that we would like to bring to the attention of the team
16:43:05 <nikhil> #link https://www.openstack.org/summit/austin-2016/summit-schedule/events/9162?goback=1
16:43:23 <tango__> Basically, our image management is pretty ad hoc at this point
16:43:47 <tango__> We only register the distro as a property with the image in Glance
16:44:04 <tango__> there is no way to tract version, know what's in the image, etc
16:44:24 <tango__> There is a new effort to address some of these issues in Glance
16:44:51 <tango__> There is a session at the summit to collect use cases, and discuss the proposal
16:45:05 <tango__> Nikhil is one of the person leading the effort, Glare
16:45:40 <Kennan_> tango__ one question, what's the glance image metadata difference from Glare ?
16:45:44 <nikhil> Thanks tango__
16:45:48 <tango__> So, we should give some thought on what we would like to have as our use cases, especially now that we are working on designing the bay driver
16:46:38 <tango__> Nikhil, would you like to answer Kennan's question?
16:46:45 <nikhil> sure..
16:46:52 <nikhil> firstly, it's the old-new effort rebranded from artifacts to GLARE (GLance Artifacts REpository) :)
16:47:27 <nikhil> Basically, today in glance we support images and the focus is on the simplistic design that was proposed back from bexar when nova was the sole consumer
16:47:45 <nikhil> then came glance v2 that focussed on the public/user and nova like services
16:48:19 <nikhil> Nevertheless, there are some constraints that prevent storing generic openstack data assets and maintain them wisely
16:48:47 <nikhil> so, to answer Kennan_'s question precisely (from that context) -- I'd say the metadata in Glare would be similar as in Glance
16:48:52 <nikhil> but with subtle different
16:49:19 <nikhil> there is a generic API that provides skeleton of the meta for each artifact type -- here container-imgs
16:49:41 <nikhil> but you can add more specific structure to the meta based on the requirements and description
16:50:02 <nikhil> a POC for that should be ready in the next couple days and hopefully we can explain this at the session
16:50:28 <nikhil> I wanted to put this forward to gather more interest, requirements and constraints from magnum team!
16:50:38 <hongbin> Here are the potential Magnum use cases I can think of
16:50:42 * nikhil done. thanks everyone for listening.
16:50:47 <hongbin> 1. store list of COEs
16:51:02 <hongbin> 2. store the middleware pre-built into the image
16:51:12 <hongbin> 3. store the version of each middleware
16:51:37 <hongbin> 4. store the distro of hte image
16:52:00 <hongbin> 5. Maybe indicate the flavor of hte image (Ironic? VM?)
16:52:09 <hongbin> That is what I can think of
16:52:21 <tango__> Sounds good for the start.  The session is on Wed afternoon, so there is no conflict with Magnum sessions.
16:52:56 <hongbin> Thanks tango__ and nikhil
16:53:00 <Kennan_> like to see some demo for Glare use cases, to make understand it more
16:53:11 <nikhil> surely
16:53:20 <hongbin> #topic Open Discussion
16:53:27 <nikhil> we are currently collab with app-catalog team and murano team
16:53:40 <nikhil> we meet every monday as well
16:54:05 <nikhil> hopefully at one of these occurrences we can provide some demo like stuff
16:54:13 <nikhil> and there is a plan to release a video demo for this soon
16:54:16 * nikhil done
16:54:56 <nikhil> Thanks hongbin and tango__! Hoping that we get a liaison(s)/repr(s) at the session from magnum team!
16:55:45 <rochaporto> will the not implemented mitaka blueprints move to newton? or only a few? also, would be nice to get the rally one approved for newton
16:56:24 <hongbin> rochaporto: I have no problem to approve the rally one
16:56:36 <tango__> The rally bp should be moved to the Rally project?
16:56:37 <rochaporto> hongbin: great, thanks :)
16:56:53 <hongbin> rochaporto: For the mitaka blueprints, I think most of them will be pushed to Newton
16:57:25 <hongbin> #action hongbin revisit the unfinished mitaka blueprints
16:57:28 <strigazi> tango__: yes that is the proccess
16:57:59 <tango__> I am about to open a BP for Magnum in Rally, since we are submitting patches there
16:58:12 <tango__> Then we can link our BP to the Rally BP
16:59:09 <hongbin> tango__: Sounds good to me
16:59:10 <Kennan_> Good  to know that tango__
16:59:40 <vilobhmm11> tango__ : +1
17:00:01 <rochaporto> great, looking forward to the summit
17:00:17 <hongbin> OK. Let's wrap up
17:00:33 <hongbin> All, thanks for joining the meeting. Looking forward to seeing you all in Austin
17:00:36 <hongbin> #endmeeting