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 know
:12 AM, Paul Belanger
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 the node. I
> have a
> > q
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 cr
+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 reviews have been extremely
erly setup such that the amphora-agent can
> be reached.
>
> Michael
>
>
> On Sun, May 22, 2016 at 8:31 PM, 王华 wrote:
> > 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 prob
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
http://logs.openstack.org/60/314060/5/ch
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 i
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,
Wang
+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 Mail
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.
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
i
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 Mail
nk we
> should leave things the way they are today.
>
> Corey
>
> On Fri, Feb 26, 2016, 22:08 王华 wrote:
>
>> Hi all,
>>
>> I want to allow magnum-api to access DB, so that magnum-api can work even
>> if magnum-conductor is down.
>>
>> Best Reg
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, 王华 wrote:
> I think we should allow magnum-api to access DB directly like nova-api.
>
> As describe in [1], nova may
Hi all,
Should we add some operational function for COE in Magnum? For example,
collect logs, upgrade COE and modify COE configuration. I think these
features are very important in production.
Regards,
Wanghua
__
OpenStack De
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
exampl
st, 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 王华 wrote:
>
>> Hi all,
>>
>> Magnum now use a token to get CA certificate in make-cert.sh. Token has a
>> expiration time.
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 a
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 method.
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 that
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: %(exception)s '
>
>
+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@lists.opens
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 Magn
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 kuryr service without roo
ances.
> 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 ba
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
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.
er 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, 王华 wrote:
>
> Adrian,
>
> When the docker daemon starts, it
n Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
>
> ----
> Follow your heart. You are miracle!
>
> 王华 ---07/12/2015 10:10:38 am---Hi all, If we want to run
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 products (e.g. Calico or Wea
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
>
> > On Dec 1, 2015, at 6:15 PM,
t; 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 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 and
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 files
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 have
@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 fo
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,
>
> Adrian
>
> On Sep 28, 2015, at 8
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 sc
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 etcd
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
Rega
at 9:36 AM, 王华 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 which is
> a
ing to
ENV['keystone.token_auth']. I think it is a common case which service wants
to reuse user token to do something like getting service_catalog. Can
keystoneclient provide this feature?
Regards,
Wanghua
On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox
wrote:
>
>
> - Origina
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 service_ca
any comments on this?
On Fri, Sep 4, 2015 at 9:43 AM, 王华 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.
>
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)
Unsu
Hi Clint Byrum,
Trusts can solve this problem, but it may cause performance problem.
When we want to get a stack, we need to get the trust_id from db first, and
authenticate with the trust_id, then we can get the stack.
On Fri, Aug 14, 2015 at 5:13 PM, Clint Byrum wrote:
> Excerpts from 王
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 wrote:
>
>
>
> > We ca
This option can not be used in "show stack" call.
Regards,
Wanghua
On Fri, Aug 14, 2015 at 4:54 PM, 英哲 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
> > Subject
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 wrote:
>
>
> > Hi all,
> >
> > Magnum creates a stack when a bay is created and update
tively has no expiry.
>
> --
> Adrian
>
> On Aug 13, 2015, at 7:36 PM, 王华 wrote:
>
> Will the scoped swift trust token time out?
>
> Regards,
> Wanghua
>
> On Fri, Aug 14, 2015 at 10:11 AM, Adrian Otto
> wrote:
>
>> Keystone v3 trusts can be scoped
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 te
oud-init.
>
> --
> Adrian
>
> On Aug 13, 2015, at 6:46 PM, 王华 wrote:
>
> Hi hongbin,
> I have comments in line.
>
> Thank you.
>
> Regards,
> Wanghua
>
> On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu wrote:
>
>> Hi Wanghua,
>>
>>
t;
>
>
> [1] https://review.openstack.org/#/c/186617/
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* 王华 [mailto:wanghua.hum...@gmail.com]
> *Sent:* August-13-15 4:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject
are 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 王华 ---08/13/2015 03:32
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
k...@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 yo
any comments on this?
On Wed, Aug 12, 2015 at 2:50 PM, 王华 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 operat
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.
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
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 has
60 matches
Mail list logo
