[openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

[大塚元央]

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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[大塚元央]

+1, welcome Shu.

-Yuanying

On Sat, Mar 5, 2016 at 09:37 Bradley Jones (bradjone) 
wrote:

> +1
>
> Shu has done some great work in magnum-ui and will be a welcome addition
> to the core team.
>
> Thanks,
> Brad
>
> > On 5 Mar 2016, at 00:29, Adrian Otto  wrote:
> >
> > Magnum UI Cores,
> >
> > I propose the following changes to the magnum-ui core group [1]:
> >
> > + Shu Muto
> > - Dims (Davanum Srinivas), by request - justified by reduced activity
> level.
> >
> > Please respond with your +1 votes to approve this change or -1 votes to
> oppose.
> >
> > Thanks,
> >
> > Adrian
> >
> __
> > 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] FW: [magnum][magnum-ui] Liaisons for I18n

[大塚元央]

Hi team,

Shu Muto is interested in to became liaisons  from magnum-ui.
He put great effort into translating English to Japanease in magnum-ui and
horizon.
I recommend him to be liaison.

Thanks
-yuanying

2016年2月29日(月) 23:56 Hongbin Lu :

> Hi team,
>
>
>
> FYI, I18n team needs liaisons from magnum-ui. Please contact the i18n team
> if you interest in this role.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Ying Chun Guo [mailto:guoyi...@cn.ibm.com]
> *Sent:* February-29-16 3:48 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [all][i18n] Liaisons for I18n
>
>
>
> Hello,
>
> Mitaka translation will start soon, from this week.
> In Mitaka translation, IBM full time translators will join the
> translation team and work with community translators.
> With their help, I18n team is able to cover more projects.
> So I need liaisons from dev projects who can help I18n team to work
> compatibly with development team in the release cycle.
>
> I especially need liaisons in below projects, which are in Mitaka
> translation plan:
> nova, glance, keystone, cinder, swift, neutron, heat, horizon, ceilometer.
>
>
>
> I also need liaisons from Horizon plugin projects, which are ready in
> translation website:
>
> trove-dashboard, sahara-dashboard,designate-dasbhard, magnum-ui,
>
> monasca-ui, murano-dashboard and senlin-dashboard.
>
> I need liaisons tell us whether they are ready for translation from
> project view.
>
>
>
> As to other projects, liaisons are welcomed too.
>
> Here are the descriptions of I18n liaisons:
> - The liaison should be a core reviewer for the project and understand the
> i18n status of this project.
> - The liaison should understand project release schedule very well.
> - The liaison should notify I18n team happens of important moments in the
> project release in time.
>
> For example, happen of soft string freeze, happen of hard string freeze,
> and happen of RC1 cutting.
> - The liaison should take care of translation patches to the project, and
> make sure the patches are
>
> successfully merged to the final release version. When the translation
> patch is failed, the liaison
>
> should notify I18n team.
>
> If you are interested to be a liaison and help translators,
> input your information here:
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n .
>
>
>
> Thank you for your support.
>
> Best regards
> Ying Chun Guo (Daisy)
> __
> 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

[大塚元央]

+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

Re: [openstack-dev] [openstack][magnum]Create trustee user for each bay

[大塚元央]

Hi, Hua.

I agree with you if trust_id is secret.
But I think trust_id is not a secret.
User can know trustee_user_name and trustee_password from k8s/swarm
instances.
If user knows about other user's trust_id, user can use a other user's
swift resources.
This wii be a security risk.

Thanks
-yuanying

2015年12月24日(木) 16:49 王华 :

> Hi all,
>
> I want to create a trustee user for each bay [1]. The discussion for trust
> is in [2].
>
> Here is my solution:
> I don't create a user for each bay. All the bays no matter who creates it
> use the same user.
> But we create different trust for the user for different bay. The user can
> not access any service without the trust id. So there is no need to create
> a user for each bay.
>
>
> [1]
> https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay
> [2]https://review.openstack.org/#/c/254705/
>
> Regards,
> Wanghua
> __
> 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][kolla] Stepping down as a Magnum core reviewer

[大塚元央]

Hi Steve,

I'm very sad about your stepping down from Magnum core. Without your help,
I couldn't contribute to magnum project.
But kolla is also fantastic project.
I wish you the best of luck in kolla.

Best regards.
- Yuanying Otsuka

On Tue, Oct 27, 2015 at 00:39 Baohua Yang  wrote:

> Really a pity!
>
> We need more resources on the container part in OpenStack indeed, as so
> many new projects are just initiated.
>
> Community is not only about putting technologies together, but also
> putting technical guys together.
>
> Happy to see so many guys in the Tokyo Summit this afternoon.
>
> Let's take care of the opportunities to make good communications with each
> other.
>
> On Mon, Oct 26, 2015 at 8:17 AM, Steven Dake (stdake) 
> wrote:
>
>> Hey folks,
>>
>> It is with sadness that I find myself under the situation to have to
>> write this message.  I have the privilege of being involved in two of the
>> most successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
>> getting involved in two major initiatives on purpose, to see if I could do
>> the job; to see if  I could deliver two major initiatives at the same
>> time.  I also wanted it to be a length of time that was significant – 1+
>> year.  I found indeed I was able to deliver both Magnum and Kolla, however,
>> the impact on my personal life has not been ideal.
>>
>> The Magnum engineering team is truly a world class example of how an Open
>> Source project should be constructed and organized.  I hope some young
>> academic writes a case study on it some day but until then, my gratitude to
>> the Magnum core reviewer team is warranted by the level of  their sheer
>> commitment.
>>
>> I am officially focusing all of my energy on Kolla going forward.  The
>> Kolla core team elected me as PTL (or more accurately didn’t elect anyone
>> else;) and I really want to be effective for them, especially in what I
>> feel is Kolla’s most critical phase of growth.
>>
>> I will continue to fight  for engineering resources for Magnum internally
>> in Cisco.  Some of these have born fruit already including the Heat
>> resources, the Horizon plugin, and of course the Networking plugin system.
>> I will also continue to support Magnum from a resources POV where I can do
>> so (like the fedora image storage for example).  What I won’t be doing is
>> reviewing Magnum code (serving as a gate), or likely making much technical
>> contribution to Magnum in the future.  On the plus side I’ve replaced
>> myself with many many more engineers from Cisco who should be much more
>> productive combined then I could have been alone ;)
>>
>> Just to be clear, I am not abandoning Magnum because I dislike the people
>> or the technology.  I think the people are fantastic! And the technology –
>> well I helped design the entire architecture!  I am letting Magnum grow up
>> without me as I have other children that need more direct attention.  I
>> think this viewpoint shows trust in the core reviewer team, but feel free
>> to make your own judgements ;)
>>
>> Finally I want to thank Perry Myers for influencing me to excel at
>> multiple disciplines at once.  Without Perry as a role model, Magnum may
>> have never happened (or would certainly be much different then it is
>> today). Being a solid hybrid engineer has a long ramp up time and is really
>> difficult, but also very rewarding.  The community has Perry to blame for
>> that ;)
>>
>> Regards
>> -steve
>>
>> __
>> 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 wishes!
> Baohua
> __
> 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] TLS Support in Magnum

[大塚元央]

Hi, Tom

2015年6月16日(火) 3:00 Tom Cammann tom.camm...@hp.com:


 At the summit we talked about using Magnum as a CA and signing the
 certificates, and we seemed to have some consensus about doing this with
 the
 possibility of using Anchor. This would take a lot of the onus off of
 the user to
 fiddle around with openssl and craft the right signed certs safely. Using
 Magnum as a CA the user would generate a key/cert pair, and then get the
 cert signed by Magnum, and the kube node would do the same. The main
 downside of this technique is that the user MUST trust Magnum and the
 administrator as they would have access to the CA signing cert.


I'm not sure about Anchor.
You mean, Anchor can be used for implementation of Magnum as a CA.
Right?

Thanks
-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] Add periodic task threading for conductor server

[大塚元央]

Hi, folks.

At the last summit, we decided to support pluggable conductor for multi
backend [1].
So, if we choose #3, new service (instance of periodic task) also should
support plugin.
I think this will be a little complicated to implement a plugin.

[1]: https://etherpad.openstack.org/p/liberty-work-abstract-backend

Thanks
-yuanying


2015年6月15日(月) 11:59 Hongbin Lu hongbin...@huawei.com:

  I think option #3 is the most desired choice in performance’s point of
 view, because magnum is going to support multiple conductors and all
 conductors share the same DB. However, if each conductor runs its own
 thread for periodic task, we will end up to have multiple instances of
 tasks for doing the same job (syncing heat’s state to magnum’s DB). I think
 magnum should have only one instance of periodic task since the replicated
 instance of tasks will stress the computing and networking resources.



 Best regards,

 Hongbin



 *From:* Qiao,Liyong [mailto:liyong.q...@intel.com]
 *Sent:* June-14-15 9:38 PM
 *To:* openstack-dev@lists.openstack.org
 *Cc:* qiaoliy...@gmail.com
 *Subject:* [openstack-dev] [Magnum] Add periodic task threading for
 conductor server



 hi magnum team,

 I am planing to add periodic task for magnum conductor service, it will be
 good
 to sync task status with heat and container service. and I have already
 have a WIP
 patch[1], I'd like to start a discussion on the implement.

 Currently, conductor service is an rpc server, and it has several handlers
 endpoints = [
 docker_conductor.Handler(),
 k8s_conductor.Handler(),
 bay_conductor.Handler(),
 conductor_listener.Handler(),
 ]
 all handler runs in the rpc server.

 1. my patch [1] is to add periodic task functions in each handlers (if it
 requires such tasks)
 and setup these functions when start rpc server, add them to a thread
 group.
 so for example:

 if we have task in bay_conductor.Handler() and docker_conductor.Handler(),
 then adding 2 threads to current service's tg. each thread run it own
 periodic tasks.

 the advantage is we separate each handler's task job to separate thread.
 but hongbin's concern is if it will has some impacts on horizontally
 scalability.

 2. another implement is put all tasks in a thread, this thread will run all
 tasks(for bay,k8s, docker etc), just like sahara does see [2]

 3 last one is start a new service in a separate process to run tasks.( I
 think this
 will be too heavy/wasteful)

 I'd like to get what's your suggestion, thanks in advance.

 [1] https://review.openstack.org/#/c/187090/4
 [2]
 https://github.com/openstack/sahara/blob/master/sahara/service/periodic.py#L118

  --

 BR, Eli(Li Yong)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