[openstack-dev] [openstack-infra][project-config] how project config is updated

Hi all, After openstack-infra/project-config is updated, for example layout.yaml for zuul is changed, how the change is applied to the CI system? Is there a script to trigger this change? I don't find some scripts in the pipeline of project-config in the layout.yaml to do this work. Do anyone

Re: [openstack-dev] [openstack-infra][nodepool] Can the nodes created by nodepool be reused by jenkins jobs?

:12 AM, Paul Belanger <pabelan...@redhat.com> wrote: > On Thu, Jun 30, 2016 at 10:49:41AM +0800, 王华 wrote: > > Hi all, > > > > In OpenStack infra system after a job in Jenkins has finalized, Jenkins > > send a message called onFinalized to nodepool to delete

[openstack-dev] [openstack-infra][nodepool] Can the nodes created by nodepool be reused by jenkins jobs?

Hi all, In OpenStack infra system after a job in Jenkins has finalized, Jenkins send a message called onFinalized to nodepool to delete the node. I have a question. Between the time the job is done and the node is deleted by nodepool, will the node be reused by other jobs in jenkins? All nodes

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

+1 On Fri, Jun 10, 2016 at 5:32 PM, Shuu Mutou 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

Re: [openstack-dev] [Magnum][Octavia] Need help for LBaaS v2

ment network is properly setup such that the amphora-agent can > be reached. > > Michael > > > On Sun, May 22, 2016 at 8:31 PM, 王华 <wanghua.hum...@gmail.com> wrote: > > Hi all, > > > > Previously Magnum used LBaaS v1. Now LBaaS v1 is deprecated, so

[openstack-dev] [Magnum][Octavia] Need help for LBaaS v2

Hi all, Previously Magnum used LBaaS v1. Now LBaaS v1 is deprecated, so we want to replace it by LBaaS v2. But I met a problem in my patch https://review.openstack.org/#/c/314060/. I could not figure out why it didn't work. It seems there are some errors in

[openstack-dev] [Magnum]Cache docker images

Hi all, We want to eliminate pulling docker images over the Internet on bay provisioning. There are two problems of this approach: 1. Pulling docker images over the Internet is slow and fragile. 2. Some clouds don't have external Internet access. It is suggested to build all the required images

[openstack-dev] [Magnum] duplicate scripts in different coes

Hi all, There are some duplicate scripts in different coes now, for example scripts for tls and etcd. I think we should put them into a common function module. If there is some minor difference between the scripts in different coes, we can pass different parameters to these scripts. Regards,

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

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

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

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

I think users need the support for multiple OS choices. Users may want to modify the OS by themselves to meet the requirement of their business. If Magnum only supports a single OS distro, we should have a convenient way to change one OS distro to another. But the OSes are so different, the work

[openstack-dev] [openstack][keystone] What is the difference between auth_url and auth_uri?

Hi all, There are two config parameters (auth_uri and auth_url) in keystone_authtoken group. I want to know what is the difference between them. Can I use only one of them? Best Regards, Wanghua __ OpenStack Development

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

ades in the future. I think we > should leave things the way they are today. > > Corey > > On Fri, Feb 26, 2016, 22:08 王华 <wanghua.hum...@gmail.com> wrote: > >> Hi all, >> >> I want to allow magnum-api to access DB, so that magnum-api can work even

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

Hi all, I want to allow magnum-api to access DB, so that magnum-api can work even if magnum-conductor is down. Best Regards, Wanghua On Thu, Feb 4, 2016 at 3:42 PM, 王华 <wanghua.hum...@gmail.com> wrote: > I think we should allow magnum-api to access DB directly like nova-api. > &

Re: [openstack-dev] [magnum]swarm + compose = k8s?

I think master nodes should be controlled by Magnum, so that we can do the operation work for users. AWS and GCE use the mode. And master nodes are resource-consuming. If master nodes are not controlled by users, we can do some optimization to reduce the cost which is invisible to users. For

Re: [openstack-dev] [openstack][Magnum] ways to get CA certificate in make-cert.sh from Magnum

e already have the trust, that seems like the best way to proceed > for now just to get something working. > > Corey > > On Thu, Feb 4, 2016 at 10:53 PM 王华 <wanghua.hum...@gmail.com> wrote: > >> Hi all, >> >> Magnum now use a token to get CA certificate in

[openstack-dev] [openstack][Magnum] ways to get CA certificate in make-cert.sh from Magnum

Hi all, Magnum now use a token to get CA certificate in make-cert.sh. Token has a expiration time. So we should change this method. Here are two proposals. 1. Use trust which I have introduced in [1]. The way has a disadvantage. We can't limit the access to some APIs. For example, if we want to

Re: [openstack-dev] [Magnum] Remove time costing case from gate-functional-dsvm-magnum-api

Dimitry Ushakov, Heat wait condition has a timeout, now the default for it is 6000 in our Heat template. I think we can change it to a reasonable value. Regards， wanghua On Thu, Feb 4, 2016 at 12:38 PM, Dimitry Ushakov < dimitry.usha...@rackspace.com> wrote: > Eli, > > I’m ok with removing

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

I think we should allow magnum-api to access DB directly like nova-api. As describe in [1], nova may have many compute nodes and it may take an hour or a month to upgrade. But the number of magnum-api and magnum-conductor is limited, the upgrade of them is fast. They don't benefit from the

Re: [openstack-dev] Logging and traceback at same time.

You can use LOG.exception. Regards, Wanghua On Wed, Feb 3, 2016 at 2:28 PM, Khayam Gondal wrote: > Is there a way to do logging the information and traceback at the same > time. Currently I am doing it like this. > > > > > > LOG.error(_LE('Record already exists:

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

+1 for both. Welcome! On Tue, Feb 2, 2016 at 12:12 PM, Kumari, Madhuri wrote: > +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) <

[openstack-dev] [Magnum]Remove node object from Magnum

Hi all, I want to remove node object from Magnum. The node object represents either a bare metal or virtual machine node that is provisioned with an OS to run the containers, or alternatively, run kubernetes. Magnum use Heat to deploy the nodes, so it is unnecessary to maintain node object in

Re: [openstack-dev] [Kuryr] Starting Kuryr service requires root privilege

Hi Baohua, I think https://wiki.openstack.org/wiki/Rootwrap can solve this problem. It is used in other OpenStack projects like Nova, Neutron. Regards, Wanghua On Tue, Jan 26, 2016 at 1:07 PM, Baohua Yang wrote: > Hi toni > > Recently we found some issue when starting

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

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 王华 <wanghua.hum...@gmail.com>: > >> Hi all, >> >> I

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

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

[openstack-dev] [openstack][magnum]a problem about trust

Hi all, When we create a trust to a trustee with a role, the trustor must have this role. Here is a problem I meet in my bp [1]. I need to create a trust with a role, with the trust docker registry can access Swift to store images. But the trustor (the user who uses magnum) may not have the role.

Re: [openstack-dev] [magnum]storage for docker-bootstrap

ance can share a > single docker daemon? Would that work at all? I guess I’d need a better > understanding of exactly how the BIP and MTU are generated before judging > if this is a good idea. > > Adrian > > On Dec 16, 2015, at 11:40 PM, 王华 <wanghua.hum...@gmail.com> wrot

Re: [openstack-dev] [magnum]storage for docker-bootstrap

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! > &

Re: [openstack-dev] [magnum]storage for docker-bootstrap

h to another more “friendly” images > (e.g. Fedora/CentOS/Ubuntu) which we can easy build with disk builder. > Also we can fix CoreOS template (I believe people more asked about it > instead of Atomic), but we may face similar to Atomic issues when we will > try to integrate not CoreOS pro

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

Adrian, I would like to be an alternate. Regards Wanghua On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto wrote: > Everett, > > Thanks for reaching out. Eli is a good choice for this role. We should > also identify an alternate as well. > > Adrian > > -- > Adrian > > >

Re: [openstack-dev] [magnum]storage for docker-bootstrap

t; Best regards, > > Hongbin > > > > *From:* Daneyon Hansen (danehans) [mailto:daneh...@cisco.com] > *Sent:* November-25-15 11:10 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [magnum]storage for docke

[openstack-dev] [magnum]storage for docker-bootstrap

Hi all, I am working on containerizing etcd and flannel. But I met a problem. As described in [1], we need a docker-bootstrap. Docker and docker-bootstrap can not use the same storage, so we need some disk space for it. The docker in master node stores data in /dev/mapper/atomicos-docker--data

[openstack-dev] [magnum]generate config files by magnum

Hi forks, Magnum needs to prepare config files for k8s and docker and add these services to systemd. Now we use "sed" to replace some parameters in config files. The method has a disadvantage. Magnum code depends on a specific image. Users may want to create images by themselves. The config

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

Thanks everyone! It is my pleasure to be a magnum core reviewer. Let's make magnum better together. Thanks Wanghua On Wed, Oct 7, 2015 at 1:19 AM, Vilobh Meshram < vilobhmeshram.openst...@gmail.com> wrote: > Thanks everyone! > > I really appreciate this. Happy to join Magnum-Core :) > > We

Re: [openstack-dev] [magnum]swarm + compose = k8s?

eatures or > wait longer for us to implement each new feature as it is added. Keep in > mind that our pod, service, and replication controller resources pre-date > this philosophy. If we started out with the current approach, those would > not exist in Magnum. > > Thanks, > >

Re: [openstack-dev] [magnum]swarm + compose = k8s?

@Egor, docker compose is just a command line tool now, but I think it will change its architecture to Client and Server in the future, otherwise it can not do some complicate jobs. __ OpenStack Development Mailing List (not

[openstack-dev] [magnum]swarm + compose = k8s?

Hi folks, Magnum now exposes service, pod, etc to users in kubernetes coe, but exposes container in swarm coe. As I know, swarm is only a scheduler of container, which is like nova in openstack. Docker compose is a orchestration program which is like heat in openstack. k8s is the combination of

Re: [openstack-dev] [magnum] Handling password for k8s

I think it is the same case in docker registry v2. User credentials are needed in docker registry v2 config file. We can use the same user in all bays, but different trust[1] to it. The user should have no role, it can only work with trust. [1] https://wiki.openstack.org/wiki/Keystone/Trusts

Re: [openstack-dev] [magnum] Discovery

Swarm already supports etcd as a discovery backend [1]. So we can implement both hosted discovery with Docker Hub and using name etcd. And make hosted discovery with Docker Hub default if discovery_url is not given. If we run etcd in bay, etcd alse need discovery [2]. Operator should set up a

Re: [openstack-dev] [keystone]how to get service_catalog

:36 AM, 王华 <wanghua.hum...@gmail.com> wrote: > Hi Jamie, > > We want to reuse the user token in magnum. But there is no convenient way > to reuse it. It is better that we can use ENV['keystone.token_auth'] to > init keystoneclient directly. Now we need to construct a auth_ref w

Re: [openstack-dev] [keystone]how to get service_catalog

riginal Message ----- > > From: "王华" <wanghua.hum...@gmail.com> > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > Sent: Monday, 7 September, 2015 12:00:43 PM > > Su

[openstack-dev] [keystone]how to get service_catalog

Hi all, When I use a token to init a keystoneclient and try to get service_catalog by it, error occurs. I find that keystone doesn't return service_catalog when we use a token. Is there a way to get service_catalog by token? In magnum, we now make a trick. We init a keystoneclient with

Re: [openstack-dev] [magnum]keystone version

any comments on this? On Fri, Sep 4, 2015 at 9:43 AM, 王华 <wanghua.hum...@gmail.com> wrote: > Hi all, > > Now the keystoneclient in magnum only support keystone v3. Is is necessary > to support keystone v2? Keystone v2 don't support trust. >

[openstack-dev] [magnum]keystone version

Hi all, Now the keystoneclient in magnum only support keystone v3. Is is necessary to support keystone v2? Keystone v2 don't support trust. Regards, Wanghua __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

This option can not be used in show stack call. Regards, Wanghua On Fri, Aug 14, 2015 at 4:54 PM, 英哲 zengyz1...@live.cn wrote: Can this option be used for in show stack details call? Date: Fri, 14 Aug 2015 04:30:19 -0400 From: the...@redhat.com To: openstack-dev@lists.openstack.org

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

Magnum creates a stack when a bay is created and update the stack parameters when the bay is updated. Magnum needs a periodic task to synchronize stack status and parameters from heat to keep data consistency. Regards, Wanghua On Fri, Aug 14, 2015 at 5:02 PM, Thomas Herve the...@redhat.com

[openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

Hi all, Magnum creates a stack when a bay is created and update the stack parameters when the bay is updated. Magnum has a periodic task to synchronize stack status from heat. And now we want to synchronize stack parameters from heat, too. But heat don't allow admin user to show stack in other

Re: [openstack-dev] [magnum]password for registry v2

one that effectively has no expiry. -- Adrian On Aug 13, 2015, at 7:36 PM, 王华 wanghua.hum...@gmail.com wrote: Will the scoped swift trust token time out? Regards, Wanghua On Fri, Aug 14, 2015 at 10:11 AM, Adrian Otto adrian.o...@rackspace.com wrote: Keystone v3 trusts can be scoped

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

We can get stacks by stack list call, but it does not provide info about stack parameters. If we need stack parameters, we have to use stack.get. Regards, Wanghua On Fri, Aug 14, 2015 at 4:30 PM, Thomas Herve the...@redhat.com wrote: Hi all, Magnum creates a stack when a bay is created

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

: Excerpts from 王华's message of 2015-08-14 00:52:43 -0700: Hi all, Magnum creates a stack when a bay is created and update the stack parameters when the bay is updated. Magnum has a periodic task to synchronize stack status from heat. And now we want to synchronize stack parameters from heat

[openstack-dev] [magnum]password for registry v2

Hi all, In order to add registry v2 to bay nodes[1], authentication information is needed for the registry to upload and download files from swift. The swift storage-driver in registry now needs the parameters as described in [2]. User password is needed. How can we get the password? 1. Let user

Re: [openstack-dev] [magnum]problems for horizontal scale

Follow your heart. You are miracle! [image: Inactive hide details for 王华 ---08/13/2015 11:31:53 AM---any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wan]王华 ---08/13/2015 11:31:53 AM---any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wanghua.hum

Re: [openstack-dev] [magnum]problems for horizontal scale

, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! [image: Inactive hide details for 王华 ---08/13/2015 03:32:53 PM---Hi Kai Qiang Wu, I have some comments in line.]王华 ---08/13/2015 03:32

Re: [openstack-dev] [magnum]password for registry v2

can take a snapshot of the VM and boot another VM from the snapshot. Maybe storing a scoped credential in the config file could mitigate the security risk. Not sure if there is a better solution. [1] https://review.openstack.org/#/c/186617/ Best regards, Hongbin *From:* 王华

Re: [openstack-dev] [magnum]password for registry v2

On Aug 13, 2015, at 6:46 PM, 王华 wanghua.hum...@gmail.com wrote: Hi hongbin, I have comments in line. Thank you. Regards, Wanghua On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu hongbin...@huawei.com wrote: Hi Wanghua, For the question about how to pass user password to bay nodes

Re: [openstack-dev] [magnum]problems for horizontal scale

any comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 wanghua.hum...@gmail.com wrote: Hi All, In order to prevent race conditions due to multiple conductors, my solution is as blew: 1. remove the db operation in bay_update to prevent race conditions.Stack operation is atomic. Db

[openstack-dev] [magnum]problems for horizontal scale

Hi All, In order to prevent race conditions due to multiple conductors, my solution is as blew: 1. remove the db operation in bay_update to prevent race conditions.Stack operation is atomic. Db operation is atomic. But the two operations together are not atomic.So the data in the db may be wrong.

[openstack-dev] [Magnum]horizontal scalability

Hi all, As discussed in the Vancouver Summit, we are going to drop the bay lock implementation. Instead, each conductor will call Heat concurrently and rely on heat for concurrency control. However, I think we need an approach for state convergence from heat to magnum. Either periodic task [1] or

[openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

Hi, all. Currently magnum-conductor can communicates with k8s master which has a floating ip in all-in-one deployment. But if magnum-conductor is not deployed on the neutron network node which has the br-ex, how can magnum-conductor communicate with k8s master. The magnum-conductor node then