Re: [openstack-dev] [Zun] Add Deepak Mourya to the core team

[Kumari, Madhuri]

Welcome to the team, Deepak!

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Monday, May 14, 2018 10:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
; deepak.mou...@nectechnologies.in
Subject: [openstack-dev] [Zun] Add Deepak Mourya to the core team

Hi all,

This is an announcement of the following change on the Zun core reviewers team:

+ Deepak Mourya (mourya007)

Deepak has been actively involving in Zun for several months. He has submitted 
several code patches to Zun, all of which are useful features or bug fixes. In 
particular, I would like to highlight that he has implemented the availability 
zone API which is a significant contribution to the Zun feature set. Based on 
his significant contribution, I would like to propose him to become a core 
reviewer of Zun.

This proposal has been voted within the existing core team and is unanimously 
approved. Welcome to the core team Deepak.

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] [Zun] Announce change of Zun core reviewer team

[Kumari, Madhuri]

Welcome to the team, Ji Wei ☺

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Thursday, May 3, 2018 2:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun] Announce change of Zun core reviewer team

Hi all,

I would like to announce the following change on the Zun core reviewers team:

+ Ji Wei

Ji Wei has been working on Zun for a while. His contributions include 
blueprints, bug fixes, code reviews, etc. In particular, I would like to 
highlight that he has implemented two blueprints [1][2], both of which are not 
easy to implement. Based on his high-quality work in the past, I believe he 
will serve the core reviewer role very well.

This proposal had been voted within the existing core team and was unanimously 
approved. Welcome to the core team Ji Wei.

[1] https://blueprints.launchpad.net/zun/+spec/glance-support-tag
[2] https://blueprints.launchpad.net/zun/+spec/zun-rebuild-on-local-node

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] [Zun][k8s] AWS Fargate and OpenStack Zun

[Kumari, Madhuri]

Thank you Hongbin. The article is very helpful.

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Sunday, April 29, 2018 5:16 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun][k8s] AWS Fargate and OpenStack Zun

Hi folks,

FYI. I wrote a blog post about a comparison between AWS Fargate and OpenStack 
Zun. It mainly covers the following:

* The basic concepts of OpenStack Zun and AWS Fargate
* The Kubernetes integration plan

Here is the link: 
https://www.linkedin.com/pulse/aws-fargate-openstack-zun-comparing-serverless-container-hongbin-lu/

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] [Nova][Ironic][API] Service Management API Design

[Kumari, Madhuri]

Hi Nova Developers,

I am working on adding a service management API in Ironic [1][2]. This spec 
adds a new API /conductors to list, enable/disable an ironic-conductor service.
I am struggling to understand the difference between shutting down a service 
manually and disabling it.

So my question is what happens to the VMs and the current operation(if any) 
going on with the nova-compute service we disable? What is the difference 
between shutting down the service and disabling it?
I understand both the actions, disables scheduling request to the compute 
service and the workloads are taken over by other nova-compute service.

Please help me understand the design in Nova.

[1] https://review.openstack.org/#/c/471217/
[2] https://bugs.launchpad.net/ironic/+bug/1526759


Regards,
Madhuri

__
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] PTL on vacation for 3 weeks

[Kumari, Madhuri]

Hello,

@Hongbin, Enjoy your vacation!

Team, please feel free to reach me at mkrai on #openstack-zun. I am happy to 
serve as Zun’s temporary PTL.

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Friday, December 8, 2017 10:00 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Kumari, Madhuri <madhuri.kum...@intel.com>
Subject: [Zun] PTL on vacation for 3 weeks

Hi team,

I will be on vacation during Dec 11 - Jan 2. Madhuri Kumari (cc-ed) kindly 
agreed to serve the PTL role while I am away. Wish everyone have a happy 
holiday.

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] [Zun] Nova docker replaced by zun?

[Kumari, Madhuri]

Hi,

nova-docker was discontinued because the lifecycle of containers and VMs are 
different and the Nova APIs doesn't satisfy it.
Zun is an independent project of Nova which has its own set of APIs for 
managing containers on top of OpenStack.

For more information, you can read the FAQ section of Zun wiki page [1].

[1] https://wiki.openstack.org/wiki/Zun

Regards,
Madhuri


From: ADAMS, STEVEN E [mailto:sa2...@att.com]
Sent: Friday, September 29, 2017 8:18 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Nova docker replaced by zun?

Can anyone point me to some background on why nova docker was discontinued and 
how zun is the heir?
Thx,
Steve Adams
AT
https://github.com/openstack/nova-docker/blob/master/README.rst

__
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

[Kumari, Madhuri]

+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] [zun] sandbox and clearcontainers

[Kumari, Madhuri]

Hi Surya,

Please see my response inline.
Currently Zun have two drivers for managing containers: Docker and NovaDocker. 
Sandbox was initially implemented for the NovaDocker driver which we are going 
to deprecate soon.
Also we are working on making the sandbox optional for the Docker driver. See 
patch [1] for the code.

[1] https://review.openstack.org/#/c/471634/

Regards,
Madhuri


From: surya.prabha...@dell.com [mailto:surya.prabha...@dell.com]
Sent: Wednesday, July 12, 2017 4:44 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [zun] sandbox and clearcontainers

Dell - Internal Use - Confidential
Hi Folks,
I am just trying to wrap my head around zun's sandboxing and clear 
containers.   From what Hongbin told in Barcelona ( see the attached pic which 
I scrapped from his video)

[cid:image003.jpg@01D2FAF8.E8A6E1D0]

current implementation in Zun is, Sandbox is the outer container and the real 
user container is nested inside the sandbox.  I am trying to figure out how 
this is going to play out
when we have clear containers.
[Kumari, Madhuri] The sandbox container is just an infra container that manage 
IaaS resources associated with a container or a group of containers. Real 
container is only using the resources attached with the infra container not 
running inside infra container, so no other virtualization layer is involved 
here.

I envision the following scenarios:


1)  Scenario 1: where the sandbox itself is a clear container and user will 
nest another clear container inside the sandbox. This is like nested 
virtualization.

But I am not sure how this is going to work since the nested containers won't 
get VT-D cpu flags.

2)  Scenario 2: the outer sandbox is just going to be a standard docker 
container without vt-d and the inside container is going to be the real clear 
container with vt-d.  Now this

might work well but we might be losing the isolation features for the network 
and storage which lies open in the sandbox. Wont this defeat the whole purpose 
of using clear containers.

[Kumari, Madhuri] I have tried to run infra container as docker container and 
the real container as a Clear Container and it seems to work well. But I agree 
with your point that we might lose the advantage of using clear container.

So after the sandbox is made optional, we can run a clear container directly 
without any sandbox. Thus solving the issue.



I am just wondering what is the thought process for this design inside zun.  If 
this is trivial and if I am missing something please shed some light :).

Thanks
Surya ( spn )
__
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

[Kumari, Madhuri]

+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

[openstack-dev] [Openstack-operators][all][Ironic][Nova] The /service API endpoint

[Kumari, Madhuri]

Hi All,

I am working on a bug [1] in Ironic which talks exposing the state of conductor 
service running in OpenStack environment.
There are two ways to do this:

1) create a new API endpoint e.g. 'v1/service' that can report which conductor 
is managing given node. Additionally it can also report aliveness of all Ironic 
conductors and on which hosts they are running (similar to nova service-list)

2) expose conductor_affinity in node-show (but resolve it to hostname first).

Option #2 is probably quicker to implement, but option #1 has more benefits for 
operators.

So I would like to know from the OpenStack operators and project teams who has 
this API:

1. What are the other use-case of this API?
2. Which option is better to implement? Is it worth adding a new API endpoint 
for the purpose?
2. Also why this API only expose the state of RPC servers and not the API 
server in the environment?

[1] https://bugs.launchpad.net/ironic/+bug/1616878

Regards,
Madhuri
__
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] Proposal a change of Zun core team

[Kumari, Madhuri]

+1 for both.
Well deserved Feng!

Thanks,
Madhuri

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Saturday, April 29, 2017 9:35 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun] Proposal a change of Zun core team

Hi all,

I proposes a change of Zun's core team memberships as below:

+ Feng Shengqin (feng-shengqin)
- Wang Feilong (flwang)

Feng Shengqin has contributed a lot to the Zun projects. Her contribution 
includes BPs, bug fixes, and reviews. In particular, she completed an essential 
BP and had a lot of accepted commits in Zun's repositories. I think she is 
qualified for the core reviewer position. I would like to thank Wang Feilong 
for his interest to join the team when the project was found. I believe we are 
always friends regardless of his core membership.

By convention, 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.

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][osc] What name to use for magnum commands in osc?

[Kumari, Madhuri]

It seems the term COE is a valid term now. I am in favor of having “openstack 
coe cluster” or “openstack container cluster”.
Using the command “infra” is too generic and doesn’t relate to what Magnum is 
doing exactly.

Regards,
Madhuri

From: Spyros Trigazis [mailto:strig...@gmail.com]
Sent: Tuesday, March 21, 2017 7:25 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum commands 
in osc?

IMO, coe is a little confusing. It is a term used by people related somehow
to the magnum community. When I describe to users how to use magnum,
I spent a few moments explaining what we call coe.

I prefer one of the following:
* openstack magnum cluster create|delete|...
* openstack mcluster create|delete|...
* both the above

It is very intuitive for users because, they will be using an openstack cloud
and they will be wanting to use the magnum service. So, it only make sense
to type openstack magnum cluster or mcluster which is shorter.


On 21 March 2017 at 02:24, Qiming Teng 
> wrote:
On Mon, Mar 20, 2017 at 03:35:18PM -0400, Jay Pipes wrote:
> On 03/20/2017 03:08 PM, Adrian Otto wrote:
> >Team,
> >
> >Stephen Watson has been working on an magnum feature to add magnum commands 
> >to the openstack client by implementing a plugin:
> >
> >https://review.openstack.org/#/q/status:open+project:openstack/python-magnumclient+osc
> >
> >In review of this work, a question has resurfaced, as to what the client 
> >command name should be for magnum related commands. Naturally, we’d like to 
> >have the name “cluster” but that word is already in use by Senlin.
>
> Unfortunately, the Senlin API uses a whole bunch of generic terms as
> top-level REST resources, including "cluster", "event", "action",
> "profile", "policy", and "node". :( I've warned before that use of
> these generic terms in OpenStack APIs without a central group
> responsible for curating the API would lead to problems like this.
> This is why, IMHO, we need the API working group to be ultimately
> responsible for preventing this type of thing from happening.
> Otherwise, there ends up being a whole bunch of duplication and same
> terms being used for entirely different things.
>

Well, I believe the name and namespaces used by Senlin is very clean.
Please see the following outputs. All commands are contained in the
cluster namespace to avoid any conflicts with any other projects.

On the other hand, is there any document stating that Magnum is about
providing clustering service? Why Magnum cares so much about the top
level noun if it is not its business?

From magnum's wiki page [1]:
"Magnum uses Heat to orchestrate an OS image which contains Docker
and Kubernetes and runs that image in either virtual machines or bare
metal in a cluster configuration."

Many services may offer clusters indirectly. Clusters is NOT magnum's focus,
but we can't refer to a collection of virtual machines or physical servers with
another name. Bay proven to be confusing to users. I don't think that magnum
should reserve the cluster noun, even if it was available.

[1] https://wiki.openstack.org/wiki/Magnum



$ openstack --help | grep cluster

  --os-clustering-api-version 

  cluster action list  List actions.
  cluster action show  Show detailed info about the specified action.
  cluster build info  Retrieve build information.
  cluster check  Check the cluster(s).
  cluster collect  Collect attributes across a cluster.
  cluster create  Create the cluster.
  cluster delete  Delete the cluster(s).
  cluster event list  List events.
  cluster event show  Describe the event.
  cluster expand  Scale out a cluster by the specified number of nodes.
  cluster list   List the user's clusters.
  cluster members add  Add specified nodes to cluster.
  cluster members del  Delete specified nodes from cluster.
  cluster members list  List nodes from cluster.
  cluster members replace  Replace the nodes in a cluster with
  specified nodes.
  cluster node check  Check the node(s).
  cluster node create  Create the node.
  cluster node delete  Delete the node(s).
  cluster node list  Show list of nodes.
  cluster node recover  Recover the node(s).
  cluster node show  Show detailed info about the specified node.
  cluster node update  Update the node.
  cluster policy attach  Attach policy to cluster.
  cluster policy binding list  List policies from cluster.
  cluster policy binding show  Show a specific policy that is bound to
  the specified cluster.
  cluster policy binding update  Update a policy's properties on a
  cluster.
  cluster policy create  Create a policy.
  cluster policy delete  Delete policy(s).
  cluster policy detach  Detach policy from cluster.
  cluster policy list  List policies that meet the criteria.
  cluster policy show  Show the policy details.
  cluster 

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

[Kumari, Madhuri]

+1 for both.

-Original Message-
From: Wenzhi Yu [mailto:wenzhi...@163.com] 
Sent: Tuesday, January 24, 2017 7:02 PM
To: OpenStack Development Mailing List (not for usage questions) 

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

+1 from me! 
Kevin has made significant contribution to Zun, he deserves this!

Best Regards,
Wenzhi Yu(yuywz)
> 在 2017年1月24日，下午5:12，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



__
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] [Magnum] New Core Reviewers

[Kumari, Madhuri]

+1 for both.

-Original Message-
From: Adrian Otto [mailto:adrian.o...@rackspace.com] 
Sent: Tuesday, November 8, 2016 12:36 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Magnum] New Core Reviewers

Magnum Core Team,

I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
Reviewers. Please respond with your votes.

Thanks,

Adrian Otto
__
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 Zun core team

[Kumari, Madhuri]

+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] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

[Kumari, Madhuri]

+1 from me for both.

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Wednesday, August 10, 2016 8:40 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu 
for Zun core reviewer team

Hi all,

Both Sudipta and Wenzhi have been actively contributing to the Zun project for 
a while. Sudipta provided helpful advice for the project roadmap and 
architecture design. Wenzhi consistently contributed high quality patches and 
insightful reviews. I think both of them are qualified to join the core team.

I am happy to propose Sudipta and Wenzhi to be core reviewers of Zun team. 
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, Sudipta 
and Wenzhi are not able to join the core team and needs to wait 30 days to 
reapply.

The voting is open until Wednesday August 17st.

[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] Proposing Spyros Trigazis for Magnum core reviewer team

[Kumari, Madhuri]

+1 for Sypros.

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Saturday, July 23, 2016 1:57 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core 
reviewer team

Hi all,

Spyros has consistently contributed to Magnum for a while. In my opinion, what 
differentiate him from others is the significance of his contribution, which 
adds concrete value to the project. For example, the operator-oriented install 
guide he delivered attracts a significant number of users to install Magnum, 
which facilitates the adoption of the project. I would like to emphasize that 
the Magnum team has been working hard but struggling to increase the adoption, 
and Spyros's contribution means a lot in this regards. He also completed 
several essential and challenging tasks, such as adding support for OverlayFS, 
adding Rally job for Magnum, etc. In overall, I am impressed by the amount of 
high-quality patches he submitted. He is also helpful in code reviews, and his 
comments often help us identify pitfalls that are not easy to identify. He is 
also very active in IRC and ML. Based on his contribution and expertise, I 
think he is qualified to be a Magnum core reviewer.

I am happy to propose Spyros to be a core reviewer of Magnum team. According to 
the OpenStack Governance process [1], we require a minimum of 4 +1 votes from 
Magnum 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, Spyros is not able 
to join the core team and needs to wait 30 days to reapply.

The voting is open until Thursday July 29st.

[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] Following Magnum QuickStart page, how do i use Docker CLI directly to manage containers

[Kumari, Madhuri]

Hi Greg,

Yes we do have document that explains the steps to configure your docker client 
to to be able to interact to bays.
Please follow this link 
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

Regards,
Madhuri

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Monday, July 18, 2016 6:53 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Following Magnum QuickStart page, how do i 
use Docker CLI directly to manage containers

Was trying out Magnum in Devstack, following the instructions at 
http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html

I successfully created a swarmbay.
test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
nova keypair-add --pub-key ~/.ssh/id_rsa.pub testkey
magnum baymodel-create --name swarmbaymodel \
   --image-id fedora-21-atomic-5 \
   --keypair-id testkey \
   --external-network-id public \
   --dns-nameserver 8.8.8.8 \
   --flavor-id m1.small \
   --docker-volume-size 5 \
   --coe swarm
magnum bay-create --name swarmbay --baymodel swarmbaymodel --node-count 2

Given that the ‘magnum container-… …’ APIs are no longer supported,
I wanted to use the Docker CLI directly to manage containers.

Is there an updated dev-quickstart guide on how to do this ?

-  I tried ssh-ing to the swarm-master VM, using the key … but could 
not connect.

-  ???

Greg.
__
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] Is LBAAS mandatory for MAGNUM ?

[Kumari, Madhuri]

Hi Greg,

Now it is not mandatory to have lbaas in Magnum. Here is blueprint in Magnum 
that aims to decouple lbaas from  Magnum 
https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas.
You can use flag –master-lb-enabled in baymodel to specify whether you want 
lbaas or not. However it just allows you to disable lbaas when master count is 
1.

Regards,
Madhuri

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Monday, July 18, 2016 5:11 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Is LBAAS mandatory for MAGNUM ?

I’m relatively new to looking at Magnum.
Just recently played with Magnum in devstack on Newton.
I noticed that the HEAT Stack used by Magnum created Load Balancer Pool and 
Load Balancer HealthMonitor.

QUESTION … Is LBAAS support mandatory for MAGNUM ?  or can it be used 
(configured) without it ?

i.e. if the OpenStack distribution being used does NOT support LBAAS, will 
MAGNUM work ?   will it still be useful ?

( … thinking that it could still be used, although would not support the load 
balancing across scaled or multiple instances of a container … )

Greg.
__
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] 2 million requests / sec, 100s of nodes

[Kumari, Madhuri]

Hi Ricardo,

Thanks for sharing it. Result seems great and we will surely try to fix the 
issue.

Cheers!

Regards,
Madhuri

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com] 
Sent: Friday, June 17, 2016 8:44 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

Hi.

Just thought the Magnum team would be happy to hear :)

We had access to some hardware the last couple days, and tried some tests with 
Magnum and Kubernetes - following an original blog post from the kubernetes 
team.

Got a 200 node kubernetes bay (800 cores) reaching 2 million requests / sec.

Check here for some details:
https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html

We'll try bigger in a couple weeks, also using the Rally work from Winnie, Ton 
and Spyros to see where it breaks. Already identified a couple issues, will add 
bugs or push patches for those. If you have ideas or suggestions for the next 
tests let us know.

Magnum is looking pretty good!

Cheers,
Ricardo

__
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] [Higgins] Call for contribution for Higgins API design

[Kumari, Madhuri]

Hi,

We have created an etherpad page for API design 
https://etherpad.openstack.org/p/zun-containers-service-api
Please have a look and write your suggestions.

Regards,
Madhuri

From: Yuanying OTSUKA [mailto:yuany...@oeilvert.org]
Sent: Tuesday, June 14, 2016 9:39 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Sheel Rana Insaan <ranasheel2...@gmail.com>
Cc: adit...@nectechnologies.in; yanya...@cn.ibm.com; flw...@catalyst.net.nz; Qi 
Ming Teng <teng...@cn.ibm.com>; sitlani.namr...@yahoo.in; Yuanying 
<yuany...@fraction.jp>; Chandan Kumar <chku...@redhat.com>
Subject: Re: [openstack-dev] [Higgins] Call for contribution for Higgins API 
design

Hi, Hongbin,

Yes, those urls are just information for our work.
We will create a etherpad page to collaborate.




2016年6月11日(土) 7:38 Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>>:
Yuanying,

The etherpads you pointed to were a few years ago and the information looks a 
bit outdated. I think we can collaborate a similar etherpad with updated 
information (i.e. remove container runtimes that we don’t care, add container 
runtimes that we care). The existing etherpad can be used as a starting point. 
What do you think?

Best regards,
Hongbin

From: Yuanying OTSUKA 
[mailto:yuany...@oeilvert.org<mailto:yuany...@oeilvert.org>]
Sent: June-01-16 12:43 AM
To: OpenStack Development Mailing List (not for usage questions); Sheel Rana 
Insaan
Cc: adit...@nectechnologies.in<mailto:adit...@nectechnologies.in>; 
yanya...@cn.ibm.com<mailto:yanya...@cn.ibm.com>; 
flw...@catalyst.net.nz<mailto:flw...@catalyst.net.nz>; Qi Ming Teng; 
sitlani.namr...@yahoo.in<mailto:sitlani.namr...@yahoo.in>; Yuanying; Chandan 
Kumar
Subject: Re: [openstack-dev] [Higgins] Call for contribution for Higgins API 
design

Just F.Y.I.

When Magnum wanted to become “Container as a Service”,
There were some discussion about API design.

* https://etherpad.openstack.org/p/containers-service-api
* https://etherpad.openstack.org/p/openstack-containers-service-api



2016年6月1日(水) 12:09 Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>>:
Sheel,

Thanks for taking the responsibility. Assigned the BP to you. As discussed, 
please submit a spec for the API design. Feel free to let us know if you need 
any help.

Best regards,
Hongbin

From: Sheel Rana Insaan 
[mailto:ranasheel2...@gmail.com<mailto:ranasheel2...@gmail.com>]
Sent: May-31-16 9:23 PM
To: Hongbin Lu
Cc: adit...@nectechnologies.in<mailto:adit...@nectechnologies.in>; 
vivek.jain.openst...@gmail.com<mailto:vivek.jain.openst...@gmail.com>; 
flw...@catalyst.net.nz<mailto:flw...@catalyst.net.nz>; Shuu Mutou; Davanum 
Srinivas; OpenStack Development Mailing List (not for usage questions); Chandan 
Kumar; hai...@xr.jp.nec.com<mailto:hai...@xr.jp.nec.com>; Qi Ming Teng; 
sitlani.namr...@yahoo.in<mailto:sitlani.namr...@yahoo.in>; Yuanying; Kumari, 
Madhuri; yanya...@cn.ibm.com<mailto:yanya...@cn.ibm.com>
Subject: Re: [Higgins] Call for contribution for Higgins API design


Dear Hongbin,

I am interested in this.
Thanks!!

Best Regards,
Sheel Rana
On Jun 1, 2016 3:53 AM, "Hongbin Lu" 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:
Hi team,

As discussed in the last team meeting, we agreed to define core use cases for 
the API design. I have created a blueprint for that. We need an owner of the 
blueprint and it requires a spec to clarify the API design. Please let me know 
if you interest in this work (it might require a significant amount of time to 
work on the spec).

https://blueprints.launchpad.net/python-higgins/+spec/api-design

Best regards,
Hongbin
__
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
__
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
__
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] Discuss the idea of manually managing the bay nodes

[Kumari, Madhuri]

Hi Hongbin,

I also liked the idea of having heterogeneous set of nodes but IMO such 
features should not be implemented in Magnum, thus deviating Magnum again from 
its roadmap. Whereas we should leverage Heat(or may be Senlin) APIs for the 
same.

I vote +1 for this feature.

Regards,
Madhuri

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com] 
Sent: Thursday, June 2, 2016 3:33 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually managing the 
bay nodes

Personally, I think this is a good idea, since it can address a set of similar 
use cases like below:
* I want to deploy a k8s cluster to 2 availability zone (in future 2 
regions/clouds).
* I want to spin up N nodes in AZ1, M nodes in AZ2.
* I want to scale the number of nodes in specific AZ/region/cloud. For example, 
add/remove K nodes from AZ1 (with AZ2 untouched).

The use case above should be very common and universal everywhere. To address 
the use case, Magnum needs to support provisioning heterogeneous set of nodes 
at deploy time and managing them at runtime. It looks the proposed idea 
(manually managing individual nodes or individual group of nodes) can address 
this requirement very well. Besides the proposed idea, I cannot think of an 
alternative solution.

Therefore, I vote to support the proposed idea.

Best regards,
Hongbin

> -Original Message-
> From: Hongbin Lu
> Sent: June-01-16 11:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [magnum] Discuss the idea of manually 
> managing the bay nodes
> 
> Hi team,
> 
> A blueprint was created for tracking this idea:
> https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-
> nodes . I won't approve the BP until there is a team decision on 
> accepting/rejecting the idea.
> 
> From the discussion in design summit, it looks everyone is OK with the 
> idea in general (with some disagreements in the API style). However, 
> from the last team meeting, it looks some people disagree with the 
> idea fundamentally. so I re-raised this ML to re-discuss.
> 
> If you agree or disagree with the idea of manually managing the Heat 
> stacks (that contains individual bay nodes), please write down your 
> arguments here. Then, we can start debating on that.
> 
> Best regards,
> Hongbin
> 
> > -Original Message-
> > From: Cammann, Tom [mailto:tom.camm...@hpe.com]
> > Sent: May-16-16 5:28 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually 
> > managing the bay nodes
> >
> > The discussion at the summit was very positive around this
> requirement
> > but as this change will make a large impact to Magnum it will need a 
> > spec.
> >
> > On the API of things, I was thinking a slightly more generic 
> > approach to incorporate other lifecycle operations into the same API.
> > Eg:
> > magnum bay-manage  
> >
> > magnum bay-manage  reset –hard
> > magnum bay-manage  rebuild
> > magnum bay-manage  node-delete  magnum bay-manage 
> >  node-add –flavor  magnum bay-manage  node-reset 
> >  magnum bay-manage  node-list
> >
> > Tom
> >
> > From: Yuanying OTSUKA 
> > Reply-To: "OpenStack Development Mailing List (not for usage 
> > questions)" 
> > Date: Monday, 16 May 2016 at 01:07
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually 
> > managing the bay nodes
> >
> > Hi,
> >
> > I think, user also want to specify the deleting node.
> > So we should manage “node” individually.
> >
> > For example:
> > $ magnum node-create —bay …
> > $ magnum node-list —bay
> > $ magnum node-delete $NODE_UUID
> >
> > Anyway, if magnum want to manage a lifecycle of container 
> > infrastructure.
> > This feature is necessary.
> >
> > Thanks
> > -yuanying
> >
> >
> > 2016年5月16日(月) 7:50 Hongbin Lu
> > >:
> > Hi all,
> >
> > This is a continued discussion from the design summit. For recap, 
> > Magnum manages bay nodes by using ResourceGroup from Heat. This 
> > approach works but it is infeasible to manage the heterogeneity
> across
> > bay nodes, which is a frequently demanded feature. As an example, 
> > there is a request to provision bay nodes across availability zones
> [1].
> > There is another request to provision bay nodes with different set 
> > of flavors [2]. For the request features above, ResourceGroup won’t 
> > work very well.
> >
> > The proposal is to remove the usage of ResourceGroup and manually 
> > create Heat stack for each bay nodes. For example, for creating a 
> > cluster with 2 masters and 3 minions, Magnum is going to manage 6
> Heat
> > stacks (instead of 1 big 

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

[Kumari, Madhuri]

Thanks Shu for providing suggestions.

I wanted the new name to be related to containers as Magnum is also synonym for 
containers. So I have few options here.

1. Casket
2. Canister
3. Cistern
4. Hutch

All above options are free to be taken on pypi and Launchpad.
Thoughts?

Regards
Madhuri

-Original Message-
From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com] 
Sent: Wednesday, June 1, 2016 11:11 AM
To: openstack-dev@lists.openstack.org
Cc: Haruhiko Katou 
Subject: Re: [openstack-dev] [higgins] Should we rename "Higgins"?

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) 
> 
> 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 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] Proposing Eli Qiao to be a Higgins core

[Kumari, Madhuri]

+1 for Eli. Great addition to team.

Regards,
Madhuri

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Wednesday, June 1, 2016 8:11 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Higgins] Proposing Eli Qiao to be a Higgins core

+1 Welcome Eli

-- Dims

On Tue, May 31, 2016 at 9:22 PM, Yanyan Hu  wrote:
> +1, welcome, Eli :)
>
> 2016-06-01 7:07 GMT+08:00 Yuanying OTSUKA :
>>
>> +1, He will become a good contributor!
>>
>>
>>
>> 2016年6月1日(水) 7:14 Fei Long Wang :
>>>
>>> +1
>>>
>>>
>>> On 01/06/16 09:39, Hongbin Lu wrote:
>>>
>>> Hi team,
>>>
>>>
>>>
>>> I wrote this email to propose Eli Qiao (taget-9) to be a Higgins core.
>>> Normally, the requirement to join the core team is to consistently 
>>> contribute to the project for a certain period of time. However, 
>>> given the fact that the project is new and the initial core team was 
>>> formed based on a commitment, I am fine to propose a new core based 
>>> on a strong commitment to contribute plus a few useful 
>>> patches/reviews. In addition, Eli Qiao is currently a Magnum core 
>>> and I believe his expertise will be an asset of Higgins team.
>>>
>>>
>>>
>>> According to the OpenStack Governance process [1], we require a 
>>> minimum of 4 +1 votes from existing Higgins core team 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, Eli is not able to 
>>> join the core team and needs to wait 30 days to reapply.
>>>
>>>
>>>
>>> The voting is open until Tuesday June 7st.
>>>
>>>
>>>
>>> [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
>>>
>>>
>>> --
>>> 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 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
>



--
Davanum Srinivas :: https://twitter.com/dims

__
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] [magnum] How to document 'labels'

[Kumari, Madhuri]

Hi,

+1 for option #2. Its ok to fetch help message from API server but a drawback 
is help message is supposed to work generally even if the actual services are 
not running.
Thoughts?

Regards,
Madhuri

-Original Message-
From: taget [mailto:qiaoliy...@gmail.com] 
Sent: Thursday, May 12, 2016 7:01 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] How to document 'labels'

+1 for #2, to keep help message in magnum API server, since we have an
validation list in API Server, see
https://review.openstack.org/#/c/312990/5/magnum/api/attr_validator.py@23 .

But, if we chose #2 , CLI should add supporting to retrieve help message from 
API server.

On 2016年05月12日 09:10, Shuu Mutou wrote:
> 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-suppo
> rt
>
> 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

--
Best Regards, Eli Qiao (乔立勇)


__
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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

[Kumari, Madhuri]

+1 from me. Thanks Eli for your contribution.

Regards,
Madhuri

From: Yuanying OTSUKA [mailto:yuany...@oeilvert.org]
Sent: Friday, April 1, 2016 8:13 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core 
reviewer team

+1 for Eli

Thanks
-Yuanying

2016年4月1日(金) 10:59 王华 
>:
+1 for Eli.

Best Regards,
Wanghua

On Fri, Apr 1, 2016 at 9:51 AM, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> wrote:
+1 for Eli.

Regards,
Gary Duan

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Friday, April 01, 2016 2:18 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer 
team

Hi all,

Eli Qiao has been consistently contributed to Magnum for a while. His 
contribution started from about 10 months ago. Along the way, he implemented 
several important blueprints and fixed a lot of bugs. His contribution covers 
various aspects (i.e. APIs, conductor, unit/functional tests, all the COE 
templates, etc.), which shows that he has a good understanding of almost every 
pieces of the system. The feature set he contributed to is proven to be 
beneficial to the project. For example, the gate testing framework he heavily 
contributed to is what we rely on every days. His code reviews are also 
consistent and useful.

I am happy to propose Eli Qiao to be a core reviewer of Magnum team. According 
to the OpenStack Governance process [1], we require a minimum of 4 +1 votes 
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, Eli is not able to join the core team 
and needs to wait 30 days to reapply.

The voting is open until Thursday April 7st.

[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

__
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] [Magnum] API service won't work if conductor down?

[Kumari, Madhuri]

Corey the one you are talking about has changed to coe-service-*.

Eli, IMO we should display proper error message. M-api service should only have 
read permission.

Regards,
Madhuri

From: Corey O'Brien [mailto:coreypobr...@gmail.com]
Sent: Wednesday, February 3, 2016 6:50 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] API service won't work if conductor down?

The service-* commands aren't related to the magnum services (e.g. 
magnum-conductor). The service-* commands are for services on the bay that the 
user creates and deletes.

Corey

On Wed, Feb 3, 2016 at 2:25 AM Eli Qiao 
> wrote:
hi
Whey I try to run magnum service-list to list all services (seems now we only 
have m-cond service), it m-cond is down(which means no conductor at all),
API won't response and will return a timeout error.

taget@taget-ThinkStation-P300:~/devstack$ magnum service-list
ERROR: Timed out waiting for a reply to message ID 
fd1e9529f60f42bf8db903bbf75bbade (HTTP 500)

And I debug more and compared with nova service-list, nova will give response 
and will tell the conductor is down.

and deeper I get this in magnum-api boot up:

# Enable object backporting via the conductor
base.MagnumObject.indirection_api = base.MagnumObjectIndirectionAPI()

so in magnum_service api code

return objects.MagnumService.list(context, limit, marker, sort_key,
  sort_dir)

will require to use magnum-conductor to access DB, but no magnum-conductor at 
all, then we get a 500 error.
(nova-api doesn't specify indirection_api so nova-api can access DB)

My question is:

1) is this by designed that we don't allow magnum-api to access DB directly ？
2) if 1) is by designed, then `magnum service-list` won't work, and the error 
message should be improved such as "magnum service is down , please check 
magnum conductor is alive"

What do you think?

P.S. I tested comment this line:
# base.MagnumObject.indirection_api = base.MagnumObjectIndirectionAPI()
magnum-api will response but failed to create bay(), which means api service 
have read access but can not write it at all since(all db write happened in 
conductor layer).



--

Best Regards, Eli(Li Yong)Qiao

Intel OTC China
__
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] [Magnum] New Core Reviewers

[Kumari, Madhuri]

+1 for both. Welcome!

From: 大塚元央 [mailto:yuany...@oeilvert.org]
Sent: Tuesday, February 2, 2016 9:39 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] New Core Reviewers

+1 welcome!!

2016年2月2日(火) 10:14 Eli Qiao 
>:
+1 +1 thanks for both harding reviewing.

On 2016年02月01日 23:58, Adrian Otto wrote:
> Magnum Core Team,
>
> I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. 
> Please respond with your votes.
>
> Thanks,
>
> Adrian Otto
> __
> 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, Eli(Li Yong)Qiao
Intel OTC China

__
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