16:00:04 <hongbin> #startmeeting containers
16:00:05 <openstack> Meeting started Tue May 17 16:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <openstack> The meeting name has been set to 'containers'
16:00:11 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-05-17_1600_UTC Today's agenda
16:00:17 <hongbin> #topic Roll Call
16:00:18 <adrian_otto> Adrian Otto
16:00:19 <strigazi> Spyros Trigazis
16:00:20 <muralia> o/
16:00:20 <mkrai> Madhuri Kumari
16:00:23 <wangqun> o/
16:00:26 <Kennan> o/
16:00:26 <tango> Ton Ngo
16:00:28 <tcammann_> sup!
16:00:29 <Drago> o/
16:00:29 <spn_> o/
16:00:34 <juggler> o/
16:01:20 <hongbin> Thanks for joining the meeting adrian_otto strigazi muralia mkrai wangqun Kennan tango tcammann_ Drago spn_ juggler
16:01:39 <hongbin> #topic Announcements
16:01:44 <hongbin> Spyros Trigazis become our documentation Liaison
16:01:50 <hongbin> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation
16:02:00 <hongbin> strigazi: Thanks for taking this responsibility
16:02:10 <strigazi> my pleasure
16:02:16 <Kennan> Good work
16:02:19 <mkrai> Thanks strigazi
16:02:20 <tango> +1
16:02:26 <hongbin> #topic Review Action Items
16:02:26 <wangqun> +1
16:02:40 <hongbin> Sorry I should ask
16:02:52 <hongbin> Any other announcement from other team members?
16:02:53 <spn> o/
16:03:04 <dane_leblanc_> o/
16:03:27 <hongbin> OK. Advance topic
16:03:30 <hongbin> 1. hongbin start a ML to discuss the CLI help text documentation (DONE)
16:03:38 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094729.html
16:03:50 <hongbin> There are several response in the ML
16:04:00 <hongbin> We have a session to revisit it
16:04:02 <hongbin> later
16:04:10 <hongbin> #topic Essential Blueprints Review
16:04:17 <hongbin> 1. Support baremetal container clusters (strigazi)
16:04:23 <hongbin> strigazi: status?
16:04:32 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:05:19 <strigazi> I was investigating the integration with devstack and managed to just depoly ironic with devstack. This is the fitst thing we need to do
16:05:39 <hongbin> strigazi: ack
16:05:52 <hongbin> strigazi: Any road blockers?
16:05:59 <strigazi> Along with fixing the heat templates? We can assing those two tasks
16:06:12 <spn> strigazi: I will  ping you offline. I would like to setup up a similar one. I have devstack ready
16:06:38 <tango> Would it be useful to add some tips in the quickstart on how to deploy ironic in devstack?
16:06:45 <tango> for others to try out
16:06:51 <spn> +1
16:07:02 <hongbin> Yes, need a documentation for the Ironic devstack setup
16:07:09 <strigazi> i just followed the manual, just a sec
16:07:12 <hongbin> which can be done in a separated person
16:07:17 <strigazi> (on ubuntu)
16:07:32 <strigazi> http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html
16:07:50 <hongbin> #link http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html
16:08:13 <hongbin> Thanks strigazi
16:08:15 <wangqun> +1
16:08:22 <hongbin> Any question for this BP?
16:08:43 <adrian_otto> the docs are a prerequisite?
16:08:54 <adrian_otto> or the docs are depending on this work?
16:09:08 <adrian_otto> I am unable to conclude the direction of the dependency illustrated on the BP
16:09:45 <hongbin> I think it depends on contributors to define the dependencies of tasks
16:10:40 <hongbin> Any other question?
16:11:09 <hongbin> strigazi: Feel free to distribute sub-tasks to others if it can be done
16:11:24 <strigazi> ack
16:11:25 <hongbin> Then we can do the BPs in parallel
16:11:28 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:11:35 <adrian_otto> then there shold be no dependency defined
16:11:35 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:11:50 <tango> I added a section on storage, covering ephemeral and persistent storage
16:12:09 <tango> incorporated Qun's doc on volume drivers
16:12:14 <adrian_otto> nice.
16:12:16 <wangqun> Good work
16:12:17 <tango> patch under review
16:12:22 <hongbin> #link https://review.openstack.org/#/c/317592/
16:12:36 <hongbin> Thanks tango
16:12:41 <tango> Next I will work on bay drivers, while it's still fresh in my mind
16:13:06 <hongbin> tango: ack
16:13:17 <tango> I will write as I understand from the spec, so this will flush out any misunderstanding or assumption
16:13:31 <Kennan> +1 to know that
16:13:44 <tango> it will be WIP for awhile, as we proceed with the implementation
16:14:04 <tango> that's all for now
16:14:10 <hongbin> Thanks tango
16:14:17 <hongbin> Any question for tango ?
16:14:37 <hongbin> 3. COE Bay Drivers (Jamie Hannaford)
16:14:43 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:14:58 <hongbin> It looks Jamie is not here
16:15:19 <strigazi> I think we should close the versioning issue
16:15:32 <muralia> Jamie isint here today, but the spec looks good. i had one question today about tracking minor versions. strigazi seems to have a solution for it.
16:15:34 <hongbin> muralia: Are you able to give a update on behalf of Jamie?
16:16:06 <hongbin> #link https://review.openstack.org/#/c/296384/
16:16:12 <muralia> most comments have been addressed. everyone, please do take a look again if you get a chance.
16:16:12 <hongbin> muralia: Thx
16:16:51 <hongbin> Yes, it looks the spec is close to merge
16:17:11 <hongbin> Any question about this BP?
16:17:31 <muralia> I was planning to work on the implementation too. tango if you are too, we can collaborate. this is a big chunk of work.
16:18:11 <tango> I will certainly collaborate
16:18:22 <hongbin> tango: Thanks Ton
16:18:52 <hongbin> Any further comment?
16:19:10 <hongbin> 4. Create a magnum installation guide (strigazi)
16:19:21 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide
16:19:41 <hongbin> strigazi: I saw you uploaded a patch for that?
16:19:48 <strigazi> I worked on the template that the doc team created. I would like to seperate the task
16:20:12 <strigazi> One is to have install instructions under /doc
16:20:41 <strigazi> and publish on owr wiki from source and for centos which are tested by me
16:20:52 <strigazi> and one to create content under /install-guide
16:21:07 <strigazi> to publish on docs.openstack
16:21:29 <strigazi> This will get us to a result this week I think
16:21:40 <adrian_otto> would we consolidate them later?
16:21:46 <hongbin> strigazi: Thanks. It sounds like a good progress
16:21:48 <strigazi> yes
16:21:57 <adrian_otto> I see, sounds okay from my perspective
16:22:14 <strigazi> The doc team have plans
16:22:24 <strigazi> for the next release
16:22:30 <strigazi> we need something faster
16:22:49 <adrian_otto> faster in what way?
16:22:58 <adrian_otto> you mean we need it sooner?
16:23:31 <strigazi> yes, pass the review process sooner and without restrictions from the template etc
16:24:33 <strigazi> So, I'll push a different change under magnum/doc
16:24:52 <strigazi> and work in parallel for the content under magnum/install-guide
16:24:58 <strigazi> what do you think?
16:25:01 <hongbin> strigazi: Thanks. It sounds like we should prioritize the reviews for your patch?
16:26:03 <adrian_otto> I can definitely help it get reviewed, and run through to verify the instructions do work
16:26:21 <hongbin> adrian_otto: thanks
16:26:22 <strigazi> mostly test it to verify that it works
16:26:46 <wangqun> I will also help to test it.
16:26:50 <strigazi> thanks
16:27:00 <tango> I tried it out on Mitaka and have some problem with Keystone authentication
16:27:16 <strigazi> with debconf on ubuntu?
16:27:23 <tango> Ubuntu
16:27:39 <tango> I will follow up with you
16:27:42 <hongbin> Yes, let flush the comments in the reviews of the patch
16:27:46 <strigazi> ok
16:28:35 <strigazi> that's all from me
16:31:08 <hongbin_> sorry folks
16:31:13 <hongbin_> THe internet is dead
16:31:38 <hongbin_> everyone still here?
16:31:43 <wangqun> yes
16:31:43 <strigazi> here
16:31:46 <mkrai> Yes
16:31:46 <adrian_otto> o/
16:31:48 <Kennan> 0/
16:31:50 <hongbin_> :)
16:31:51 <muralia> yes
16:31:57 <juggler> o/
16:32:08 <hongbin_> We talked about the magnum-ui before
16:32:28 <hongbin_> And there is a patch in the magnum-ui side
16:32:31 <hongbin_> #link https://review.openstack.org/#/c/315436/
16:32:39 <hongbin_> I guess that is it
16:32:51 <hongbin_> #topic Other blueprints/Bugs/Reviews/Ideas
16:33:02 <hongbin_> 1. Add labels help text in magnumclient
16:33:07 <hongbin_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094729.html
16:33:33 <hongbin_> For recap, we discussed how to document 'labels' in CLI
16:33:40 <hongbin_> There are three options presented
16:33:49 <hongbin_> 1. Place the documentation in Magnum CLI as help text (as Wangqun proposed [1][2]).
16:33:56 <hongbin_> 2. Place the documentation in Magnum server and expose them via the REST API. Then, have the CLI to load help text of individual properties from Magnum server.
16:34:02 <hongbin_> 3. Place the documentation in a documentation server (like developer.openstack.org/...), and add the doc link to the CLI help text.
16:34:41 <adrian_otto> 1 and 3 should not be mutually exclusive.
16:35:00 <hongbin_> Yes, I think so as well
16:35:03 <Kennan> 1 + 3 seems easy and ok enough
16:35:10 <adrian_otto> CLI help text should be in the CLI, not the API.
16:35:28 <adrian_otto> and there should be somewhere to turn for additional detail (web based)
16:35:42 <hongbin_> Yes
16:35:44 <adrian_otto> so 1+3 seems best to me
16:36:08 <Kennan> adrian_otto: do you mean to expose to UI from rest api for web base ?
16:36:19 <Kennan> I mean help text
16:36:42 <adrian_otto> the API does not need to provide the help text. It can be kept in the client.
16:36:58 <adrian_otto> we may end up with different clients that use the API
16:37:10 <Kennan> Yes, I think so, web related not need to get from rest API point for help text
16:37:16 <adrian_otto> so if you ahve an operator using an alternate client, having different help text in the API would be really confusing
16:37:31 <wangqun> +1
16:37:43 <mkrai> Good point adrian_otto
16:38:00 <hongbin_> Looks like #1 + #3 is the popular option
16:38:05 <hongbin_> Any opposing point of view?
16:38:08 <adrian_otto> for example, we might have osc and python-magnumclient both using our API
16:38:15 <adrian_otto> and they have different usage
16:38:22 <tango> Does this address Tom's concern?
16:38:35 <tango> (for the -2 on Qun's patch)
16:38:48 <hongbin_> tango: He changed it to -1
16:39:06 <Kennan> 1+3 is ok for me
16:39:13 <hongbin_> tcammann_: are you ok with #1 + #3?
16:39:48 <hongbin_> seems he is not here
16:40:11 <hongbin_> In general, it looks most of us agree a combination of #1 and #3
16:40:22 <mkrai> Yeah +1 for it
16:40:43 <hongbin_> So, I would suggest to proceed in this way unless there is further disagreement
16:40:50 <hongbin_> wangqun: sounds good to you?
16:41:02 <wangqun> yes, It's good.
16:41:12 <hongbin_> wangqun: Thanks
16:41:17 <wangqun> I will finish it.
16:41:33 <hongbin_> 2. Manually manage bay nodes
16:41:36 <adrian_otto> I suggest proposing the solution on the ML, seeking final opposing POV
16:41:48 <hongbin_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095044.html ML discussion
16:42:39 <hongbin_> adrian_otto: you are talking to the "labels" or the "management of bay nodes"?
16:43:41 <hongbin_> For the manually management of bay nodes, it looks most of us agreed on the direction in the ML
16:43:52 <hongbin_> There are some discussion about the style
16:43:55 <mkrai> He is talking about labels hongbin_
16:44:01 <adrian_otto> ?
16:44:44 <adrian_otto> I responded fro sdake's question about client behaviour, and offered a few points of reference that we could model management after.
16:45:05 <adrian_otto> the question was about consistency with other openstack clients.
16:45:20 <hongbin_> OK. I responsed to the ML as well
16:45:41 <hongbin_> Let's put the link here
16:46:16 <hongbin_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095172.html
16:46:42 <hongbin_> In summary, there are three style proposed
16:46:55 <hongbin_> 1. magnum node-add [--flavor <flavor-id>] <bay>
16:47:01 <hongbin_> 2. openstack bay node add [--flavor <flavor-id>]
16:47:06 <hongbin_> 3. magnum bay node add [--flavor <flavor-id>]
16:47:17 <hongbin_> It looks adrian_otto proposed #3
16:47:23 <tango> Question:  will the Magnum python client always exist in parallel to the OSC?  or will all the project clients be merged into OSC eventually?
16:47:23 <hongbin_> adrian_otto: correct?
16:47:49 <hongbin_> tango: I think they will co-exist for a while, then switch to OSC finally
16:47:50 <adrian_otto> the python language bindings enable OSC
16:48:09 <adrian_otto> the various CLI tools are there for legacy compatibility
16:48:29 <adrian_otto> I suggest that we try to confirm with the OSC style now so we don't have a future divergence.
16:48:35 <Kennan> osc is final direction
16:48:57 <hongbin_> Yes, we will move to OSC eventually
16:49:12 <adrian_otto> s/confirm/conform/
16:49:17 <hongbin_> However, I don't like a mix of two styles (python-*client + OSC)
16:49:22 <tango> I just wonder whether it's worth making all current command in Magnum consistent to OSC, instead of a mix
16:49:28 <adrian_otto> +1
16:49:36 <strigazi> +1
16:49:59 <tango> a little pain at the beginning for existing user (mostly us developers)
16:50:26 <adrian_otto> the API can stay the same, the CLI changes.
16:50:31 <tango> right
16:50:32 <adrian_otto> so we have some docs to tweak
16:50:42 <adrian_otto> but don't need to refactor much code.
16:50:48 <hongbin_> I disgree to change the CLI in magnumclient
16:50:59 <hongbin_> If it has to change, it should go to the OSC repo
16:51:16 <adrian_otto> why?
16:51:17 <hongbin_> I don't see value to do such signficant chance
16:51:34 <hongbin_> As I said, I don't like mix of sytle
16:51:44 <Kennan> maybe follow other projects style is good reference
16:51:52 <Kennan> like keystone nova etc.
16:52:02 <wangqun> +1 Kennan
16:52:08 <hongbin_> Here is what other project did
16:52:32 <hongbin_> stay with current style in *client
16:52:38 <hongbin_> but print a deprecate warning
16:52:41 <Kennan> still want to point that, own main focus is to make life cyle function to work, interface styles should not big block for us
16:53:33 <hongbin_> OK, push the discussion to the ML
16:53:56 <hongbin_> #topic Open Discussion
16:54:42 <hongbin_> adrian_otto: I don't think why we need to change our CLI, given the fact that we are going to remove it eventually
16:54:58 <hongbin_> adrian_otto: If you want the new style, just implement it in OSC
16:55:04 <mkrai> +1 hongbin_
16:55:09 <hongbin_> adrian_otto: Which is more intuitive
16:56:28 <muralia> the move to OSC is taking years. I've been hearing this for atleast 2 years. until then, we'll have 2 different styles.
16:57:04 <hongbin_> muralia: I think that is fine. We can print a warning in our CLI to ask users to switch to OSC
16:57:15 <hongbin_> muralia: which is all the other projects are doing
16:57:33 <mkrai> Both CLIs are independent, so I don't think we should take this pain of changing the whole magnum commands
16:57:40 <Kennan> adrian_otto: hongbin_ better ways is consistentce with other core projects if code not much
16:57:48 <Kennan> what do you think ?
16:58:01 <hongbin_> Kennan: agree
16:58:41 <adrian_otto> we have an opportunity to limit user confusion.
16:59:11 <adrian_otto> seems a shame to miss that opportunity.
16:59:16 <hongbin_> OK. TIme is up
16:59:23 <hongbin_> All. thanks for joining hte meeting
16:59:32 <hongbin_> The next meeting is next week at the same time
16:59:36 <hongbin_> #endmeeting
16:59:41 <Kennan> adrian_otto: maybe throw your points in ML
16:59:52 <hongbin_> Oh, I cannot end the meeting
17:00:46 <hongbin> #endmeeting