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

[Yuanying OTSUKA]

+1 for both.

Best regards
-yuanying

2016年11月8日(火) 4:23 Hongbin Lu :

> +1!
>
> Both jvgrant and yatin contributed a lot to the Magnum project. It would
> be great to have both of you in the core team.
>
> Best regards,
> Hongbin
>
> > -Original Message-
> > From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> > Sent: November-07-16 2:06 PM
> > 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
>
__
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 internet-access necessary for Magnum + CoreOS?

[Yuanying OTSUKA]

Hi, Rikimaru.

Currently, k8s-CoreOS driver dosen’t have way to disable internet access.
But k8s-fedora driver has.

See, below blueprint.
* https://blueprints.launchpad.net/magnum/+spec/support-insecure-registry

Maybe you can bring this feature to k8s-coreos driver.


Thanks
-yuanying


2016年11月1日(火) 15:05 Rikimaru Honjo :

> Hi all,
>
> Can I use magnum + CoreOS on the environment which is not able to access
> the internet?
> I'm trying it, but CoreOS often accesses to "quay.io".
> Please share the knowledge if you know about it.
>
> I'm using CoreOS, kubernetes, Magnum 2.0.1.
>
> Regards,
> --
> Rikimaru Honjo
> honjo.rikim...@po.ntts.co.jp
>
>
> __
> 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 Spyros Trigazis for Magnum core reviewer team

[Yuanying OTSUKA]

+1, Spyros will be a great addition to the team.

Yuanying

2016年7月25日(月) 9:39 taget :

> I am +1
>
> Eli.
>
>
> On 2016年07月23日 04:27, Hongbin Lu wrote:
>
> 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Best Regards,
> Eli Qiao (乔立勇), Intel OTC.
>
> __
> 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] Need helps to implement the full baremetals support

[Yuanying OTSUKA]

Hi, Spyros

Thanks for testing it.
Maybe you see that there are some problems to support baremetal.
We should add functional test to our jenkins job
because this template will be broken easily if anyone adds some logic to
our templates/codes.
But following problems will block us.

1. How to get Fedora 23 image which includes k8s?
2. How to solve Ironic instance_info problem?

Currently I have no idea, maybe time will solve these?


Thanks
-yuanying

2016年6月21日(火) 0:30 Spyros Trigazis <strig...@gmail.com>:

> Hi Yuanying,
>
> I tested your patch [2] with the image that Ton created [1] and it worked.
>
> For me devicemapper as docker-storage-driver didn't work but this is
> unrelated to this patch, I'll update devicemapper. I used overlay and
> it was ok.
>
> I'll sum up what I did here, for others to test.
>
> On a fresh install of Ubuntu 14.04.3
>
> 0-
> setup environment as in:
>
> http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html#dev-quickstart
>
> 1-
> I used a local.conf with less configuration and I added magnum.
> https://stikked.web.cern.ch/stikked/view/35816b1d
>
> 2-
> Update subnets with dns-nameserver
> neutron subnet-update private-subnet --dns-nameserver 8.8.8.8
> neutron subnet-update public-subnet --dns-nameserver 8.8.8.8
>
> 3-
> Modify ironic.nodes table
> alter table ironic.nodes modify instance_info LONGTEXT;
>
> 4-
> download images [1] and register as in:
>
> https://review.openstack.org/#/c/320968/10/magnum/elements/kubernetes/README.md
>
> 5-
> update iptables as in our devstack script:
> https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L326
>
> 6-
> magnum baymodel-create --name k8s-ironic-baymodel \
>--keypair-id testkey \
>--server-type bm \
>--external-network-id public \
>--fixed-network private \
>--image-id fedora-k8s \
>--flavor-id baremetal \
>--network-driver flannel \
>--dns 8.8.8.8 \
>--coe kubernetes \
>--docker-storage-driver overlay
>
> 7-
> create bay
> magnum bay-create --name k8s-ironbay --baymodel k8s-ironic-baymodel 
> --node-count
> 1
>
> It took a few minutes to get CREATE_COMPLETE on my 4-core desktop.
>
> Thanks Yuanying and Ton!
>
> Cheers,
> Spyros
>
>
> [1] https://fedorapeople.org/groups/magnum/fedora-23-kubernetes*
> [2] https://review.openstack.org/#/c/320968/
>
>
> On 14 June 2016 at 03:26, Yuanying OTSUKA <yuany...@oeilvert.org> wrote:
>
>> Hi, Spyros
>>
>> I updated ironic heat template, and succeeded booting k8s bay with Ironic.
>> Could you test it?
>>
>> Unfortunately there are some problem and requirement to test.
>> I describe below.
>>
>> * subnet which belongs to private network should be set up with
>> dns_nameservers like following.
>>
>> $ neutron subnet-update private-subnet —dns-nameserver 8.8.8.8
>>
>> * modify ironic.nodes table
>>
>> $ alter table ironic.nodes modify instance_info LONGTEXT;
>>
>> * baymodel
>>
>> $ magnum baymodel-create —name kubernetes —keypair-id default \
>>--server-type bm \
>>--external-network-id public \
>>--fixed-network private \
>>--image-id fedora-k8s \
>>--flavor-id baremetal \
>>--network-driver flannel \
>>        --coe kubernetes
>>
>> * Fedora image
>> Following procedure depends on diskimage-builder fix:
>> https://review.openstack.org/#/c/247296/
>>
>> https://review.openstack.org/#/c/320968/10/magnum/elements/kubernetes/README.md
>>
>> * my local.conf to setup ironic env
>> http://paste.openstack.org/show/515877/
>>
>>
>> Thanks
>> -yuanying
>>
>>
>> 2016年5月25日(水) 22:00 Yuanying OTSUKA <yuany...@oeilvert.org>:
>>
>>> Hi, Spyros
>>>
>>> I fixed a conflicts and upload following patch.
>>> * https://review.openstack.org/#/c/320968/
>>>
>>> But it isn’t tested yet, maybe it doesn’t work..
>>> If you have a question, please feel free to ask.
>>>
>>>
>>> Thanks
>>> -yuanying
>>>
>>>
>>>
>>> 2016年5月25日(水) 17:56 Spyros Trigazis <strig...@gmail.com>:
>>>
>>>> Hi Yuanying,
>>>>
>>

Re: [openstack-dev] [Higgins] Call for contribution for Higgins API design

[Yuanying OTSUKA]

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>:

> 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]
> *Sent:* June-01-16 12:43 AM
> *To:* OpenStack Development Mailing List (not for usage questions); Sheel
> Rana Insaan
> *Cc:* adit...@nectechnologies.in; yanya...@cn.ibm.com;
> flw...@catalyst.net.nz; Qi Ming Teng; 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>:
>
> 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]
> *Sent:* May-31-16 9:23 PM
> *To:* Hongbin Lu
> *Cc:* adit...@nectechnologies.in; vivek.jain.openst...@gmail.com;
> flw...@catalyst.net.nz; Shuu Mutou; Davanum Srinivas; OpenStack
> Development Mailing List (not for usage questions); Chandan Kumar;
> hai...@xr.jp.nec.com; Qi Ming Teng; sitlani.namr...@yahoo.in; Yuanying;
> Kumari, Madhuri; 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> 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://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-ui][magnum] Proposed Core addition, and removal notice

[Yuanying OTSUKA]

+1

Thanks
-yuanying

2016年6月14日(火) 10:55 Kai Qiang Wu :

> +1 Welcome to new one :)
>
>
>
> Thanks
>
> Best Wishes,
>
> 
> Kai Qiang Wu (吴开强 Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wk...@cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
>
> 
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for 王华 ---13/06/2016 05:30:39 pm---+1 On
> Fri, Jun 10, 2016 at 5:32 PM, Shuu Mutou  ---13/06/2016 05:30:39 pm---+1 On Fri, Jun 10, 2016 at 5:32 PM, Shuu Mutou <
> shu-mu...@rf.jp.nec.com> wrote:
>
> From: 王华 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 13/06/2016 05:30 pm
> Subject: Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition,
> and removal notice
> --
>
>
>
>
> +1
>
> On Fri, Jun 10, 2016 at 5:32 PM, Shuu Mutou <*shu-mu...@rf.jp.nec.com*
> > wrote:
>
>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*
>
>
> __
> 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] Need helps to implement the full baremetals support

[Yuanying OTSUKA]

Hi, Spyros

I updated ironic heat template, and succeeded booting k8s bay with Ironic.
Could you test it?

Unfortunately there are some problem and requirement to test.
I describe below.

* subnet which belongs to private network should be set up with
dns_nameservers like following.

$ neutron subnet-update private-subnet —dns-nameserver 8.8.8.8

* modify ironic.nodes table

$ alter table ironic.nodes modify instance_info LONGTEXT;

* baymodel

$ magnum baymodel-create —name kubernetes —keypair-id default \
   --server-type bm \
   --external-network-id public \
   --fixed-network private \
   --image-id fedora-k8s \
   --flavor-id baremetal \
   --network-driver flannel \
   --coe kubernetes

* Fedora image
Following procedure depends on diskimage-builder fix:
https://review.openstack.org/#/c/247296/
https://review.openstack.org/#/c/320968/10/magnum/elements/kubernetes/README.md

* my local.conf to setup ironic env
http://paste.openstack.org/show/515877/


Thanks
-yuanying


2016年5月25日(水) 22:00 Yuanying OTSUKA <yuany...@oeilvert.org>:

> Hi, Spyros
>
> I fixed a conflicts and upload following patch.
> * https://review.openstack.org/#/c/320968/
>
> But it isn’t tested yet, maybe it doesn’t work..
> If you have a question, please feel free to ask.
>
>
> Thanks
> -yuanying
>
>
>
> 2016年5月25日(水) 17:56 Spyros Trigazis <strig...@gmail.com>:
>
>> Hi Yuanying,
>>
>> please upload your workaround. I can test it and try to fix the conflicts.
>> Even if it conflicts we can have some iterations on it.
>>
>> I'll upload later what worked for me on devstack.
>>
>> Thanks,
>> Spyros
>>
>> On 25 May 2016 at 05:13, Yuanying OTSUKA <yuany...@oeilvert.org> wrote:
>>
>>> Hi, Hongbin, Spyros.
>>>
>>> I’m also interesting this work.
>>> I have workaround patch to support ironic.
>>> (but currently conflict with master.
>>> Is it helpful to upload it for initial step of the implementation?
>>>
>>> Thanks
>>> -yuanying
>>>
>>> 2016年5月25日(水) 6:52 Hongbin Lu <hongbin...@huawei.com>:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> One of the most important feature that Magnum team wants to deliver in
>>>> Newton is the full baremetal support. There is a blueprint [1] created for
>>>> that and the blueprint was marked as “essential” (that is the highest
>>>> priority). Spyros is the owner of the blueprint and he is looking for helps
>>>> from other contributors. For now, we immediately needs help to fix the
>>>> existing Ironic templates [2][3][4] that are used to provision a Kubernetes
>>>> cluster on top of baremetal instances. These templates were used to work,
>>>> but they become outdated right now. We need help to fix those Heat template
>>>> as an initial step of the implementation. Contributors are expected to
>>>> follow the Ironic devstack guide to setup the environment. Then, exercise
>>>> those templates in Heat.
>>>>
>>>>
>>>>
>>>> If you interest to take the work, please contact Spyros or me and we
>>>> will coordinate the efforts.
>>>>
>>>>
>>>>
>>>> [1]
>>>> https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
>>>>
>>>> [2]
>>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster-fedora-ironic.yaml
>>>>
>>>> [3]
>>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster-fedora-ironic.yaml
>>>>
>>>> [4]
>>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion-fedora-ironic.yaml
>>>>
>>>>
>>>>
>>>> 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 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

[Yuanying OTSUKA]

ing 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 <yuany...@oeilvert.org>
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>> questions)" <openstack-dev@lists.openstack.org>
> >>> Date: Monday, 16 May 2016 at 01:07
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> <openstack-dev@lists.openstack.org>
> >>> 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
> >>> <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>:
> >>> 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 Heat stack as right now):
> >>> * A kube cluster stack that manages the global resources
> >>> * Two kube master stacks that manage the two master nodes
> >>> * Three kube minion stacks that manage the three minion nodes
> >>>
> &g

Re: [openstack-dev] [Higgins] Call for contribution for Higgins API design

[Yuanying OTSUKA]

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 :

> 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]
> *Sent:* May-31-16 9:23 PM
> *To:* Hongbin Lu
> *Cc:* adit...@nectechnologies.in; vivek.jain.openst...@gmail.com;
> flw...@catalyst.net.nz; Shuu Mutou; Davanum Srinivas; OpenStack
> Development Mailing List (not for usage questions); Chandan Kumar;
> hai...@xr.jp.nec.com; Qi Ming Teng; sitlani.namr...@yahoo.in; Yuanying;
> Kumari, Madhuri; 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"  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://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

[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:unsubscribehttp://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

Re: [openstack-dev] [magnum] Need helps to implement the full baremetals support

[Yuanying OTSUKA]

Hi, Spyros

I fixed a conflicts and upload following patch.
* https://review.openstack.org/#/c/320968/

But it isn’t tested yet, maybe it doesn’t work..
If you have a question, please feel free to ask.


Thanks
-yuanying



2016年5月25日(水) 17:56 Spyros Trigazis <strig...@gmail.com>:

> Hi Yuanying,
>
> please upload your workaround. I can test it and try to fix the conflicts.
> Even if it conflicts we can have some iterations on it.
>
> I'll upload later what worked for me on devstack.
>
> Thanks,
> Spyros
>
> On 25 May 2016 at 05:13, Yuanying OTSUKA <yuany...@oeilvert.org> wrote:
>
>> Hi, Hongbin, Spyros.
>>
>> I’m also interesting this work.
>> I have workaround patch to support ironic.
>> (but currently conflict with master.
>> Is it helpful to upload it for initial step of the implementation?
>>
>> Thanks
>> -yuanying
>>
>> 2016年5月25日(水) 6:52 Hongbin Lu <hongbin...@huawei.com>:
>>
>>> Hi all,
>>>
>>>
>>>
>>> One of the most important feature that Magnum team wants to deliver in
>>> Newton is the full baremetal support. There is a blueprint [1] created for
>>> that and the blueprint was marked as “essential” (that is the highest
>>> priority). Spyros is the owner of the blueprint and he is looking for helps
>>> from other contributors. For now, we immediately needs help to fix the
>>> existing Ironic templates [2][3][4] that are used to provision a Kubernetes
>>> cluster on top of baremetal instances. These templates were used to work,
>>> but they become outdated right now. We need help to fix those Heat template
>>> as an initial step of the implementation. Contributors are expected to
>>> follow the Ironic devstack guide to setup the environment. Then, exercise
>>> those templates in Heat.
>>>
>>>
>>>
>>> If you interest to take the work, please contact Spyros or me and we
>>> will coordinate the efforts.
>>>
>>>
>>>
>>> [1]
>>> https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
>>>
>>> [2]
>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster-fedora-ironic.yaml
>>>
>>> [3]
>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster-fedora-ironic.yaml
>>>
>>> [4]
>>> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion-fedora-ironic.yaml
>>>
>>>
>>>
>>> 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 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] Need helps to implement the full baremetals support

[Yuanying OTSUKA]

Hi, Hongbin, Spyros.

I’m also interesting this work.
I have workaround patch to support ironic.
(but currently conflict with master.
Is it helpful to upload it for initial step of the implementation?

Thanks
-yuanying

2016年5月25日(水) 6:52 Hongbin Lu :

> Hi all,
>
>
>
> One of the most important feature that Magnum team wants to deliver in
> Newton is the full baremetal support. There is a blueprint [1] created for
> that and the blueprint was marked as “essential” (that is the highest
> priority). Spyros is the owner of the blueprint and he is looking for helps
> from other contributors. For now, we immediately needs help to fix the
> existing Ironic templates [2][3][4] that are used to provision a Kubernetes
> cluster on top of baremetal instances. These templates were used to work,
> but they become outdated right now. We need help to fix those Heat template
> as an initial step of the implementation. Contributors are expected to
> follow the Ironic devstack guide to setup the environment. Then, exercise
> those templates in Heat.
>
>
>
> If you interest to take the work, please contact Spyros or me and we will
> coordinate the efforts.
>
>
>
> [1]
> https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
>
> [2]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster-fedora-ironic.yaml
>
> [3]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster-fedora-ironic.yaml
>
> [4]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion-fedora-ironic.yaml
>
>
>
> 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

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

[Yuanying OTSUKA]

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 Heat stack as right now):
>
> * A kube cluster stack that manages the global resources
>
> * Two kube master stacks that manage the two master nodes
>
> * Three kube minion stacks that manage the three minion nodes
>
>
>
> The proposal might require an additional API endpoint to manage nodes or a
> group of nodes. For example:
>
> $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2
> --availability-zone us-east-1 ….
>
> $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3
> --availability-zone us-east-2 …
>
>
>
> Thoughts?
>
>
>
> [1]
> https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones
>
> [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor
>
>
>
> 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

Re: [openstack-dev] [magnum] Jinja2 for Heat template

[Yuanying OTSUKA]

Hi,

My concern is that using option 1 is acceptable or not (because it’s not
implemented yet.)
So, first step, I’ll implement bp:bay-with-no-floating-ips
<https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips> using
option 1,
and option2 or 3 will be implemented later if supporting older versions are
needed. right?

(Sorry, I remember Tom was working for supporing jinja2, but I didn’t know
current status about it.


Thanks
- OTSUKA, Yuanying


2016年5月13日(金) 3:34 Cammann, Tom <tom.camm...@hpe.com>:

> I’m in broad agreement with Hongbin. Having tried a patch to use jinja2 in
> the templates, it certainly adds complexity. I am in favor of using
> conditionals and consuming the latest version of heat. If we intend to
> support older versions of OpenStack this should be a clearly defined goal
> and needs to be tested. An aspiration to work with older versions isn’t a
> good policy.
>
>
>
> I would like to understand a bit better the “chaos” option 3 would cause.
>
>
>
> Tom
>
>
>
> *From:* Hongbin Lu [mailto:hongbin...@huawei.com]
> *Sent:* 12 May 2016 16:35
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum] Jinja2 for Heat template
>
>
>
> We discussed the management of Heat templates several times. It seems the
> consensus is to leverage the *conditionals*feature from Heat (option #1).
> From the past discussion, it sounds like option #2 or #3 will significantly
> complicate our Heat templates, thus incurring burden on maintenance.
>
>
>
> However, I agree with Yuanying that option #1 will make Newton (or newer)
> version of Magnum incompatible with Mitaka (or older) version of OpenStack.
> A solution I can think of is to have a Jinja2 version of Heat template in
> the contrib folder, so that operators can swap the Heat templates if they
> want to run newer version of Magnum with older version of OpenStack.
> Thoughts.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Yuanying OTSUKA [mailto:yuany...@oeilvert.org
> <yuany...@oeilvert.org>]
> *Sent:* May-12-16 6:02 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum] Jinja2 for Heat template
>
>
>
> Hi,
>
> Thanks for your helpful comment.
>
>
>
> I didn’t know about the pattern you suggested.
>
> We often want to “if” or “for” etc…
>
>
>
> For example,
>
> * if private network is supplied as parameter, disable creating network
> resource.
>
> * if https parameter is enable, tcp 6443 port should be opened instead of
> 8080 at“OS::Neutron::SecurityGroup".
>
> * if https parameter is enable, loadbalancing protocol should be TCP
> instead of HTTP
>
>
>
> and so on.
>
> So, I want to Jinja2 template to manage it.
>
>
>
> I’ll try to use the composition model above,
>
> and also test the limited use of jinja2 templating.
>
>
>
>
>
> Thanks
>
> - OTSUKA, Yuanying
>
>
>
>
>
>
>
> 2016年5月12日(木) 17:46 Steven Hardy <sha...@redhat.com>:
>
> On Thu, May 12, 2016 at 11:08:02AM +0300, Pavlo Shchelokovskyy wrote:
> >Hi,
> >
> >not sure why 3 will bring chaos when implemented properly.
>
> I agree - heat is designed with composition in mind, and e.g in TripleO
> we're making heavy use of it for optional configurations and it works
> pretty well:
>
> http://docs.openstack.org/developer/heat/template_guide/composition.html
>
> https://www.youtube.com/watch?v=fw0JhywwA1E
>
>
> http://hardysteven.blogspot.co.uk/2015/05/tripleo-heat-templates-part-1-roles-and.html
>
>
> https://github.com/openstack/tripleo-heat-templates/tree/master/environments
>
> >Can you abstract the "thing" (sorry, not quite familiar with Magnum)
> that
> >needs FP + FP itself into a custom resource/nested stack? Then you
> could
> >use single master template plus two environments (one with FP, one
> >without), and choose which one to use right where you have this logic
> >split in your code.
>
> Yes, this is exactly the model we make heavy use of in TripleO, it works
> pretty well.
>
> Note there's now an OS::Heat::None resource in heat, which makes it easy to
> conditionally disable things (without the need for a noop.yaml template
> that contains matching parameters):
>
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::None
>
> So you'd have two environment files like:
>
> cat enable_floating.yaml:
> resource_registry:
>   OS::Magnum::FloatingIP: templates/the_floating_config.yaml
>
&g

Re: [openstack-dev] [magnum] Jinja2 for Heat template

[Yuanying OTSUKA]

Hi,
Thanks for your helpful comment.

I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc…

For example,
* if private network is supplied as parameter, disable creating network
resource.
* if https parameter is enable, tcp 6443 port should be opened instead of
8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP
instead of HTTP

and so on.
So, I want to Jinja2 template to manage it.

I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.


Thanks
- OTSUKA, Yuanying



2016年5月12日(木) 17:46 Steven Hardy :

> On Thu, May 12, 2016 at 11:08:02AM +0300, Pavlo Shchelokovskyy wrote:
> >Hi,
> >
> >not sure why 3 will bring chaos when implemented properly.
>
> I agree - heat is designed with composition in mind, and e.g in TripleO
> we're making heavy use of it for optional configurations and it works
> pretty well:
>
> http://docs.openstack.org/developer/heat/template_guide/composition.html
>
> https://www.youtube.com/watch?v=fw0JhywwA1E
>
>
> http://hardysteven.blogspot.co.uk/2015/05/tripleo-heat-templates-part-1-roles-and.html
>
>
> https://github.com/openstack/tripleo-heat-templates/tree/master/environments
>
> >Can you abstract the "thing" (sorry, not quite familiar with Magnum)
> that
> >needs FP + FP itself into a custom resource/nested stack? Then you
> could
> >use single master template plus two environments (one with FP, one
> >without), and choose which one to use right where you have this logic
> >split in your code.
>
> Yes, this is exactly the model we make heavy use of in TripleO, it works
> pretty well.
>
> Note there's now an OS::Heat::None resource in heat, which makes it easy to
> conditionally disable things (without the need for a noop.yaml template
> that contains matching parameters):
>
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::None
>
> So you'd have two environment files like:
>
> cat enable_floating.yaml:
> resource_registry:
>   OS::Magnum::FloatingIP: templates/the_floating_config.yaml
>
> cat disable_floating.yaml:
> resource_registry:
>   OS::Magnum::FloatingIP: OS::Heat::None
>
> Again, this pattern is well proven and works pretty well.
>
> Conditionals may provide an alternative way to do this, but at the expense
> of some additional complexity inside the templates.
>
> >Option 2 is not so bad either IMO (AFAIK Trove was doing that at
> sometime,
> >not sure of current status), but the above would be nicer.
>
> Yes, in the past[1] I've commented that the composition model above may be
> preferable to jinja templating, but recently I've realized there are pros
> and cons to each approach.
>
> The heat composition model works pretty well when you want to combine
> multiple pieces (nested stacks) which contain some mixture of different
> resources, but it doesn't work so well when you want to iterate over a
> common pattern and build a template (e.g based on a loop).
>
> You can use ResourceGroups in some cases, but that adds to the stack depth
> (number of nested stacks), and may not be workable for upgrades, so TripleO
> is now looking at some limited use of jinja2 templating also, I agree it's
> not so bad provided the interfaces presented to the user are carefully
> constrained.
>
> Steve
>
> [1] https://review.openstack.org/#/c/211771/
>
> __
> 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] Jinja2 for Heat template

[Yuanying OTSUKA]

Hi, all.

Now, I’m trying to implement following bp.
* https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips

This bp requires to disable/enable “floating ip resource” in heat template
dynamically.
We have 3 options to implement this.

1. Use “conditions function”
*
https://blueprints.launchpad.net/heat/+spec/support-conditions-function
2. Dynamically generate heat template using Jinja2
3. Separate heat template to “kubecluster-with-floatingip.yaml” and
“kubecluster-no-floatingip.yaml”

Option 1 is easy to implement, but unfortunately this isn’t supported by
Mitaka release.
Option 2 needs a Jinja2 template support by Magnum.
Option 3 will bring chaos.

Please let me know what you think.


Thanks
-OTSUKA, Yuanying
__
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] Are Floating IPs really needed for all nodes?

[Yuanying OTSUKA]

Hi Egor,

I know some people still want to use floating ips to connect nodes,
So I will not remove floating ips feature completely.
Only introduce the option which will disable to assign floating ip to nodes.
Because some people doesn’t want to assign floating ip to nodes.

Thanks
-yuaning

2016年3月31日(木) 13:11 Guz Egor :

> -1
>
> who is going to run/support this proxy? also keep in mind that Kubernetes
> Service/NodePort (
> http://kubernetes.io/docs/user-guide/services/#type-nodeport)
> functionality is not going to work without public ip and this is very
> handy feature.
>
> ---
> Egor
>
> --
> *From:* 王华 
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Sent:* Wednesday, March 30, 2016 8:41 PM
>
> *Subject:* Re: [openstack-dev] [magnum] Are Floating IPs really needed
> for all nodes?
>
> Hi yuanying,
>
> I agree to reduce the usage of floating IP. But as far as I know, if we
> need to pull
> docker images from docker hub in nodes floating ips are needed. To reduce
> the
> usage of floating ip, we can use proxy. Only some nodes have floating ips,
> and
> other nodes can access docker hub by proxy.
>
> Best Regards,
> Wanghua
>
> On Thu, Mar 31, 2016 at 11:19 AM, Eli Qiao  wrote:
>
> Hi Yuanying,
> +1
> I think we can add option on whether to using floating ip address since IP
> address are
> kinds of resource which not wise to waste.
>
>
> On 2016年03月31日 10:40, 大塚元央 wrote:
>
> Hi team,
>
> Previously, we had a reason why all nodes should have floating ips [1].
> But now we have a LoadBalancer features for masters [2] and minions [3].
> And also minions do not necessarily need to have floating ips [4].
> I think it’s the time to remove floating ips from all nodes.
>
> I know we are using floating ips in gate to get log files,
> So it’s not good idea to remove floating ips entirely.
>
> I want to introduce `disable-floating-ips-to-nodes` parameter to bay model.
>
> Thoughts?
>
> [1]:
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/067213.html
> [2]: https://blueprints.launchpad.net/magnum/+spec/make-master-ha
> [3]: https://blueprints.launchpad.net/magnum/+spec/external-lb
> [4]:
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/067280.html
>
> Thanks
> -yuanying
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Best Regards, Eli 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
>
>
> __
> 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

[Yuanying OTSUKA]

+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) <
>> openstack-dev@lists.openstack.org>
>> *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