16:00:10 <hongbin> #startmeeting containers
16:00:13 <openstack> Meeting started Tue Aug 23 16:00:10 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:16 <openstack> The meeting name has been set to 'containers'
16:00:18 <hongbin> #topic Roll Call
16:00:24 <muralia> Murali Allada
16:00:27 <tonanhngo> Ton Ngo
16:00:35 <swatson_> Stephen Watson o/
16:00:41 <hieulq_> o/
16:00:47 <jvgrant> Jaycen Grant
16:00:55 <dane_leblanc> o/
16:01:41 <hongbin> Thanks for joining the meeting muralia tonanhngo swatson_ hieulq_ jvgrant dane_leblanc
16:01:44 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-08-23_1600_UTC Today's agenda
16:01:47 <muralia> Hi all
16:01:49 <hongbin> Anything needs to be added to the agenda?
16:02:05 <eghobo> o/
16:02:14 <vijendar> o/
16:02:16 <hongbin> #topic Announcements
16:02:28 <hongbin> I have no announcement, any from others?
16:02:45 <hongbin> #topic Review Action Items
16:02:51 <hongbin> 1. hongbin create a BP for API docs
16:02:57 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-doc-rest-api There is already a BP about API docs
16:03:07 <hongbin> 2. hongbin add rename-bay-to-cluster BP to the meeting agenda (DONE)
16:03:13 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-08-23_1600_UTC
16:03:33 <hongbin> Any question regarding to the review action items?
16:03:58 <hongbin> #topic Essential Blueprints Review
16:04:04 <hongbin> 1. Support baremetal container clusters (strigazi)
16:04:09 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:04:30 <hongbin> strigazi_AFK: you there?
16:05:03 <hongbin> It looks Spyros is not here. Skip this from today's agenda
16:05:10 <muralia> the ironic swarm driver got merged.
16:05:17 <muralia> looks like they need to work on others
16:05:33 <hongbin> muralia: good news
16:06:01 <hongbin> Thanks muralia
16:06:13 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:06:18 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:06:22 <hongbin> tonanhngo: ^^
16:06:39 <tonanhngo> I revised the Labels section from Qin, and it was merged
16:07:00 <tonanhngo> Next is the Scaling section
16:07:23 <tonanhngo> Steady progress, we should have the bulk of the user guide soon
16:07:38 <tonanhngo> that's all for now
16:07:48 <hongbin> Thanks tonanhngo
16:08:25 <hongbin> The guide looks more comprehensive now. Thanks Ton for the hard work
16:08:41 <hongbin> 3. COE Bay Drivers (jamie_h, muralia)
16:08:47 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:08:55 <hongbin> muralia: ^^
16:09:05 <muralia> I made some more progress. As discussed before, I've changed the bay-create call to take --driver
16:09:29 <muralia> and use that to seletct the driver instead of the earlier options os server_type, distro and coe
16:09:51 <muralia> however, i cant delete the other 3 inputs. they need to be deprecated
16:10:05 <muralia> so i need to work on supporting both for now
16:10:21 <muralia> working on that for now.
16:10:40 <muralia> thats all from me
16:10:53 <hongbin> muralia: could you elaborate the reason to change to --driver?
16:11:33 <muralia> so, right now baymodel has 3 values
16:11:39 <muralia> server_type, distro and coe
16:11:50 <hongbin> yes
16:11:58 <muralia> we use these 3 to select the right tempates
16:12:15 <muralia> we dont need all 3 now as inputs.
16:12:39 <muralia> because just be selecting the driver to use, we are choosing server_type, distro and coe
16:12:53 <muralia> so we can collapse these 3 into just one input --driver
16:12:58 <muralia> or --driver-name
16:13:12 <muralia> basically, we are just choosing the driver to be used
16:13:33 <hongbin> could we map the 3 values into a driver (if --driver is not sepcified)
16:14:05 <hongbin> That means there is 2 options to create a bay
16:14:08 <muralia> we could, and thats what i'll be doing to support those 3 for now, but eventually, we should remove them as inputs.
16:14:31 <hongbin> Yes, why remove them eventually?
16:14:49 <hongbin> From user perspective, I would like to specify the 3 values instead of a driver
16:15:14 <hongbin> It is a better user experience from my point of view
16:15:24 <muralia> what is the point though? when just selecting the driver by name is simpler
16:15:28 <hongbin> However, we could offer a optional --driver option
16:15:34 <Drago> For me, I would like to do magnum driver-list and see which drivers have what capabilities and specify one option
16:16:05 <tonanhngo> Do we have that yet?
16:16:16 <hongbin> Drago: yes, that is fine. I am arguing if we need to remove the 3 values
16:16:20 <muralia> not yet. it needs to be added
16:16:34 <jvgrant> if we support every combination of the 3 values then it might make sense to keep all 3, but if only some combination are valid then having the list and just select the driver seems more friendly
16:17:18 <muralia> ok, i'll need to support both anyway for now. we'll decide what to do later
16:17:27 <hongbin> ok
16:17:27 <Drago> Also, there may be cases where an operator wants multiple bay driver with the same combination of 3 values. Such as a minion/master hybrid node for dev clusters and separated nodes for production
16:17:28 <muralia> lets first get a feel for what the new experience is like
16:17:31 <tonanhngo> Yes, it might be less error prone to look up the matching driver
16:17:56 <tonanhngo> and just remember that instead of the combination of 3 values
16:18:14 <jvgrant> i agree with muralia we have to support both for now anyway, we can take it under consideration as we do the v2 api what works best
16:18:29 <hongbin> my concern is that users might find hard to understand each driver and have difficulties to select them
16:18:52 <hongbin> ok. then let's support both for now
16:18:58 <tonanhngo> Sounds good
16:19:01 <jvgrant> it would need to be shown to the user in a friendly way
16:19:01 <muralia> hongbin: makes sense. i'll keep that in for now. lets talk more
16:19:25 <hongbin> OK. Advance topic
16:19:31 <hongbin> 4. Rename bay to cluster (jvgrant)
16:19:37 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster
16:19:44 <hongbin> jvgrant: ^^
16:19:58 <jvgrant> The first major patch went in, so now api has been updated to support ClusterTemplate and Cluster
16:20:28 <jvgrant> Bay/BayModel are still supported, but all new feature work should be done on ClusterTemplate/Cluster
16:20:48 <jvgrant> so be aware of that with new changes and code reviews
16:21:12 <jvgrant> several more code review are out for more changes:
16:21:20 <jvgrant> https://review.openstack.org/#/c/354436/ - Client
16:21:30 <jvgrant> https://review.openstack.org/#/c/354404/ - Docs
16:21:37 <jvgrant> https://review.openstack.org/#/c/358777/ - Certs
16:21:43 <jvgrant> https://review.openstack.org/#/c/358831/ - API cleanup
16:22:08 <muralia> oh wow! lots of patches. cool.
16:22:08 <jvgrant> I've started working on the object and db changes and the first patch for the ClusterTemplate will be out soon
16:22:15 <tonanhngo> I guess new patches from everyone should now refer to the new terminology?
16:22:31 <jvgrant> tonanhngo: yes please
16:22:33 <swatson_> Client is basically done but I'll implement those nits once I'm done syncing here
16:23:17 <jvgrant> in my opinion, we should consider Bay and BayModel frozen now and only bug fixes go into those. Any changes or new features should go on cluster
16:23:38 <jvgrant> so we all get used to using the new terms and Bay/BayModel can be retired
16:23:49 <tonanhngo> hmm, but that would mean we have different behavior
16:24:21 <jvgrant> they are still backwards compatible
16:24:33 <muralia> yes, i would expect them to work the same. we are just renaming it
16:25:01 <hongbin> we might not be able to freeze the bay/baymodel
16:25:02 <tonanhngo> It's probably OK with new features, but bug fixes should probably go into both
16:25:19 <jvgrant> yes, bug fixes and anything key should go into both
16:25:22 <hongbin> because they are actually share the code in DB/objects
16:25:55 <hongbin> ok
16:25:55 <jvgrant> yeah, this is just about api
16:26:10 <jvgrant> underneath they will use the exact same code for object and db
16:26:11 <hongbin> jvgrant: However, most of the changes are not just api
16:26:36 <tonanhngo> It's more work, but it may be simplest to just maintain both for now until we remove bay/baymodel
16:26:46 <jvgrant> i guess freeze is a little strong, i guess i meant we should avoid having to duplicate too much between them
16:26:51 <jvgrant> but most things will remain the same
16:27:04 <jvgrant> agreed
16:27:09 <muralia> ah, makes sense
16:27:40 <jvgrant> everyone just needs to be aware during reviews to make sure if one is updated then the other api is as well
16:28:05 <tonanhngo> hopefully the unit tests would help to catch them
16:28:34 <jvgrant> tonanhngo: i have made sure to keep versions of both unit tests so that we check both ways on changes
16:28:43 <hongbin> It would be niceer if the API of bay/cluster are consolidate into one though
16:29:17 <jvgrant> yeah, i have a change for that, but it made the code pretty complicated. I haven't given up on it though
16:29:30 <jvgrant> it might be easier once i switch the object and db
16:29:41 <hongbin> ok
16:29:59 <jvgrant> good progress over all and thanks to swatson for help on client side
16:30:08 <jvgrant> that is all
16:30:19 <hongbin> Thanks jvgrant
16:30:36 <hongbin> Any other comment/question?
16:31:06 <hongbin> #topic Kuryr Integration Update (tango)
16:31:12 <hongbin> tonanhngo: ^^
16:31:37 <tonanhngo> The Kuryr team didn't have a meeting yesterday, looks like Taku from Japan was not available to run the meeting
16:32:06 <tonanhngo> There was a number of reviews on the current patches for refactoring
16:32:38 <tonanhngo> but the developer working on it apparently was out last week, so no new patches yet
16:33:16 <tonanhngo> I have 2 patches now, and I can bring up a Swarm cluster with Kuryr
16:33:26 <tonanhngo> Still validating and debugging
16:33:26 <hongbin> woo
16:33:46 <tonanhngo> What I am thinking is that we can go ahead with the current Kuryr driver
16:33:56 <tonanhngo> basically it's the Mitaka version
16:34:05 <hongbin> wfm
16:34:08 <tonanhngo> and have it working with our Swarm cluster
16:34:27 <tonanhngo> when we have the new driver, we can do some rework to fit it in
16:34:36 <muralia> sure
16:34:48 <tonanhngo> the functionality is the same, so it should be transparent to the user
16:35:08 <tonanhngo> That's all for now
16:35:31 <hongbin> Thanks tonanhngo
16:35:45 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:35:51 <hongbin> 1. How many fishbowl/workroom sessions you would like to request in Barcelona summit?
16:36:00 <hongbin> We had 5 fishbowl and 5 workroom at Austin summit, but I was told there will be less slots in Barcelona.
16:36:54 <tonanhngo> We will still have the Friday session right?
16:36:55 <hongbin> We need to decide how many fishbowl/workroom to request
16:37:11 <hongbin> tonanhngo: Friday session will have two session
16:37:22 <hongbin> tonanhngo: design summit at the morning, meetup at the afternoon
16:37:34 <tonanhngo> We can spill over to Friday afternoon if necessary
16:37:59 <hongbin> tonanhngo: what do you mean?
16:38:33 <tonanhngo> arrange our own sessions during the meetup
16:39:09 <tonanhngo> we can probably fit 3 topics in the afternoon
16:39:17 <hongbin> tonanhngo: The fishbowl/workrrom sessions will be from Wednesday to Friday morning
16:39:34 <hongbin> tonanhngo: At the Friday afternoon, there are all meetup session
16:40:15 <hongbin> tonanhngo: Yes, uncovered topics will be moved to the meetup session
16:41:13 <hongbin> All, how many fishbowl/workroom we would like to request?
16:41:22 <tonanhngo> So, would it be poor manner to request 5 + 5 as in Austin?
16:42:02 <hongbin> tonanhngo: I think 5+5 is fine, as long as they have enough slots
16:42:41 <hongbin> tonanhngo: possibly, the result will be 4+4 or 3+3 if the slots are not enough
16:42:49 <tonanhngo> In the worst case, they will just tell us what's available and we can go with that
16:43:06 <hongbin> Yes
16:44:01 <hongbin> If nobody has opinion, I will continue to request 5+5 on behalf of the team
16:44:45 <hongbin> silent ....
16:44:51 <Drago> +1+1
16:44:56 <jvgrant> +1 :)
16:44:58 <tonanhngo> +1
16:45:05 <hongbin> ok
16:45:23 <hongbin> That is all for the design summit session
16:45:29 <hongbin> Next one
16:45:31 <hongbin> 2. Decide the time for Magnum feature freeze
16:45:40 <hongbin> #link http://releases.openstack.org/newton/schedule.html Newton release scheduler
16:46:30 <hongbin> We needs to choose a date to freeze our repo
16:46:55 <hongbin> When we are on feature freeze, only bug fixes can go in
16:47:35 <hongbin> The freeze will last a few days, until I create a stable branch
16:47:51 <tonanhngo> Do we allow FFE?
16:48:02 <hongbin> Yes
16:48:33 <hongbin> I would be flexiable for the freezing date
16:48:44 <hongbin> However, here is the date of release
16:48:52 <muralia> looks like the newton release is oct
16:48:56 <hongbin> Aug 29-02 for CLI
16:49:29 <hongbin> Sep 12-16 for server
16:49:43 <hongbin> muralia: Yes, oct is the final release
16:51:17 <hieulq_> hongbin: why do magnum not have tag release:cycle-with-milestones?
16:52:17 <hongbin> hieulq_: I guess that is because nobody asked me to require this tag
16:52:32 <muralia> i think those dates should work. for the cli, looks like the bay to cluster work is what needs to get done. im adding --driver, but everything will be backwards compatible. i cant think of any other major work in progress. i think those dates should work. for the cli, looks like the bay to cluster work is what needs to get done. im adding --driver, but everything will be backwards compatible. i cant think of any other major work
16:52:32 <muralia> in progress.
16:52:42 <tonanhngo> So if we take 8/29 as the FF and pick the key features for FFE, is there any concern?
16:53:18 <tonanhngo> this would match other projects
16:54:12 <hongbin> OK
16:54:30 <hongbin> Aug 29-02 is the CLI release
16:54:44 <hongbin> If we freeze at that date, that is too late (I feel)
16:55:15 <hongbin> It is better to make it a week earlier, then I have more time to create the stable branch
16:55:29 <hongbin> but it is up to you
16:55:33 <tonanhngo> Sounds good
16:55:35 <jvgrant> freeze CLI on 26th?
16:55:49 <hongbin> jvgrant: yes. That could be done
16:56:10 <jvgrant> i think the cluster to bay is the only major feature that needs to get in before then
16:56:16 <jvgrant> and it is in review and close now
16:56:29 <swatson_> Hongbin +2'd it but I can put in the nit fixes if we want
16:56:35 <swatson_> I think the only thing after that is the cert thing
16:56:36 <tcammann> I'm very late, but would this bp still add value. I have a team member who might have some time available: https://blueprints.launchpad.net/magnum/+spec/add-hidden-flag-to-baymodel
16:57:35 <tcammann> If not could you suggest some a constrained piece that could be completed by someone new to Magnum that would be useful.
16:57:38 <hongbin> Let's prioritize for all the CLI patches for now
16:58:02 <muralia> tcammann: yes, this would be helpful
16:58:06 <hongbin> Then, the CLI will be freeze whenever you guys are ready
16:58:36 <hongbin> Any concern about the CLI freezing?
16:59:19 <hongbin> For the freeze of server, we can discuss it at the next team meeting
17:00:03 <hongbin> Time is up now. All, thanks for joining the meeting
17:00:07 <hongbin> #endmeeting