Re: [openstack-dev] [Zun] Change in Zun core team

[Shuu Mutou]

+1 for them, includes the new voting schema.

Best regards,
Shu


> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@gmail.com]
> Sent: Wednesday, November 22, 2017 8:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: miao.hong...@zte.com.cn
> Subject: [openstack-dev] [Zun] Change in Zun core team
> 
> Hi all,
> 
> I would like to announce the following change to the Zun core reviewers
> team.
> 
> + miaohb (miao-hongbao)
> - Sheel Rana (ranasheel2000)
> 
> Miaohb has been consistently contributed to Zun for a few months. So far,
> he has 60 commits in Zun, which ranked on top 3 in the commit metric. I
> think his hard work justified his qualification as a core reviewer in Zun.
> 
> This change was approved unanimously by the existing core team. Below are
> the core team members who supported this change:
> 
> Hongbin Lu
> Shunli Zhou
> Kien Nguyen
> Kevin Zhao
> Madhuri Kumari
> Namrata Sitlani
> Shubham Sharma
> 
> Best regards,
> Hongbin
> 
> [1] http://stackalytics.com/?metric=commits=zun-group
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Propose change of the core team

[Shuu Mutou]

+1 for both.

Thanks,
Shu

> -Original Message-
> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
> Sent: Monday, September 18, 2017 1:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose change of the core team
> 
> +1 for both. Thanks Kien for all your work in Zun, especially multi-node
> CI.
> 
> 
> 
> Regards,
> 
> Madhuri
> 
> 
> 
> From: Pradeep Singh [mailto:ps4openst...@gmail.com]
> Sent: Sunday, September 17, 2017 8:35 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose change of the core team
> 
> 
> 
> +1 for both
> 
> 
> 
> On Sun, Sep 17, 2017 at 4:26 AM, Kevin Zhao   > wrote:
> 
>   +1 on both
> 
> 
> 
>   On 15 September 2017 at 08:40, Qiming Teng
>  > wrote:
> 
>   +1 on both.
> 
> 
>   On Thu, Sep 14, 2017 at 01:58:48PM +, Hongbin Lu wrote:
>   > Hi all,
>   >
>   > I propose the following change of the Zun core reviewer
> team.
>   >
>   > + Kien Nguyen (kiennt2609)
>   > - Aditi Sharma (adi-sky17)
>   >
>   > Kien has been contributing to the Zun project for a few
> months. His contributions include proposing high-quality codes, providing
> helpful code reviews, participating team discussion at weekly team meeting
> and IRC, etc. He is the one who setup the multi-node job in the CI and the
> job is up and running now. I think his contribution is significant which
> qualifies him to be a core reviewer. Aditi is a member of the initial core
> team but becomes inactive for a while.
>   >
>   > Core reviewers, please cast your vote on this proposal.
>   >
>   > Best regards,
>   > Hongbin
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django version cap

[Shuu Mutou]

Hi Rob,

Thanks for the notification! I confirmed that following plugins work fine with 
Django 1.10.7.

* Magnum UI
* Senlin Dashboard
* Zaqar UI
* Zun UI


Also, I tried to use Django 1.11.3, but Horizon doesn't run. If plugin seems to 
need to fix anything, please notice us again.

Shu


> -Original Message-
> From: Rob Cresswell (rcresswe) [mailto:rcres...@cisco.com]
> Sent: Wednesday, July 05, 2017 7:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django
> version cap
> 
> If you want to install Django 1.11 and test it, that would be very helpful,
> even if its just to open bugs. I’m in the process of adding a non-voting
> job for 1.11 right now, so we should be able to move quickly.
> 
> Rob
> 
> 
>   On 5 Jul 2017, at 01:36, Adrian Turjak   > wrote:
> 
>   Great work!
> 
>   Is there anything that can be done to help meet that July deadline
> and get 1.11.x in? I'm more than happy to help with reviews or even fixes
> for newer Django in Horizon, and we should try and get others involved if
> it will help as I think this is a little urgent.
> 
>   Running anything less than Django 1.11 leaves us in a weird spot
> because of the point where support ends for any versions below it.
> 
>   Looking at the release timelines, if we don't get 1.11 in for Pike,
> we'll have released a version of Horizon that will be for an unsupported
> version of Django in about 6 months time (8 if deployers stick with django
> 1.8):
>   https://releases.openstack.org/pike/schedule.html
>   https://www.djangoproject.com/download/
> 
>   It isn't as bad it could be, but it's an awkward situation to be
> in. 1.9 is no longer supported, 1.10 support stops at 2018, so realistically
> 1.8 is the only version to have Pike 'safe' until Queens thats not
> particularly great either. Getting 1.11 support in would be ideal.
> 
> 
> 
>   On 05/07/17 03:01, Rob Cresswell wrote:
> 
> 
>   Hi everyone,
> 
>   I've put up a patch to global-requirements to raise the
> Django cap to "<1.11", with the upper-constraint at "1.10.7"
> (https://review.openstack.org/#/c/480215). Depending on the remaining
> time, I'd quite like to move us to "1.11.x" before Requirements Freeze,
> which will fall around the 27th of July.
> 
>   Rob
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe: openstack-dev-requ...@lists.openstack.org
>  ?subject:unsubscribe
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Propose addition of Zun core team and removal notice

[Shuu Mutou]

+1 to all from me.

Welcome Shunli! And greate thanks to Dims and Yanyan!!.

Best regards,
Shu

> -Original Message-
> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
> Sent: Wednesday, June 21, 2017 12:30 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose addition of Zun core team and
> removal notice
> 
> +1 from me as well.
> 
> 
> 
> Thanks Dims and Yanyan for you contribution to Zun :)
> 
> 
> 
> Regards,
> 
> Madhuri
> 
> 
> 
> From: Kevin Zhao [mailto:kevin.z...@linaro.org]
> Sent: Wednesday, June 21, 2017 6:37 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose addition of Zun core team and
> removal notice
> 
> 
> 
> +1 for me.
> 
> Thx!
> 
> 
> 
> On 20 June 2017 at 13:50, Pradeep Singh   > wrote:
> 
>   +1 from me,
> 
>   Thanks Shunli for your great work :)
> 
> 
> 
>   On Tue, Jun 20, 2017 at 10:02 AM, Hongbin Lu   > wrote:
> 
>   Hi all,
> 
> 
> 
>   I would like to propose the following change to the Zun
> core team:
> 
> 
> 
>   + Shunli Zhou (shunliz)
> 
> 
> 
>   Shunli has been contributing to Zun for a while and did
> a lot of work. He has completed the BP for supporting resource claim and
> be closed to finish the filter scheduler BP. He showed a good understanding
> of the Zun’s code base and expertise on other OpenStack projects. The
> quantity [1] and quality of his submitted code also shows his qualification.
> Therefore, I think he will be a good addition to the core team.
> 
> 
> 
>   In addition, I have a removal notice. Davanum Srinivas
> (Dims) and Yanyan Hu requested to be removed from the core team. Dims had
> been helping us since the inception of the project. I treated him as mentor
> and his guidance is always helpful for the whole team. As the project becomes
> mature and stable, I agree with him that it is time to relieve him from
> the core reviewer responsibility because he has many other important
> responsibilities for the OpenStack community. Yanyan’s leaving is because
> he has been relocated and focused on an out-of-OpenStack area. I would like
> to take this chance to thank Dims and Yanyan for their contribution to Zun.
> 
> 
> 
>   Core reviewers, please cast your vote on this proposal.
> 
> 
> 
>   Best regards,
> 
>   Hongbin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Propose a change of the Zun core team membership

[Shuu Mutou]

+1 for both.

regards
Shu


> -Original Message-
> From: Pradeep Singh [mailto:ps4openst...@gmail.com]
> Sent: Tuesday, January 24, 2017 11:58 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose a change of the Zun core team
> membership
> 
> +1, welcome Kevin. I appreciate your work.
> 
> On Tuesday, January 24, 2017, Yanyan Hu   > wrote:
> 
> 
>   ＋1 for the change.
> 
> 
>   2017-01-24 6:56 GMT+08:00 Hongbin Lu   >:
> 
> 
>   Hi Zun cores,
> 
> 
> 
>   I proposed a change of Zun core team membership as below:
> 
> 
> 
>   + Kevin Zhao (kevin-zhao)
> 
>   - Haiwei Xu (xu-haiwei)
> 
> 
> 
>   Kevin has been working for Zun for a while, and made
> significant contribution. He submitted several non-trivial patches with
> high quality. One of his challenging task is adding support of container
> interactive mode, and it looks he is capable to handle this challenging
> task (his patches are under reviews now). I think he is a good addition
> to the core team. Haiwei is a member of the initial core team. Unfortunately,
> his activity dropped down in the past a few months.
> 
> 
> 
>   According to the OpenStack Governance process [1], we
> require a minimum of 4 +1 votes from Zun core reviewers within a 1 week
> voting window (consider this proposal as a +1 vote from me). A vote of -1
> is a veto. If we cannot get enough votes or there is a veto vote prior to
> the end of the voting window, this proposal is rejected.
> 
> 
> 
>   [1]
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> 
> 
> 
>   Best regards,
> 
>   Hongbin
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage
> questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev 
> 
> 
> 
> 
> 
> 
>   --
> 
>   Best regards,
> 
>   Yanyan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Propose a change of Zun core membership

[Shuu Mutou]

+1 for both.

Thanks,
Shu

> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, December 01, 2016 8:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [Zun] Propose a change of Zun core membership
> 
> Hi Zun cores,
> 
> 
> 
> I am going to propose the following change of the Zun core reviewers team:
> 
> + Pradeep Kumar Singh (pradeep-singh-u)
> 
> - Vivek Jain (vivek-jain-openstack)
> 
> 
> 
> Pradeep was proven to be a significant contributor to Zun. He ranked first
> at the number of commits, and his patches were non-trivial and with high
> quality. His reviews were also very helpful, and often prompted us to
> re-think the design. It would be great to have him in the core team. I would
> like to thank Vivek for his interest to join the core team when Zun was
> found. However, he became inactive in the past a few months, but he is
> welcomed to re-join the core team as long as he becomes active again.
> 
> 
> 
> According to the OpenStack Governance process [1], we require a minimum
> of 4 +1 votes from Zun core reviewers within a 1 week voting window (consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected.
> 
> 
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> 
> 
> 
> Best regards,
> 
> Hongbin


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum-ui][horizon] use json-schema-form on workflow

[Shuu Mutou]

Thanks Rob. Pretty good! We have confirmed 'tabs' type is same look and feel as 
previous Workflow Service.


> -Original Message-
> From: Rob Cresswell [mailto:robert.cressw...@outlook.com]
> Sent: Friday, November 25, 2016 5:39 PM
> To: OpenStack Dev Mailer <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum-ui][horizon] use json-schema-form on
> workflow
> 
> From a quick scan, it looks like you're using it several times in the same
> workflow? Why not just use the existing tabs type and create a single form?
> Have a look at https://review.openstack.org/#/c/348969/
> <https://review.openstack.org/#/c/348969/> for reference.
> 
> 
> Rob
> 
> On 25 Nov 2016 08:28, "Shuu Mutou" <shu-mu...@rf.jp.nec.com
> <mailto:shu-mu...@rf.jp.nec.com> > wrote:
> 
> 
>   Hi Thai,
> 
>   We're trying to use json-schema-form in workflow, but 'required'
> attribute doesn't work. So we can push 'create' button without input. Could
> you check following patch?
> 
>   https://review.openstack.org/#/c/400701/
> <https://review.openstack.org/#/c/400701/>
> 
>   best regards,
>   Shu Muto
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum-ui][horizon] use json-schema-form on workflow

[Shuu Mutou]

Hi Thai,

We're trying to use json-schema-form in workflow, but 'required' attribute 
doesn't work. So we can push 'create' button without input. Could you check 
following patch?

https://review.openstack.org/#/c/400701/

best regards, 
Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] ui-cookiecutter

[Shuu Mutou]

Hi Thai,

I created new blueprint[1], and added the BP to next IRC meeting agenda[2]. I 
hope the topic will be discussed in the meeting.

[1]https://blueprints.launchpad.net/horizon/+spec/ui-cookiecutter
[2]https://wiki.openstack.org/wiki/Meetings/Horizon

Best regards,
Shu Muto


> -Original Message-
> From: Thai Q Tran [mailto:tqt...@us.ibm.com]
> Sent: Tuesday, November 15, 2016 4:30 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] ui-cookiecutter
> 
> Hi Shuu,
> 
> Sorry for the delay again, I just got back from vacation. I think your
> cookiecutter will be useful in a number of ways.
> 
> 1. We can use it to easily generate plugins for beginners
> 2. We can use it in Horizon's startdash command (have to look into this)
> for internal use
> 
> Ideally, the project should be under an OpenStack repo so horizon drivers
> can maintain it. Lets make it a point and bring it up at the horizon weekly
> meeting. We can proceed after community feedback.
> 
> 
>   - Original message -
>   From: Shuu Mutou <shu-mu...@rf.jp.nec.com>
>   To: "openstack-dev@lists.openstack.org"
> <openstack-dev@lists.openstack.org>
>   Cc: Haruhiko Katou <har-ka...@ts.jp.nec.com>
>   Subject: [openstack-dev] [Horizon] ui-cookiecutter
>   Date: Tue, Nov 8, 2016 1:24 AM
> 
>   Hi Horizoners,
> 
>   Thanks for picking up ui-cookiecutter[1] and setting Ocata-2
> milestone at summit[2].
>   Thai or Cindy? Thank you!!
> 
>   I'm maintaining ui-cookiecutter, but I'm ready for transferring
> it as Horizon subproject.
> 
>   Can I start to create subproject for ui-cookiecutter?
>   Or please let me know what I should do.
> 
>   [1] https://github.com/shu-mutou/ui-cookiecutter
>   [2] https://etherpad.openstack.org/p/horizon-ocata-priorities
> 
>   Regards,
> 
>   Shu Muto
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] ui-cookiecutter

[Shuu Mutou]

Hi Horizoners,

Thanks for picking up ui-cookiecutter[1] and setting Ocata-2 milestone at 
summit[2].
Thai or Cindy? Thank you!!

I'm maintaining ui-cookiecutter, but I'm ready for transferring it as Horizon 
subproject.

Can I start to create subproject for ui-cookiecutter?
Or please let me know what I should do.

[1] https://github.com/shu-mutou/ui-cookiecutter
[2] https://etherpad.openstack.org/p/horizon-ocata-priorities

Regards,

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Propose a change of Zun core team

[Shuu Mutou]

+1 for both.

Regards,
Shu Muto

> -Original Message-
> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
> Sent: Thursday, October 20, 2016 12:33 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose a change of Zun core team
> 
> +1 for both. Shubham will be a great addition to team.
> 
> 
> 
> Thanks!
> 
> 
> 
> Madhuri
> 
> 
> 
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, October 20, 2016 2:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [Zun] Propose a change of Zun core team
> 
> 
> 
> Hi team,
> 
> 
> 
> I am going to propose an exchange of the core team membership as below:
> 
> 
> 
> + Shubham Kumar Sharma (shubham)
> 
> - Chandan Kumar (chandankumar)
> 
> 
> 
> Shubham contributed a lot for the container image feature and active on
> reviews and IRC. I think he is a good addition to the core team. Chandan
> became inactive for a long period of time so he didn’t meet the expectation
> of a core reviewer anymore. However, thanks for his interest to join the
> core team when the team was found. He is welcomed to re-join the core team
> if he become active in the future.
> 
> 
> 
> According to the OpenStack Governance process [1], we require a minimum
> of 4 +1 votes from Zun core reviewers within a 1 week voting window (consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected and Shubham is not able to join the core
> team and needs to wait 30 days to reapply.
> 
> 
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> 
> 
> 
> Best regards,
> 
> Hongbin


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Release schedule of magnumclient

[Shuu Mutou]

Hi Hongbin,

Also, Magnum-UI will meet "Soft StringFreeze" next week.

If the following BP [1] can reach to release in this cycle, 
I will implement it into Magnum-UI until next week.

How do you think about the release timing of the BP?

[1] https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster


Thanks,
Shu


> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Wednesday, August 24, 2016 6:32 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Magnum] Release schedule of magnumclient
> 
> Hi team,
> 
> 
> 
> As discussed at the team meeting, Aug 29-02 (next week) is the final release
> for client libraries [1]. We are going to freeze the python-magnumclient
> repo for preparing the client release. If you have *client* patches for
> newton release, please submit it by the end of this week.
> 
> 
> 
> According to the schedule, the feature freeze is next week as well but I
> am OK to be flexible about that. However, we needs to deliver the first
> release candidate no later than the RC1 target week (Sep 12-16) so please
> try to submit all your *server* patches before the RC1 target week, or let
> me know if you need more time.
> 
> 
> 
> [1] https://releases.openstack.org/newton/schedule.html
> 
> 
> 
> 
> Best regards,
> 
> Hongbin


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Magnum] about word "baymodel"

[Shuu Mutou]

Hi folks, 

I recognize that "baymodel" or "Baymodel" is correct, and "bay model" or 
"BayModel" is not correct. 

Magnum-UI implemented using former since Rob's last patch. Before the 
implementation, Rob seemed to ask on IRC.

What is truth?

And please check https://review.openstack.org/#/c/355804/


Thanks, 
Shu


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [Magnum] Using common tooling for API docs

[Shuu Mutou]

>   AFAIK, the API WG adopted Swagger (OpenAPI) as common tool for API
> docs.
>   Anne, has not the adoption been changed? Otherwise, do we need to
> maintain much RST files also?
> 
> 
> 
> It does say either/or in the API WG guideline:
> http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html

Yes. Also Ken'ichi Omichi said.


> This isn't about a contest between projects for the best approach. This
> is about serving end-users the best information we can.

Yes. Correct information is the best information. The Accuracy is more 
important than web experience. When I was a user (and SIer), the document 
accuracy had not been kept. So we had to read source code at last. And now, as 
a developer (mainly UI plugins), I don't want maintain overlapped content 
several times (API source code, API reference, helps in client, helps in WebUI, 
etc). So I spend efforts to the spec auto-generation.


> I'm reporting what I'm seeing from a broader viewpoint than a single project.
> I don't have a solution other than RST/YAML for common navigation, and I'm
> asking you to provide ideas for that integration point.
> 
> My vision is that even if you choose to publish with OpenAPI, you would
> find a way to make this web experience better. We can do better than this
> scattered approach. I'm asking you to find a way to unify and consider the
> web experience of a consumer of OpenStack services. Can you generate HTML
> that can plug into the openstackdocstheme we are providing as a common tool?

I need to know about the "common tools". Please, let me know what is difference 
between HTMLs built by Lars's patch and by common tools? Or can fairy-slipper 
do that from OpenAPI file?


Thanks,
Shu


> -Original Message-
> From: Anne Gentle [mailto:annegen...@justwriteclick.com]
> Sent: Wednesday, August 17, 2016 11:55 AM
> To: Mutou Shuu(武藤 周) <shu-mu...@rf.jp.nec.com>
> Cc: openstack-dev@lists.openstack.org; m...@redhat.com; Katou Haruhiko(加
> 藤 治彦) <har-ka...@ts.jp.nec.com>; openstack-d...@lists.openstack.org;
> kenichi.omi...@necam.com
> Subject: Re: [OpenStack-docs] [openstack-dev] [Magnum] Using common
> tooling for API docs
> 
> 
> 
> On Tue, Aug 16, 2016 at 1:05 AM, Shuu Mutou <shu-mu...@rf.jp.nec.com
> <mailto:shu-mu...@rf.jp.nec.com> > wrote:
> 
> 
>   Hi Anne,
> 
>   AFAIK, the API WG adopted Swagger (OpenAPI) as common tool for API
> docs.
>   Anne, has not the adoption been changed? Otherwise, do we need to
> maintain much RST files also?
> 
> 
> 
> It does say either/or in the API WG guideline:
> http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
> 
> 
> 
>   IMO, for that the reference and the source code doesn't have
> conflict, these should be near each other as possible as follow. And it
> decreases maintainance costs for documents, and increases document
> reliability. So I believe our approach is more ideal.
> 
> 
> 
> 
> This isn't about a contest between projects for the best approach. This
> is about serving end-users the best information we can.
> 
> 
>   The Best: the references generated from source code.
> 
> 
> 
> I don't want to argue, but anything generated from the source code suffers
> if the source code changes in a way that reviewers don't catch as a
> backwards-incompatible change you can break your contract.
> 
> 
>   Better: the references written in docstring.
> 
>   We know some projects abandoned these approach, and then they uses
> RST + YAML.
>   But we hope decreasing maintainance cost for the documents. So we
> should not create so much RST files, I think.
> 
> 
> 
> 
> I think you'll see the evolution of our discussions over the years has
> brought us to this point in time. Yes, there are trade-offs in these
> decisions.
> 
> 
> 
>   I'm proceeding auto-generation of swagger spec from magnum source
> code using pecan-swagger [1], and improving pecan-swagger with Michael
> McCune [2].
>   These will generate almost Magnum API specs automatically in
> OpenAPI format.
>   Also, these approach can be adopted by other APIs that uses pecan
> and WSME.
>   Please check this also.
> 
> 
> 
> I ask you to consider the experience of someone consuming the API documents
> OpenStack provides. There are 26 REST API services under an OpenStack
> umbrella. Twelve of them will be included in an unified side-bar navigation
> on developer.openstack.org <http://developer.openstack.org>  due to
> using Sphinx tooling provided as a common web experience. Six of them don't
> have redirects yet from the "old way" to do API reference docs. Seven of
> t

Re: [openstack-dev] [OpenStack-docs] [Magnum] Using common tooling for API docs

[Shuu Mutou]

Hi Anne,

AFAIK, the API WG adopted Swagger (OpenAPI) as common tool for API docs.
Anne, has not the adoption been changed? Otherwise, do we need to maintain much 
RST files also?

IMO, for that the reference and the source code doesn't have conflict, these 
should be near each other as possible as follow. And it decreases maintainance 
costs for documents, and increases document reliability. So I believe our 
approach is more ideal.

The Best: the references generated from source code.
Better: the references written in docstring.

We know some projects abandoned these approach, and then they uses RST + YAML. 
But we hope decreasing maintainance cost for the documents. So we should not 
create so much RST files, I think.


I'm proceeding auto-generation of swagger spec from magnum source code using 
pecan-swagger [1], and improving pecan-swagger with Michael McCune [2].
These will generate almost Magnum API specs automatically in OpenAPI format.
Also, these approach can be adopted by other APIs that uses pecan and WSME.
Please check this also.

[1] https://review.openstack.org/#/c/303235/
[2] https://github.com/elmiko/pecan-swagger/

Regards,
Shu


> -Original Message-
> From: Anne Gentle [mailto:annegen...@justwriteclick.com]
> Sent: Monday, August 15, 2016 11:00 AM
> To: Hongbin Lu 
> Cc: openstack-dev@lists.openstack.org; enstack.org
> 
> Subject: Re: [openstack-dev] [OpenStack-docs] [Magnum] Using common
> tooling for API docs
> 
> Hi Hongbin,
> 
> Thanks for asking. I'd like for teams to look for ways to innovate and
> integrate with the navigation as a good entry point for OpenAPI to become
> a standard for OpenStack to use. That said, we have to move forward and
> make progress.
> 
> Is Lars or anyone on the Magnum team interested in the web development work
> to integrate with the sidebar? See the work at
> https://review.openstack.org/#/c/329508 and my comments on
> https://review.openstack.org/#/c/351800/ saying that I would like teams
> to integrate first to provide the best web experience for people consuming
> the docs.
> 
> Anne
> 
> On Fri, Aug 12, 2016 at 4:43 PM, Hongbin Lu   > wrote:
> 
> 
>   Hi team,
> 
> 
> 
>   As mentioned in the email below, Magnum are not using common tooling
> for generating API docs, so we are excluded from the common navigation of
> OpenStack API. I think we need to prioritize the work to fix it. BTW, I
> notice there is a WIP patch [1] for generating API docs by using Swagger.
> However, I am not sure if Swagger belongs to “common tooling” (docs team,
> please confirm).
> 
> 
> 
>   [1] https://review.openstack.org/#/c/317368/
> 
> 
> 
> 
>   Best regards,
> 
>   Hongbin
> 
> 
> 
>   From: Anne Gentle [mailto:annegen...@justwriteclick.com
>  ]
>   Sent: August-10-16 3:50 PM
>   To: OpenStack Development Mailing List;
> openstack-d...@lists.openstack.org
> 
>   Subject: [openstack-dev] [api] [doc] API status report
> 
> 
> 
>   Hi all,
> 
>   I wanted to report on status and answer any questions you all have
> about the API reference and guide publishing process.
> 
> 
> 
>   The expectation is that we provide all OpenStack API information
> on developer.openstack.org  . In order to
> meet that goal, it's simplest for now to have all projects use the
> RST+YAML+openstackdocstheme+os-api-ref extension tooling so that users
> see available OpenStack APIs in a sidebar navigation drop-down list.
> 
> 
> 
>   --Migration--
> 
>   The current status for migration is that all WADL content is
> migrated except for trove. There is a patch in progress and I'm in contact
> with the team to assist in any way.
> https://review.openstack.org/#/c/316381/
> 
> 
> 
> 
>   --Theme, extension, release requirements--
> 
>   The current status for the theme, navigation, and Sphinx extension
> tooling is contained in the latest post from Graham proposing a solution
> for the release number switchover and offers to help teams as needed:
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101112.
> html
>  .html>  I hope to meet the requirements deadline to get those changes landed.
> Requirements freeze is Aug 29.
> 
> 
> 
>   --Project coverage--
> 
>   The current status for project coverage is that these projects are
> now using the RST+YAML in-tree workflow and tools and publishing to
> http://developer.openstack.org/api-ref/
>   so they will be
> included in the upcoming API navigation sidebar intended to span all
> OpenStack APIs:
> 
> 
> 
>   designate 

[openstack-dev] [Horizon] ui-cookiecutter

[Shuu Mutou]

Hi everyone,

I have uploaded cookiecutter for dashboard plugin [1]. I'm happy if it will be 
your help, for creation of new plugin.

[1]: https://github.com/shu-mutou/ui-cookiecutter

The happiest case is that I donate this and the cookiecutter is maintained in 
Horizon, and the cookiecutter is used for plugin creation for functional test 
against plugin. Otherwise, should I talk with openstack-dev? Let me know your 
thoughts, please.

This cookiecutter is based on Magnum-UI (including a patch on reviewing), and 
Horizon on master branch (2016, 19th July). So the UI created from the 
cookiecutter doesn't have update function, but it has create/delete functions, 
uses registry service, default table and detail views.

Thanks,

Shu Muto

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition, and removal notice

[Shuu Mutou]

Hi peers,

Welcome Thai!!

I have closed this vote window, five days since the proposal posted onto ML, 
according to following guide.
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

This proposal have been approved from majority of the active Core Developers 
without rejection votes.

Also, I have freed Adrian from independent Magnum-UI core role according to 
agreement from him, because his role as Magnum-UI core is included with role as 
Magnum core.

Thanks, 
Shu

> -Original Message-
> From: Ton Ngo [mailto:t...@us.ibm.com]
> Sent: Tuesday, June 14, 2016 3:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Cc: Katou Haruhiko(加藤 治彦) <har-ka...@ts.jp.nec.com>
> Subject: Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition,
> and removal notice
> 
> +1
> 
> Ton Ngo,
> 
> Shuu Mutou ---06/10/2016 02:41:02 AM---Hi team, I propose the following
> changes to the magnum-ui core group.
> 
> From: Shuu Mutou <shu-mu...@rf.jp.nec.com>
> To: "openstack-dev@lists.openstack.org"
> <openstack-dev@lists.openstack.org>
> Cc: Haruhiko Katou <har-ka...@ts.jp.nec.com>
> Date: 06/10/2016 02:41 AM
> Subject: [openstack-dev] [magnum-ui][magnum] Proposed Core addition, and
> removal notice
> 
> 
> 
> 
> 
> 
> Hi team,
> 
> I propose the following changes to the magnum-ui core group.
> 
> + Thai Tran
>  http://stackalytics.com/report/contribution/magnum-ui/90
>  I'm so happy to propose Thai as a core reviewer.
>  His reviews have been extremely valuable for us.
>  And he is active Horizon core member.
>  I believe his help will lead us to the correct future.
> 
> - David Lyle
> 
> http://stackalytics.com/?metric=marks_type=openstack=a
> ll=magnum-ui_id=david-lyle
>  No activities for Magnum-UI since Mitaka cycle.
> 
> - Harsh Shah
>  http://stackalytics.com/report/users/hshah
>  No activities for OpenStack in this year.
> 
> - Ritesh
>  http://stackalytics.com/report/users/rsritesh
>  No activities for OpenStack in this year.
> 
> Please respond with your +1 votes to approve this change or -1 votes to
> oppose.
> 
> Thanks,
> Shu
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum-ui][magnum] Proposed Core addition, and removal notice

[Shuu Mutou]

Hi team,

I propose the following changes to the magnum-ui core group.

+ Thai Tran
  http://stackalytics.com/report/contribution/magnum-ui/90
  I'm so happy to propose Thai as a core reviewer.
  His reviews have been extremely valuable for us. 
  And he is active Horizon core member.
  I believe his help will lead us to the correct future.

- David Lyle
  
http://stackalytics.com/?metric=marks_type=openstack=all=magnum-ui_id=david-lyle
  No activities for Magnum-UI since Mitaka cycle.

- Harsh Shah
  http://stackalytics.com/report/users/hshah
  No activities for OpenStack in this year.

- Ritesh
  http://stackalytics.com/report/users/rsritesh
  No activities for OpenStack in this year.

Please respond with your +1 votes to approve this change or -1 votes to oppose.

Thanks,
Shu


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [zaqar][zaqar-ui] Nomating Shu Muto for Zaqar-UI core

[Shuu Mutou]

Hi team,

Thank you for nominating to Zaqar-UI core and voting to me.
I'm looking forward to working with you guys more.

Yours,
Shu


> -Original Message-
> From: Fei Long Wang [mailto:feil...@catalyst.net.nz]
> Sent: Wednesday, June 08, 2016 7:15 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [zaqar][zaqar-ui] Nomating Shu Muto for
> Zaqar-UI core
> 
> +1 and thanks for all the great work.
> 
> 
> On 08/06/16 08:27, Thai Q Tran wrote:
> 
> 
>   Hello all,
> 
>   I am pleased to nominate Shu Muto to the Zaqar-UI core team. Shu's
> reviews are extremely thorough and his work exemplary. His expertise in
> angularJS, translation, and project infrastructure proved to be invaluable.
> His support and reviews has helped the project progressed. Combine with
> his strong understanding of the project, I believe his will help guide us
> in the right direction and allow us to keep our current pace.
> 
>   Please vote +1 or -1 to the nomination.
> 
>   Thanks,
>   Thai (tqtran)
> 
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
> dev
> 
> 
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> 
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz 
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [zaqar][zaqar-ui][i18n] Translation enabled

[Shuu Mutou]

Hi everyone, 

Now, we can translate Zaqar-UI on Zanata, please translate Zaqar-UI into your 
native language!!
Translation is another good review for Zaqar-UI, so I hope your help.

See also https://wiki.openstack.org/wiki/I18nTeam


Best regards, 

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [higgins] Should we rename "Higgins"?

[Shuu Mutou]

I found container related names and checked whether other project uses.

https://en.wikipedia.org/wiki/Straddle_carrier
https://en.wikipedia.org/wiki/Suezmax
https://en.wikipedia.org/wiki/Twistlock

These words are not used by other project on PYPI and Launchpad.

ex.)
https://pypi.python.org/pypi/straddle
https://launchpad.net/straddle


However the chance of renaming in N cycle will be done by Infra-team on this 
Friday, we would not meet the deadline. So

1. use 'Higgins' ('python-higgins' for package name)
2. consider other name for next renaming chance (after a half year)

Thoughts?


Regards,
Shu


> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Wednesday, June 01, 2016 11:37 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [higgins] Should we rename "Higgins"?
> 
> Shu,
> 
> According to the feedback from the last team meeting, Gatling doesn't seem
> to be a suitable name. Are you able to find an alternative name?
> 
> Best regards,
> Hongbin
> 
> > -Original Message-
> > From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com]
> > Sent: May-24-16 4:30 AM
> > To: openstack-dev@lists.openstack.org
> > Cc: Haruhiko Katou
> > Subject: [openstack-dev] [higgins] Should we rename "Higgins"?
> >
> > Hi all,
> >
> > Unfortunately "higgins" is used by media server project on Launchpad
> > and CI software on PYPI. Now, we use "python-higgins" for our project
> > on Launchpad.
> >
> > IMO, we should rename project to prevent increasing points to patch.
> >
> > How about "Gatling"? It's only association from Magnum. It's not used
> > on both Launchpad and PYPI.
> > Is there any idea?
> >
> > Renaming opportunity will come (it seems only twice in a year) on
> > Friday, June 3rd. Few projects will rename on this date.
> > http://markmail.org/thread/ia3o3vz7mzmjxmcx
> >
> > And if project name issue will be fixed, I'd like to propose UI
> > subproject.
> >
> > Thanks,
> > Shu
> >
> >
> >
> __
> _
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [higgins] Should we rename "Higgins"?

[Shuu Mutou]

Hi all,

Unfortunately "higgins" is used by media server project on Launchpad and CI 
software on PYPI. Now, we use "python-higgins" for our project on Launchpad.

IMO, we should rename project to prevent increasing points to patch.

How about "Gatling"? It's only association from Magnum. It's not used on both 
Launchpad and PYPI.
Is there any idea?

Renaming opportunity will come (it seems only twice in a year) on Friday, June 
3rd. Few projects will rename on this date.
http://markmail.org/thread/ia3o3vz7mzmjxmcx

And if project name issue will be fixed, I'd like to propose UI subproject.

Thanks,
Shu


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] How to document 'labels'

[Shuu Mutou]

Hongbin, 

Actually docs from API-WG is seen in below.
[1] http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
[2] http://docs.openstack.org/contributor-guide/api-guides.html

But since present patches (below) seem to be as PoC or WIP, so we need more 
time to investigate to use Swagger and related tools.

[3] https://bugs.launchpad.net/magnum/+bug/1460161
[4] https://review.openstack.org/#/c/233446/ POC: generate swagger spec from 
api code base
[5] https://review.openstack.org/#/c/286659/ [WIP] Added bootprint and 
bootprint-swagger to project


I agree with you about doing this work as PoC now.

At last, I think to use Swagger only for API documentation and providing fixed 
values, not for generating code.

Regards, 

Shu

> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@gmail.com]
> Sent: Saturday, May 14, 2016 4:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum] How to document 'labels'
> 
> Shu,
> 
> You mentioned that Swagger was promoted by the API-WG. I wonder if they
> mention how to use it. For example, use it to generate the API document,
> generate an API client stub, or generate the CLI?
> 
> In general, I see Swagger could solve the problem, but it does incur a
> significant amount of work. We need to either i) modify the magnum client/ui
> to understand the Swagger API spec (the JSON file) or ii) switch to
> Swagger-generated client/ui modules. I think Swagger could be a long-term
> approach and it needs a POC to show how it works. In short-term, I would
> suggest to choose option #1 or #3, or a combination of both.
> 
> Best regards,
> Hongbin
> 
> On Fri, May 13, 2016 at 8:41 AM, Shuu Mutou <shu-mu...@rf.jp.nec.com
> <mailto:shu-mu...@rf.jp.nec.com> > wrote:
> 
> 
>   Hi peers,
> 
>   Since Magnum-UI should display selectable values for user, so
> Magnum-UI wants to get available values from API.
>   https://blueprints.launchpad.net/magnum/+spec/magnum-api-swagg
> er-support
>   https://bugs.launchpad.net/magnum-ui/+bug/1568890
> 
>   And we don't want to write same things in many files, sometimes
> with nits.
>   ex.) write help messages and available key/values into API, CLI,
> UI and docs
> 
>   My understanding for Swagger (=OpenAPI) and related tools are:
>   - generate swagger-spec JSON file (like YAML file proposed by Ton)
> from source code (with decorator), means writing documents as source code
> of API (#2)
>   - provide the JSON file via REST API (#2) to CLI (#1) and UI for
> available values and help messages not inconsistent with the source code.
>   - generate online documents from the JSON file (#3)
>   - are promoted by API-WG
>   - implementations seems starting to be tried in Nova and Zaqar
> 
>   I'd like to re-propose to use Swagger.
>   But it needs more investigation, so I'm not sure where is a middle
> ground for now.
> 
> 
>   Best regards,
> 
>   Shu Muto
> 
>   > -Original Message-
>   > From: Ton Ngo [mailto:t...@us.ibm.com <mailto:t...@us.ibm.com> ]
>   > Sent: Friday, May 13, 2016 5:33 AM
>   > To: OpenStack Development Mailing List (not for usage questions)
>   > <openstack-dev@lists.openstack.org
> <mailto:openstack-dev@lists.openstack.org> >
>   > Cc: Qun XK Wang <bjw...@cn.ibm.com <mailto:bjw...@cn.ibm.com>
> >
>   > Subject: Re: [openstack-dev] [magnum] How to document 'labels'
>   >
>   > I would like to add some context for a bigger picture so we might
> arrive
>   > at a more general solution.
>   > Typically CLI options are fairly static so the help messages are
> usually
>   > coded directly in the client.
>   > This provides a good user experience by making the info readily
> available
>   > to the users.
>   > The case for label is a little different, because label provides
> a general
>   > mechanism to pass arbitrary key/value pairs.
>   > The meaning for these key/value is interpreted based on a
> particular option
>   > in a particular COE type, so they are not generally applicable.
>   > For instance, Kubernetes baymodel that uses flannel as
> network-driver
>   > supports the label "flannel_backend", with the allowed values
> of "udp, vxlan,
>   > host-gw".
>   > This particular label would be meaningless in another COE like
> Mesos.
>   >
>   > So to provide this kind of info to the users, we have to address
> 2 issues:
>   

Re: [openstack-dev] [magnum] How to document 'labels'

[Shuu Mutou]

Hi peers,

Since Magnum-UI should display selectable values for user, so Magnum-UI wants 
to get available values from API.
https://blueprints.launchpad.net/magnum/+spec/magnum-api-swagger-support
https://bugs.launchpad.net/magnum-ui/+bug/1568890

And we don't want to write same things in many files, sometimes with nits.
ex.) write help messages and available key/values into API, CLI, UI and docs

My understanding for Swagger (=OpenAPI) and related tools are:
- generate swagger-spec JSON file (like YAML file proposed by Ton) from source 
code (with decorator), means writing documents as source code of API (#2)
- provide the JSON file via REST API (#2) to CLI (#1) and UI for available 
values and help messages not inconsistent with the source code.
- generate online documents from the JSON file (#3)
- are promoted by API-WG
- implementations seems starting to be tried in Nova and Zaqar

I'd like to re-propose to use Swagger.
But it needs more investigation, so I'm not sure where is a middle ground for 
now.


Best regards, 

Shu Muto

> -Original Message-
> From: Ton Ngo [mailto:t...@us.ibm.com]
> Sent: Friday, May 13, 2016 5:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Qun XK Wang 
> Subject: Re: [openstack-dev] [magnum] How to document 'labels'
> 
> I would like to add some context for a bigger picture so we might arrive
> at a more general solution.
> Typically CLI options are fairly static so the help messages are usually
> coded directly in the client.
> This provides a good user experience by making the info readily available
> to the users.
> The case for label is a little different, because label provides a general
> mechanism to pass arbitrary key/value pairs.
> The meaning for these key/value is interpreted based on a particular option
> in a particular COE type, so they are not generally applicable.
> For instance, Kubernetes baymodel that uses flannel as network-driver
> supports the label "flannel_backend", with the allowed values of "udp, vxlan,
> host-gw".
> This particular label would be meaningless in another COE like Mesos.
> 
> So to provide this kind of info to the users, we have to address 2 issues:
> 
> 1.How the user can discover the available labels specific to the COE,
> along with the valid values to specify.
> 2.How to maintain the help messages specific to each label since they
> are likely to change frequently.
> 
> 
> I think just displaying the info for all labels together would not be too
> helpful.
> Putting the info in the API would make it available to tools built on Magnum,
> but Madhuri has a good point that the info would not be available when the
> server is not running.
> We need to accommodate new bay drivers that may add new labels.
> Validation for the label value is another requirement.
> 
> Here is a thought on how to meet these requirements: we can install a yaml
> file in /etc/magnum/labels.yaml that would describe all the supported
> labels, something like:
> 
> flannel_backend:
> valid_values:
> -udp
> -vxlan
> -host-gw
> default_value: udp
> COE:
> -kubernetes
> -swarm
> help_message: "This label is used with the flannel network driver to specify
> the type of back end to use. The option host-gw gives the best bandwidth
> performance."
> doc_url: "http://xxx;
> 
> Then the client can read this yaml file and list the labels for a COE, say
> Kubernetes. For help on a specific label, the client would print the help
> message along with the url for further info (if available)
> The validation code can also load this file for a more general way to validate
> the baymodel, avoiding hardcoding in api/attr_validator.py
> New bay drivers can just append new labels to this file to have them handled
> in the same way as Magnum supported labels.
> Optionally, the API server can provide access to this info.
> In the source, we can keep this file in etc/magnum/labels.yaml.
> Maintaining the help messages would be simpler since we just need to edit
> the file.
> 
> Thought?
> 
> Ton,
> 
> 
> Jamie Hannaford ---05/12/2016 07:08:47 AM---+1 for 1 and 3. I'm not sure
> maintainability should discourage us from exposing information to the u
> 
> From: Jamie Hannaford 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc: Qun XK Wang 
> Date: 05/12/2016 07:08 AM
> Subject: Re: [openstack-dev] [magnum] How to document 'labels'
> 
> 
> 
> 
> 
> 
> +1 for 1 and 3.
> 
> I'm not sure maintainability should discourage us from exposing information
> to the user through the client - we'll face the same maintenance burden
> as we currently do, and IMO it's our job as a team to ensure our docs are
> up-to-date. Any kind of input which touches the API should also live in
> the API docs, because that's in line with every other OpenStack service.

Re: [openstack-dev] [magnum] How to document 'labels'

[Shuu Mutou]

Hi all, 

+1 for option #2.

Yuanying drafted following blueprint. And I will follow up this.
https://blueprints.launchpad.net/magnum/+spec/magnum-api-swagger-support

I think, this will be satisfy Tom's comments.

regards, 

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [containers][horizon][magnum-ui] - Stable version for Liberty?

[Shuu Mutou]

Hi Marcos and Adrian,

Since Magnum-UI has a lot of new angularized feature in master branch, next 
release of Magnum-UI is not suitable for backporting to stable/liberty.


Adrian,

Could you cut the release as 1.0.0rc2, for freeze strings, at following git 
hash?

c3494b3fce6d46de5a761f77ec1b01a2f2abf5ab

https://github.com/openstack/magnum-ui/commit/a6e326d72d957d7f64c5297fb1869d7b0bb05b3a


Best regards,

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

[Shuu Mutou]

Hi Akihiro,

Thank you for your announcement.
We will create stable/mitaka branch for Magnum-UI in this week,
and that will freeze strings.

Thanks, 

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum-ui] Reorganization of Magnum-UI Driver

[Shuu Mutou]

Hi Bradley Jones, 

I propose reorganization of "Magnum-UI Drivers" on Launchpad for Magnum-UI.
The team can contain magnum core members and magnum-ui core members.
Also review the following patch, please.
https://review.openstack.org/#/c/289584/
So I suggest cutting the mitaka release until existing patches and following 
fix by Rob Cresswell.
https://bugs.launchpad.net/magnum-ui/+bug/1554527

Thanks, 

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice

[Shuu Mutou]

Hi peers, 

Thank you for the appointment to core!!
I'm honored to working with my peers.
I'll do my best as core and i18n liaison.

Since I received previous mail after going home, 
I'm sorry for absence in last meeting.

Best regards, 

Shu Muto


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice

[Shuu Mutou]

Hi team, 

Thank you very much for vote to me.
I'm looking forward to work more with our peers.
However, when is the end of this vote?

Shu Muto

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FW: [magnum][magnum-ui] Liaisons for I18n

[Shuu Mutou]

Hi Hongbin, Yuanying and team,

Thank you for your recommendation.
I'm keeping 100% of EN to JP translation of Magnum-UI everyday.
I'll do my best, if I become a liaison.

Since translation has became another point of review for Magnum-UI, I hope that 
members translate Magnum-UI into your native language.

Best regards,
Shu Muto

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n][stackalytics] Translations metrics

[Shuu Mutou]

Hi Ilya, 

Thank you for uploading patch to add my profile.
I confirmed it. I'm looking forward to be adopted into "Stackalytics".

Best regards, 
Shu Muto
NEC Solution Innovators, Ltd.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [i18n][stackalytics] Translations metrics

[Shuu Mutou]

Hi, 

Stackalytics shows my translations as other ones.
Does the difference between Zanata ID and Launchpad ID cause the problem?

* My Zanata ID "shu" is used by "Seihu" in Launchpad.
* My Launchpad ID is "shu-mutou".

If so, I hope that email address will be used for matching user.

Shu Muto
NEC Solution Innovators, Ltd.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev