16:04:26 <ewindisch> #startmeeting containers
16:04:26 <openstack> Minutes:        http://eavesdrop.openstack.org/meetings/_openstack_containers/2015/_openstack_containers.2015-06-09-16.03.html
16:04:27 <openstack> Minutes (text): http://eavesdrop.openstack.org/meetings/_openstack_containers/2015/_openstack_containers.2015-06-09-16.03.txt
16:04:28 <openstack> Log:            http://eavesdrop.openstack.org/meetings/_openstack_containers/2015/_openstack_containers.2015-06-09-16.03.log.html
16:04:29 <openstack> Meeting started Tue Jun  9 16:04:26 2015 UTC and is due to finish in 60 minutes.  The chair is ewindisch. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:32 <openstack> The meeting name has been set to 'containers'
16:04:38 <ewindisch> been a while!
16:04:51 <ewindisch> #topic roll call
16:05:08 <bich_le> Good morning from California.
16:05:09 <diga__> Digambar Patil
16:05:11 <hongbin> o/
16:05:11 <rpothier> Rob Pothier
16:05:12 <ewindisch> o/
16:05:14 <Tango> Ton Ngo
16:05:19 <adrian_otto> thanks ewindisch
16:05:21 <juggler> o/
16:05:24 <bradjones> o/
16:05:26 <eghobo> o/
16:05:27 <joffter> o/
16:05:29 <dane_leblanc> o/
16:05:44 <ewindisch> #topic Announcements
16:05:56 <ewindisch> feel free to 'o/' if you missed rollcall
16:06:17 <ewindisch> 1) adrian_otto and sdake are out today due to travel
16:06:26 <ewindisch> 2) Reminder that OpenStack milestone 11 comes on June 25
16:06:32 <ewindisch> any other announcements from the community?
16:07:02 <ewindisch> going once..
16:07:17 <jjlehr> o/
16:07:24 <ewindisch> twice
16:07:29 <thomasem> o/
16:07:43 <ewindisch> and... done
16:07:57 <muralia1> o/
16:08:03 <ewindisch> #topic Blueprint / Task review
16:08:18 <diga__> I need some inputs on this one https://blueprints.launchpad.net/magnum/+spec/mesos-bay-type
16:08:34 <diga__> mesos bay with coreos
16:08:40 <diga__> hongbin: you there
16:08:47 <hongbin> yes
16:09:18 <diga__> Here I need to run coreos instance with mesos installed
16:09:19 <ewindisch> any others anyone wishes to review? the agenda has auto-generate-name and magnum-horizon-plugin
16:09:25 <diga__> right ?
16:09:48 <diga__> I am starting work on this today
16:10:07 <hongbin> diga__: #link https://blueprints.launchpad.net/magnum/+spec/mesos-bay-with-coreos
16:10:16 <diga__> oops
16:10:19 <ewindisch> diga__: I can look at getting you feedback for Swarm+Mesos if you'd like
16:10:44 <eghobo> diga__: are you going to build mesos for CoreOS?
16:10:45 <diga__> ewindisch: sure
16:10:51 <diga__> yes
16:11:19 <eghobo> any specific reasons why do you need CoreOS?
16:11:22 <ewindisch> diga__: send me an email and I can get you an introduction to the right folks to answer questions; ewindisch -at- docker com
16:11:37 <diga__> ewindisch: Thanks
16:11:42 <mfalatic> o/
16:11:53 <hongbin> eghobo: That is decided on the last meeting I think.
16:12:06 <hongbin> eghobo: We will have mesos on ubuntu and coreos
16:12:18 <hongbin> Then, operators can choose their preferred os
16:12:22 <diga__> yes
16:13:14 <hongbin> any other inputs from the mesos BP?
16:13:27 <ewindisch> any objections to it?
16:13:36 <diga__> ewindisch: will send you all the question which I need to clarify
16:14:00 <diga__> nops
16:14:08 <eghobo> hongbin: I will review deeply, sorry was busy last week
16:14:16 <ewindisch> #action diga__ to contact ewindsich regarding Swarm+Mesos questions
16:14:17 <hongbin> eghobo: NP
16:14:29 <ewindisch> diga__: I would say this blueprint needs to decide on a framework before proceeding
16:14:45 <diga__> ewindisch: yes
16:15:38 <diga__> ewindisch: currently we have decided to go with mesos+marathon for this BP
16:15:39 <ewindisch> diga__: want that as an AI as well, to decide on the framework?
16:15:44 <ewindisch> ah
16:15:54 <diga__> AI ??
16:16:03 <ewindisch> diga__: then perhaps reflect that in the BP ;-)
16:16:07 <ewindisch> diga__: action item
16:16:14 <diga__> okay
16:16:30 <hongbin> ewindisch: Marathon is the first framework
16:16:39 <hongbin> Other frameworks will be supported on demand
16:16:55 <hongbin> Sure. That needs further discussion
16:17:08 <ewindisch> I see now, that the bottom indicates that Marathon would be the first supported
16:17:29 <hongbin> Yes, it is
16:17:39 <ewindisch> okay. Ready for the next BP?
16:17:42 <rbradfor> o/
16:18:00 <ewindisch> #link https://blueprints.launchpad.net/magnum/+spec/auto-generate-name
16:18:31 <ewindisch> Any objections to approving this? Any takers to own this?
16:19:07 <jay-lau-513> this might need more discussion, but I think that we can first make the auto generate name in
16:19:22 <jay-lau-513> make sense?
16:20:07 <hongbin> How about the uniqueness of the name?
16:20:13 <ewindisch> the mailing list discussion seems to have gone in a good, forward direction. I don't see any significant questions as to what needs to be done.
16:20:29 <eghobo> jay-lau-513: what's your concerns?
16:20:53 <eghobo> lets discuss them before approving bp
16:21:10 <jay-lau-513> ok, so we need to make the allow_duplicate_baymodel_name configurable for this bp
16:21:17 <diga__> dont we really need auto-generated name ??
16:21:19 <ewindisch> hongbin: do you wish the BP notes a specific number of autogenerated name permutations?
16:22:06 <hongbin> ewindisch: Haven't thought about it yet
16:22:07 <jay-lau-513> hongbin a configuration parameter will decide if the name is unique or not
16:22:11 <ewindisch> personally, I'm an advocate of always having unique names, but that's because I'm also an advocate of using the name to generate the UUID.
16:22:32 <ewindisch> but unique names means the auto-generator needs to have a very large number of permutations
16:23:26 <jay-lau-513> ewindisch I think that we can have same names under different tenant
16:23:38 <ewindisch> jay-lau-513: that's fine.
16:23:56 <ewindisch> jay-lau-513: I mean the same name should be unique within a tenant
16:24:31 <eghobo> ewindisch: +1, let add this to bp
16:24:35 <ewindisch> is there a legitimate, strong desire for allowing duplciate bay/model names?
16:24:37 <juggler> would it be beneficial for the BP to describe a few example cases maybe?
16:25:16 <jay-lau-513> I recalled that Adrian do want to introduce a global baymodel
16:25:24 <jay-lau-513> but this can be another bp
16:25:49 <jay-lau-513> ewindisch duplicate name might be only for multi tenant, thoughts?
16:26:21 <Tango> So for a tenant, name is always unique?
16:26:40 <hongbin> I think autogenerated name + config for allow duplicate will be the starting point
16:26:42 <ewindisch> jay-lau-513: yes, I never meant to suggest that names could not be duplicated *across* tenants. That's okay
16:26:49 <ewindisch> so I can call a vote on this.
16:26:51 <hongbin> We can worry about tenant and glance name later
16:27:24 <jay-lau-513> so we all agree on making this configurable now?
16:27:49 <ewindisch> jay-lau-513: why make it configurable?
16:28:06 <juggler> hang on...how about my feedback above?
16:28:20 <ewindisch> juggler: example cases?
16:29:14 <ewindisch> juggler: I think it would be useful to see how this proposes to generate the names, in the format and complexity of those names.
16:29:19 <juggler> yes, like for example, what example output is expected from the function
16:29:29 <jay-lau-513> ewindisch 2) Add a configuration directives (default=FALSE) for allow_duplicate_bay_name
16:29:29 <jay-lau-513> and allow_duplicate_baymodel_name. If TRUE, duplicate named Bay and BayModel
16:29:29 <jay-lau-513> resources will be allowed, as they are today.
16:29:29 <jay-lau-513> This way, by default Magnum requires a unique name, and if none is specified, it
16:29:29 <jay-lau-513> will automatically generate a name. This way no additional burden is put on
16:29:30 <jay-lau-513> users who want to act on containers exclusively using UUIDs, and cloud operators
16:29:32 <jay-lau-513> can decide if they want to enforce name uniqueness or not.
16:29:34 <jay-lau-513> 
16:29:40 <jay-lau-513> weindisch get from Adrian's comments
16:31:06 <juggler> ewindisch yeah, I think having an example clarifies the bp well
16:31:21 <juggler> ewindisch esp with a clear format idea
16:32:53 <ewindisch> jay-lau-513: I read the BP. I just don't see the use-case for allowing duplicates (within a tenant)
16:33:17 <ewindisch> jay-lau-513: perhaps we defer to the mailing list and make sure this gets fleshed out?
16:33:39 <jay-lau-513> ewindisch i think so
16:33:45 <hongbin> Yes, sure
16:34:06 <ewindisch> jay-lau-513: I like juggler's suggestion of clarifying the uniqueness algorithm. Okay with adding that to the BP?
16:34:32 <jay-lau-513> ewindisch yes, i will try to get some idea from docker for how to generate names
16:35:01 <ewindisch> jay-lau-513: feel free to read that code, but I will suggest it's not the best algorithm in the world
16:35:03 <diga__> +1
16:35:46 <jay-lau-513> ewindisch ok
16:36:03 <jay-lau-513> ewindisch just want to see if I can get some idea from it
16:36:44 <juggler> jay-lau-513 thx for the clarifying
16:36:56 <ewindisch> jay-lau-513: personally, I'd advise a combination of 4 words constructed from 3-4 letter words from a dictionary of several thousand words. That will give you a trillion unique names. The Docker method gives you a few thousand unique names
16:37:39 <diga__> jay-lau-513: you may want to take a look at this - https://github.com/docker/docker/blob/master/pkg/namesgenerator/names-generator.go
16:37:56 <jay-lau-513> juggler ewindisch diga__ thanks all
16:38:00 <jay-lau-513> will have a try
16:38:19 <diga__> yep
16:38:25 <ewindisch> #action jay-lau-513 Clarify human name generation algorithm plans in BP
16:38:53 <eghobo> ewindisch: thousand running containers at the same host, sounds good enough ;)
16:38:58 <ewindisch> #action jay-lau-513 Seek consensus on duplicate names on ML
16:39:19 <eghobo> I doubt we will have thousand of bay models
16:39:37 <ewindisch> eghobo: right, but if this algorithm is used in Magnum for container names eventually, it would be good if it handled more than a few thousand for a datacenter
16:39:53 <ewindisch> eghobo: I agree the docker model will be enough for BayModels
16:39:56 <jay-lau-513> exactly
16:40:45 <ewindisch> okay, next BP?
16:41:03 <ewindisch> #link https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin
16:41:05 <juggler> sounds good
16:41:20 <eghobo> jay-lau-513: also make sense to take a look at Elastic Search algorithm, just for ideas
16:41:26 <juggler> (reviewing it that is.. :) )
16:41:53 <jay-lau-513> eghobo i c
16:42:42 <bradjones> I can talk about magnum-horizon-plugin
16:42:57 <bradjones> spec is out for review here https://review.openstack.org/#/c/188958/
16:43:07 <ewindisch> I'm not sure where discussion on this left off. The agenda mentions that there was a consensus on identifying interested contributors and adding them to magnum core
16:43:16 <ewindisch> I see the BP now lists several interested contributors
16:43:32 <eghobo> my concern is "Pod, Container, Service, ReplicationController" it's very kub specific
16:44:05 <hongbin> ewindisch: The discussion is whether to create a new team for magnum-ui, or not
16:44:09 <ewindisch> eghobo: I don't think that's in the scope of this BP anyway
16:44:20 <ewindisch> sounds like, "post BP work"
16:44:43 <eghobo> ewindisch: if it's not lets remove it from bp
16:44:46 <jay-lau-513> yes, the current bp want to focus on bay and baymodel
16:44:47 <rbradfor> eghobo, these name scope issues matches the problems with the openstackclient problems, e.g. "container" is already used for image management.
16:45:54 <bradjones> the spec talks about magnum-ui as a complete entity which will eventually include Pod, Container ... but the initial effort is centered around Bay and BayModel
16:46:26 <eghobo> ok, I agree that  Bay and BayModel is good to start
16:46:28 <ewindisch> bradjones: Perhaps clarify that such will be carried out in future blueprints, and are only examples of future direction
16:46:44 <bradjones> ewindisch: sure I can make that clearer in the spec
16:46:50 <ewindisch> bradjones: thanks
16:47:10 <eghobo> after that we will add sub plugins for Kub, Mesos, Swarm (sounds like Neutron ;))
16:48:15 <ewindisch> bradjones: how about I propose to Adrian that he add you as Magnum core and then as this moves forward, future -ui folks may join in as well?
16:48:43 <ewindisch> or at least until a meeting that he chairs and can make such decisions
16:48:47 <ewindisch> ;-)
16:48:58 <bradjones> ewindisch: sure however works best
16:49:28 <ewindisch> anyone outright disagree with spec/magnum-horizon-plugin ?
16:50:14 <eghobo> bradjones: I have question about separate git repo
16:50:24 <bradjones> eghobo: fire away
16:50:55 <eghobo> I thought all Horizon plugins in Horizon repo
16:51:17 <hongbin> ewindisch: For the ui, sdake proposed a separated ui team in this ML http://lists.openstack.org/pipermail/openstack-dev/2015-June/066296.html
16:51:22 <bradjones> eghobo: it has been that way until recently however, they are trying to move away from that model
16:51:44 <ewindisch> hongbin: thanks
16:51:59 <hongbin> The idea is to start a new ui team
16:52:00 <eghobo> I see, I didn't know that thx for clarification
16:52:01 <bradjones> Horizon will just become the building blocks for other OpenStack projects to build their UIs with and pull them all together
16:52:07 <ewindisch> so how about we just agree to defer to Adrian? :)
16:52:15 <hongbin> sure
16:52:22 <bradjones> It makes sense especially with Big Tent otherwise Horizon would have to manage all the things!
16:52:37 <juggler> ewindisch lol!
16:53:05 <bradjones> ewindisch: sounds good, will just be good to get a decision made soon so I can move forward with creating the repo
16:53:35 <ewindisch> shucks, lets vote.
16:53:57 <ewindisch> #startvote Create separate magnum-ui-core team (and repo)
16:53:57 <openstack> Unable to parse vote topic and options.
16:54:03 <ewindisch> #help
16:54:18 <ewindisch> #startvote
16:54:19 <openstack> Unable to parse vote topic and options.
16:54:54 <diga__> ewindisch: "startvote" wont work, you can directly ask for vote
16:54:56 <ewindisch> #startvote Create separate magnum-ui-core team (and repo)? Yes, No
16:54:57 <openstack> Begin voting on: Create separate magnum-ui-core team (and repo)? Valid vote options are Yes, No.
16:54:58 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
16:55:14 <ewindisch> #vote Yes
16:55:21 <hongbin> #vote Yes
16:55:23 <jay-lau-513> #vote Yes
16:55:25 <Tango> Yes
16:55:28 <diga__> #vote Yes
16:55:29 <juggler> #vote Yes
16:55:31 <rbradfor> #vote Yes
16:55:38 <bich_le> #vote yes
16:55:55 <bich_le> #vote Yes
16:55:55 <rpothier> #vote Yes
16:56:06 <eghobo> #vote No, I prefer to have one core team for magnum
16:56:07 <openstack> eghobo: No, I prefer to have one core team for magnum is not a valid option. Valid options are Yes, No.
16:56:40 <eghobo> #vote No
16:56:49 <ewindisch> all in?
16:57:07 <joffter> #vote Yes
16:57:15 <ewindisch> mfalatic: thomasem: muralia1 ?
16:57:25 <jay-lau-513> Perhaps we can ask Sahara Team for some experience
16:57:35 <jay-lau-513> I see Sahara has only one core team
16:57:44 <muralia1> #vote: yes
16:57:45 <openstack> muralia1: : yes is not a valid option. Valid options are Yes, No.
16:57:46 <jay-lau-513> Just curious how they run different projects with one core tem
16:57:55 <ewindisch> 3...
16:57:59 <muralia1> #vote: Yes
16:58:00 <openstack> muralia1: : Yes is not a valid option. Valid options are Yes, No.
16:58:05 <rbradfor> Infra has now created a council, more a management over smaller core teams.
16:58:11 <ewindisch> 2...
16:58:13 <juggler> muralia1 maybe lose the colon
16:58:20 <muralia1> #vote Yes
16:58:22 <muralia1> :)
16:58:24 <ewindisch> 1...
16:58:29 <thomasem> #vote yes
16:58:29 <mfalatic> #vote:yes
16:58:30 <juggler> yea!
16:58:30 <openstack> mfalatic: :yes is not a valid option. Valid options are Yes, No.
16:58:37 <mfalatic> #vote: yes
16:58:38 <openstack> mfalatic: : yes is not a valid option. Valid options are Yes, No.
16:58:42 <mfalatic> #vote: Yes
16:58:42 <openstack> mfalatic: : Yes is not a valid option. Valid options are Yes, No.
16:58:48 <thomasem> sorry, ewindisch, was still reading through
16:58:48 <ewindisch> hah
16:58:50 <mfalatic> #vote Yes
16:58:53 <mfalatic> lol
16:58:55 <mfalatic> ok then
16:58:57 <diga__> guys we are running out of time
16:59:07 <ewindisch> #endvote
16:59:08 <openstack> Voted on "Create separate magnum-ui-core team (and repo)?" Results are
16:59:10 <openstack> Yes (12): juggler, hongbin, diga__, rbradfor, rpothier, jay-lau-513, ewindisch, muralia1, bich_le, mfalatic, joffter, thomasem
16:59:11 <openstack> No (1): eghobo
16:59:31 <ewindisch> #agreed Recommend to adrian_otto to create separate ui team
16:59:47 <ewindisch> with eghobo's concerns considered!
16:59:48 <juggler> good time for meeting closure stuff
16:59:51 <ewindisch> yep
16:59:59 <juggler> or relocation housekeeping :)
17:00:01 <ewindisch> #topic Open Discussion
17:00:06 <ewindisch> seconds ... anything?
17:00:18 <juggler> feel free to review: https://bugs.launchpad.net/magnum/+bug/1451678
17:00:19 <openstack> Launchpad bug 1451678 in Magnum "Add link to dev-manual-devstack.rst into document dev-quickstart.rst" [High,In progress] - Assigned to P Rivera (juggler)
17:00:31 <juggler> not now, but later ;)
17:00:36 <ewindisch> okay, giving it 30 seconds and then closing.
17:00:42 <ewindisch> continuing in #openstack-containers
17:00:49 <rbradfor> Infra is requesting a +1 from Magnum core team to add coverage to review process -- https://review.openstack.org/#/c/187753/
17:01:05 <ewindisch> thanks everyone!
17:01:08 <ewindisch> #endmeeting