Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

: [openstack-dev] [magnum] Nesting /containers resource under /bays What are the reasons for keeping /containers? On Fri, Jan 15, 2016 at 9:14 PM, Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote: Disagree. If the container managing part is removed, Magnum i

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

ards, > > Hongbin > > > > *From:* Mike Metral [mailto:mike.met...@rackspace.com] > *Sent:* January-15-16 6:24 PM > *To:* openstack-dev@lists.openstack.org > > *Subject:* Re: [openstack-dev] [magnum] Nesting /containers resource > under /bays > > > > I too believe

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

and requests sent to the /container endpoint will return a reasonable error code. Thoughts? Best regards, Hongbin From: Mike Metral [mailto:mike.met...@rackspace.com] Sent: January-15-16 6:24 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum] Nesting /containers resource

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

- Rackspace From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>> Sent: Thursday, January 14, 2016 1:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resour

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

nstack-dev] [magnum] Nesting /containers resource under /bays On 01/13/2016 04:42 AM, Jamie Hannaford wrote: > I've recently been gathering feedback about the Magnum API and one of > the things that people commented on​ was the global /containers > endpoints. One person highlig

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

area until these are put into further use. From: Hongbin Lu <hongbin...@huawei.com> Sent: Wednesday, January 13, 2016 5:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource u

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

through Magnum’s endpoints. Hope it is clear. Best regards, Hongbin From: Kyle Kelley [mailto:kyle.kel...@rackspace.com] Sent: January-14-16 11:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

[openstack-dev] [magnum] Nesting /containers resource under /bays

I've recently been gathering feedback about the Magnum API and one of the things that people commented on? was the global /containers endpoints. One person highlighted the danger of UUID collisions: """ It takes a container ID which is intended to be unique within that individual cluster.

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

On 01/13/2016 04:42 AM, Jamie Hannaford wrote: I've recently been gathering feedback about the Magnum API and one of the things that people commented on​ was the global /containers endpoints. One person highlighted the danger of UUID collisions: """ It takes a container ID which is intended

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

have a bay on creation, such feature is impossible. Best regards, Hongbin From: Jamie Hannaford [mailto:jamie.hannaf...@rackspace.com] Sent: January-13-16 4:43 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] Nesting /containers resource under /bays I've recently been

[openstack-dev] [magnum] Planning Magnum Midcycle

Team, We are planning a mid cycle meetup for the Magnum team to be held in the San Francisco Bay area. If you would like to attend, please take a moment to respond to this poll to select the date: http://doodle.com/poll/k8iidtamnkwqe3hd Thanks, Adrian

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

penstack.org/#/c/264998/ Best regards, Hongbin -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: January-07-16 10:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from g

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

Done: https://review.openstack.org/#/c/264998/ Best regards, Hongbin -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: January-07-16 10:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Temporarily

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

[mailto:cboy...@sapwetik.org] Sent: January-07-16 6:04 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate On Thu, Jan 7, 2016, at 02:59 PM, Hongbin Lu wrote: > Hi folks, > > It looks the swarm func test is

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

On Thu, Jan 7, 2016, at 02:59 PM, Hongbin Lu wrote: > Hi folks, > > It looks the swarm func test is currently unstable, which negatively > impacts the patch submission workflow. I proposed to remove it from > Jenkins gate (but keep it in Jenkins check), until it becomes stable. > Please find the

[openstack-dev] [Magnum] Networking Subteam Update

All, Today the Magnum networking subteam decided to merge back into the general Magnum community. I would like to thank all who participated in the subteam over the past 6 months. We were able to develop and implement the Magnum Container Networking Model [1]. I look forward to additional

[openstack-dev] [magnum] Temporarily remove swarm func test from gate

Hi folks, It looks the swarm func test is currently unstable, which negatively impacts the patch submission workflow. I proposed to remove it from Jenkins gate (but keep it in Jenkins check), until it becomes stable. Please find the details in the review

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

-Original Message- > From: Clark Boylan [mailto:cboy...@sapwetik.org] > Sent: January-07-16 6:04 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from > gate > > On Thu, Jan 7, 2016, at 02:59 PM

[openstack-dev] [magnum] Mesos Conductor patch for review

Hi,As per the discussion in [1], I have pushed patchset [1]. Can you please review the patch. I want to take comments on this patch before I push test cases and container-list operation because there was a discussion on this topic whether to have this or not. (from my previous experience :) ).

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

rom: Adrian Otto <adrian.o...@rackspace.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: 17/12/2015 07:00 am > Subject: Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs > >

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

t;> From: Adrian Otto <adrian.o...@rackspace.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Monday, December 7, 2015 at 1:16 PM >> To: "OpenStack Development Ma

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

ons)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, December 7, 2015 at 1:16 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Re: [openstack-dev] [magnum] Magnum conductor async container operations

SURO wrote: Josh, Please find my reply inline. Regards, SURO irc//freenode: suro-patz On 12/16/15 6:37 PM, Joshua Harlow wrote: SURO wrote: Hi all, Please review and provide feedback on the following design proposal for implementing the blueprint[1] on async-container-operations - 1.

[openstack-dev] [Magnum][Kuryr] Help with using docker-python client in gate

Hello Everyone, We are trying to add some gate testing for Kuryr and hopefully convert these also to Rally plugins. What i am facing in the gate right now is this: I configure the docker client: self.docker_client = docker.Client( base_url='unix://var/run/docker.sock') And call this:

Re: [openstack-dev] [magnum] Magnum conductor async container operations

-dev] [magnum] Magnum conductor async container operations > On Dec 16, 2015, at 6:24 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > > SURO wrote: >> Hi all, >> Please review and provide feedback on the following design proposal >> for implementing th

Re: [openstack-dev] [Magnum][Kuryr] Help with using docker-python client in gate

Gal, I think you need to setup your Docker environment to allow run cli without sudo permission (https://docs.docker.com/engine/installation/ubuntulinux/). Or use tcp socket instead (https://docs.docker.com/v1.8/articles/basics/), Magnum/Swarm/docker-machine uses this approach all the time. —

Re: [openstack-dev] [magnum] Magnum conductor async container operations

drian Otto [mailto:adrian.o...@rackspace.com] Sent: December-16-15 10:20 PM To: OpenStack Development Mailing List (not for usage questions) Cc: s...@yahoo-inc.com Subject: Re: [openstack-dev] [magnum] Magnum conductor async container operations On Dec 16, 2015, at 6:24 PM, Joshua Harlow <harlo...

Re: [openstack-dev] [magnum] Magnum conductor async container operations

Josh, Thanks for bringing up this discussion. Modulo-hashing introduces a possibility for 'window of inconsistency', and to address the dynamism 'consistent hashing' is better. BUT, for the problem in hand I think modulo hashing is good enough, as number of worker instances for conductor in

Re: [openstack-dev] [magnum] Magnum conductor async container operations

Josh, You pointed out correct! magnum-conductor has monkey-patched code, so the underlying thread module is actually using greenthread. - I would use eventlet.greenthread explicitly, as that would enhance the readability - greenthread has a potential of not yielding by itself, if no i/o,

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

removed APIs. > >[1] >http://docs.openstack.org/developer/nova/api_microversions.html#removing-a >n-api-method > >Best regards, >Hongbin > >-Original Message- >From: Cammann, Tom [mailto:tom.camm...@hpe.com] >Sent: December-16-15 8:21 AM >To: OpenStack

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

ons.html#removing-a >> n-api-method >> >> Best regards, >> Hongbin >> >> -Original Message- >> From: Cammann, Tom [mailto:tom.camm...@hpe.com] >> Sent: December-16-15 8:21 AM >> To: OpenStack Development Mailing List (not for u

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

e questions)" <openstack-dev@lists.openstack.org> Date: 17/12/2015 07:00 am Subject: Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.camm...@hpe.com> wrote: > > I don’t see a benefi

Re: [openstack-dev] [magnum] Magnum conductor async container operations

Please find the reply inline. Regards, SURO irc//freenode: suro-patz On 12/16/15 7:19 PM, Adrian Otto wrote: On Dec 16, 2015, at 6:24 PM, Joshua Harlow wrote: SURO wrote: Hi all, Please review and provide feedback on the following design proposal for implementing the

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

n.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: 17/12/2015 07:00 am Subject: Re: [openstack-dev] [magnum] Removing

[openstack-dev] [magnum] Magnum conductor async container operations

Hi all, Please review and provide feedback on the following design proposal for implementing the blueprint[1] on async-container-operations - 1. Magnum-conductor would have a pool of threads for executing the container operations, viz. executor_threadpool. The size of the executor_threadpool

Re: [openstack-dev] [magnum] Magnum conductor async container operations

SURO wrote: Hi all, Please review and provide feedback on the following design proposal for implementing the blueprint[1] on async-container-operations - 1. Magnum-conductor would have a pool of threads for executing the container operations, viz. executor_threadpool. The size of the

Re: [openstack-dev] [magnum] Magnum conductor async container operations

> On Dec 16, 2015, at 6:24 PM, Joshua Harlow wrote: > > SURO wrote: >> Hi all, >> Please review and provide feedback on the following design proposal for >> implementing the blueprint[1] on async-container-operations - >> >> 1. Magnum-conductor would have a pool of

Re: [openstack-dev] [magnum] Magnum conductor async container operations

SURO wrote: Hi all, Please review and provide feedback on the following design proposal for implementing the blueprint[1] on async-container-operations - 1. Magnum-conductor would have a pool of threads for executing the container operations, viz. executor_threadpool. The size of the

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

for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Monday, December 7, 2015 at 1:16 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [magnum

Re: [openstack-dev] [magnum] Magnum conductor async container operations

On 12/16/15 11:39 PM, Joshua Harlow wrote: SURO wrote: Please find the reply inline. Regards, SURO irc//freenode: suro-patz On 12/16/15 7:19 PM, Adrian Otto wrote: On Dec 16, 2015, at 6:24 PM, Joshua Harlow wrote: SURO wrote: Hi all, Please review and provide

Re: [openstack-dev] [magnum] Magnum conductor async container operations

SURO wrote: Please find the reply inline. Regards, SURO irc//freenode: suro-patz On 12/16/15 7:19 PM, Adrian Otto wrote: On Dec 16, 2015, at 6:24 PM, Joshua Harlow wrote: SURO wrote: Hi all, Please review and provide feedback on the following design proposal for

Re: [openstack-dev] [magnum] Magnum conductor async container operations

Josh, Please find my reply inline. Regards, SURO irc//freenode: suro-patz On 12/16/15 6:37 PM, Joshua Harlow wrote: SURO wrote: Hi all, Please review and provide feedback on the following design proposal for implementing the blueprint[1] on async-container-operations - 1. Magnum-conductor

[openstack-dev] [magnum] Removing pod, rcs and service APIs

I have been noticing a fair amount of redundant work going on in magnum, python-magnumclient and magnum-ui with regards to APIs we have been intending to drop support for. During the Tokyo summit it was decided that we should support for only COE APIs that all COEs can support which means

Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs

#removing-an-api-method Best regards, Hongbin -Original Message- From: Cammann, Tom [mailto:tom.camm...@hpe.com] Sent: December-16-15 8:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum] Removing pod, rcs and service APIs I have been

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

onday, December 7, 2015 at 1:16 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap Until I see evidence to the contrar

[openstack-dev] [magnum] Containerize Flannel/Etcd

All, As a follow-on from today's networking subteam meeting, I received additional feedback from the Kubernetes community about running Etcd and Flannel in a container. Etcd/Flannel were containerized to simply the N different ways that these services can be deployed. It simplifies Kubernetes

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

07/12/2015 10:10 am Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap Hi all, If we want to run etcd and flannel in container, we will introduce docker-bootstrap which makes setup become more complex as Egor pointed out. Should we pay for the price? On Sat, Nov 28,

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

er 26, 2015 at 00:15 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>> Subject:

Re: [openstack-dev] [magnum] Mesos Conductor

: December-01-15 7:49 PM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [magnum] Mesos Conductor Hi, Sorry I was off for some days because of health issues. So I think the work items for this BP[1] are: 1)Add support to accept json file in container-create

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

ts.openstack.org > >> > Date: Thursday, November 26, 2015 at 00:15 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Subject: Re: [openstack-dev] [magn

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

On 11/28/2015 01:01 AM, Egor Guz wrote: Have you tested slave/agent inside container? I was under impression that it doesn’t work until somebody from Kolla team pointed me to the https://hub.docker.com/u/mesoscloud/. Also I belive you can try your approach without any changes at existing

Re: [openstack-dev] [magnum] Mesos Conductor

in magnum. I think we need approval for this BP and then implementation? >> >> [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor >> >> Regards >> Bharath T(tbh) >> >> >> ------ >> Date: Fri, 20 Nov 2015 0

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

Thanks team for stepping up to fill this important role. Please let me know if there is anything I can do to assist you. Adrian On Dec 2, 2015, at 2:19 PM, Everett Toews > wrote: On Dec 2, 2015, at 12:32 AM, 王华

Re: [openstack-dev] [magnum] Mesos Conductor

[1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor > > Regards > Bharath T(tbh) > > > -- > Date: Fri, 20 Nov 2015 07:44:49 +0800 > From: jay.lau....@gmail.com > To: openstack-dev@lists.openstack.org > > Subject: Re: [open

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

On Dec 2, 2015, at 12:32 AM, 王华 > wrote: 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

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

Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their

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

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, Qiao,Liyong wrote: > > hi Everett > I'd like to take it. > > thanks > Eli. > >> On 2015年12月02日 05:18,

Re: [openstack-dev] [magnum] Mesos Conductor

@lists.openstack.org Subject: Re: [openstack-dev] [magnum] Mesos Conductor It's great that we come to some agreement on unifying the client call ;-) As i proposed in previous thread, I think that "magnum app-create" may be better than "magnum create", I want to use "magnum a

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

hi Everett I'd like to take it. thanks Eli. On 2015年12月02日 05:18, Everett Toews wrote: Hello Magnumites, The API Working Group [1] is looking for a Cross-Project Liaison [2] from the Magnum project. What does such a role entail? The API Working Group seeks API subject matter experts for

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

Adrian, If need more than one alternates, I would like to be that. Thanks & Best Regards Hou Ming Wang On Wed, Dec 2, 2015 at 2:32 PM, 王华 wrote: > Adrian, > I would like to be an alternate. > > Regards > Wanghua > > > On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto

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

[openstack-dev] [Magnum] Networking Subteam Meeting

All, I will be on leave this Thursday and will be unable to chair the Networking Subteam meeting. Please respond if you would like to chair the meeting. Otherwise, we will not have a meeting this week and pick things back up on 12/10. Regards, Daneyon Hansen

Re: [openstack-dev] [Magnum] Liberty RPMs for RDO

Hello Mathieu, On Mon, Nov 30, 2015 at 4:48 PM, Alan Pevec wrote: > Hi Mathieu, > > 2015-11-30 10:54 GMT+01:00 Mathieu Velten : > > Hi, > > > > Let me first introduce myself : I am currently working at CERN to help > > evaluate and deploy Magnum. > > >

[openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this?

Hi All, I'm working on API related enhancement and encountered the following issue: bay-creation return 400 Bad Request with a valid fixed-network in baymodel( https://bugs.launchpad.net/magnum/+bug/1519748 ) The 'fixed_network' actually means 'fixed_network_cidr', or more precisely

Re: [openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this?

ang...@gmail.com> To: openstack-dev@lists.openstack.org Date: 01/12/2015 05:49 pm Subject: [openstack-dev] [Magnum] 'fixed_network' actually means 'fixed_subnet'. Which way is better to fix this? Hi All, I'm working on API related enhancement and encountered  the fol

[openstack-dev] [Magnum] Liberty RPMs for RDO

Hi, Let me first introduce myself : I am currently working at CERN to help evaluate and deploy Magnum. In this regard Ricardo recently sends an email regarding Puppet modules, this one is about RPMs of Magnum for CentOS with RDO. You can find here a repository containing the source and binary

Re: [openstack-dev] [magnum] Autoscaling both clusters and containers

Ryan, That's where Hyper could help. This blog talks about wasted capacity issue and the solution: http://thenewstack.io/hypernetes-brings-multi-tenancy-microservices/ Best Peng - Hyper - Make VM run like Container On Wed, Nov 18, 2015 at

Re: [openstack-dev] [Magnum] Liberty RPMs for RDO

Hi Mathieu, 2015-11-30 10:54 GMT+01:00 Mathieu Velten : > Hi, > > Let me first introduce myself : I am currently working at CERN to help > evaluate and deploy Magnum. > > In this regard Ricardo recently sends an email regarding Puppet > modules, this one is about RPMs of

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

ing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [magnum] Using docker container to run COE daemons Hi, It is becoming more and more popular to use docker container run some applications, so what about leveraging this in Ma

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, November 26, 2015 at 16:02 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [mag

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

t 00:15 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap Hi Hongbin, The docker in master node stores data in /dev/m

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

Lau [mailto:jay.lau@gmail.com] > *Sent:* November-26-15 2:06 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [magnum] Using docker container to run COE > daemons > > > > Thanks Kai Qing, I filed a bp for mesos bay

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

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

/mesos-bay-with-coreos Best regards, Hongbin From: Jay Lau [mailto:jay.lau@gmail.com] Sent: November-26-15 2:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Using docker container to run COE daemons Thanks Kai Qing, I filed a bp

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

5:00 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [magnum]storage for docker-bootstrap Hi all, I am working on containerizing etcd and flannel. But

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

Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap From: 王华 <wanghua.hum...@gmail.com<mailto:wanghua.hum...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstac

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

stack.org> Date: 26/11/2015 07:15 am Subject: [openstack-dev] [magnum] Using docker container to run COE daemons Hi, It is becoming more and more popular to use docker container run some applications, so what about leveraging this in Magnum? What I want to do is that we

[openstack-dev] [magnum] Using docker container to run COE daemons

Hi, It is becoming more and more popular to use docker container run some applications, so what about leveraging this in Magnum? What I want to do is that we can put all COE daemons running in docker containers, because now Kubernetes, Mesos and Swarm support running in docker container and

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

r to use docker container]Jay Lau > ---26/11/2015 07:15:59 am---Hi, It is becoming more and more popular to use > docker container run some > > From: Jay Lau <jay.lau@gmail.com> > To: OpenStack Development Mailing List <openstack-dev@lists.op

Re: [openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client?

OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 25/11/2015 03:24 pm Subject:[openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client? hi all In Magnum code, we hardcode it as DEFAUL

[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

Re: [openstack-dev] [magnum-ui][magnum] Suggestions for Features/Improvements

Thanks Brad, just added a new item of "Enable end user create container objects via magnum-ui, such as creating pod, rc, service etc", it would be great if we can enable end user create some container applications via magnum UI, comments? Thanks! On Wed, Nov 25, 2015 at 1:15 AM, Bradley Jones

[openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client?

hi all In Magnum code, we hardcode it as DEFAULT_DOCKER_TIMEOUT = 10 This bring troubles in some bad networking environment (or bad performance swarm master) At least it doesn't work on our gate. Here is the test patch on gate https://review.openstack.org/249522 , I set it as 180 to make sure

Re: [openstack-dev] [Magnum] Why set DEFAULT_DOCKER_TIMEOUT = 10 in docker client?

Li Yong, At any rate, this should not be hardcoded. I agree that the default value should match the RPC timeout. Adrian > On Nov 24, 2015, at 11:23 PM, Qiao,Liyong wrote: > > hi all > In Magnum code, we hardcode it as DEFAULT_DOCKER_TIMEOUT = 10 > This bring troubles

[openstack-dev] [magnum-ui][magnum] Suggestions for Features/Improvements

We have started to compile a list of possible features/improvements for Magnum-UI. If you have any suggestions about what you would like to see in the plugin please leave them in the etherpad so we can prioritise what we are going to work on.

[openstack-dev] [Magnum]How do we support swarm master node HA

hi all, failed to set up swarm master HA cluster: here is my setup . 2 master and 1 node, and I put a LB in front of 2 master node(Round-Robin) I saw from swarm ha guide and get confirmed from swarm guys: /jimmyxian | elqiao: I'm here. :). Swarm does not support A-A. But can access the

[openstack-dev] [magnum] Networking Subteam Meeting

All, There will be no Networking Subteam meeting this week due to the Thanksgiving holiday. Regards, Daneyon Hansen Software Engineer Email: daneh...@cisco.com Phone: 303-718-0400 http://about.me/daneyon_hansen __ OpenStack

Re: [openstack-dev] [magnum] Issue on history of renamed file/folder

This is a defect with Github and should not affect our ability to fix defects and correct/refactor our code. git is a CLI tool not a GUI tool and should be treated as such. We should not be imposing restrictions on our developers because a 3rd party GUI does not fit our workflows. Tom On

Re: [openstack-dev] [magnum] Mesos Conductor

k.org> From: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com> Date: Thu, 19 Nov 2015 10:47:33 +0800 Subject: Re: [openstack-dev] [magnum] Mesos Conductor @bharath, 1) actually, if you mean use container-create(delete) to do on mesos bay for apps. I am not sure how different the interface between doc

Re: [openstack-dev] [magnum] Mesos Conductor

9, 2015 at 10:36 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > I’m open to allowing magnum to pa

Re: [openstack-dev] [magnum] Mesos Conductor

t for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor I’m open to allowing magnum to pass a blob of data (such as a lump of JSON or YAML) to the Bay's native API. That approach strikes a balance th

Re: [openstack-dev] [magnum] Mesos Conductor

: [openstack-dev] [magnum] Mesos Conductor @bharath, 1) actually, if you mean use container-create(delete) to do on mesos bay for apps. I am not sure how different the interface between docker interface and mesos interface. One point that when you introduce that feature, please not make docker container

Re: [openstack-dev] [magnum] Issue on history of renamed file/folder

As I see this, we need to pick the better of two options, even when neither is perfect. I’d rather have magnum’s source as intuitive and easy to maintain as possible. If it becomes more difficult to follow the commit history for a file in order to achieve that improvement, I’m willing to live

[openstack-dev] [magnum] Mesos Conductor

Hi all,I am working on the blueprint [1]. As per my understanding, we have two resources/objects in mesos+marathon:1)Apps: combination of instances/containers running on multiple hosts representing a service.[2]2)Application Groups: Group of apps, for example we can have database application

Re: [openstack-dev] [magnum] Mesos Conductor

m: bharath thiruveedula [mailto:bharath_...@hotmail.com] Sent: November-18-15 1:20 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] Mesos Conductor Hi all, I am working on the blueprint [<https://blueprints.launchpad.net/magnum/+spec/mesos-conductor>1]. As per my underst

Re: [openstack-dev] [magnum] Mesos Conductor

ou can point out a valid use case to wrap the API, I will give it more >> thoughts. >> > >> > Best regards, >> > Hongbin >> > >> > [1] https://docs.mesosphere.com/using/cli/marathonsyntax/ >> > >> > From: bharath thiruveedula [mailto:

Re: [openstack-dev] [magnum] Mesos Conductor

t; > Best regards, > Hongbin > > [1] https://docs.mesosphere.com/using/cli/marathonsyntax/ > > From: bharath thiruveedula [mailto:bharath_...@hotmail.com] > Sent: November-18-15 1:20 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [magnum] Me

Re: [openstack-dev] [magnum] Mesos Conductor

: [openstack-dev] [magnum] Mesos Conductor +1. One problem I want to mention is that for mesos integration, we cannot limited to Marathon + Mesos as there are many frameworks can run on top of Mesos, such as Chronos, Kubernetes etc, we may need to consider more for Mesos integration

Re: [openstack-dev] [magnum] Autoscaling both clusters andcontainers

gt; > From: Jay Lau <jay.lau@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: 11/17/2015 10:05 PM > Subject: Re: [openstack-dev] [magnum] Autoscaling both clusters and > containers >

Re: [openstack-dev] [magnum] Mesos Conductor

: bharath thiruveedula <bharath_...@hotmail.com> To: OpenStack Development Mailing List not for usage questions <openstack-dev@lists.openstack.org> Date: 19/11/2015 10:31 am Subject: Re: [openstack-dev] [magnum] Mesos Conductor @hongin, @adrian I agree with

<    4   5   6   7   8   9   10   11   12   13   >