[openstack-dev] [election] [tc] TC Candidacy

nd I look forward to the honor of serving you well. Thanks, Adrian Otto [1] https://review.openstack.org/454908 [2] https://docs.openstack.org/developer/magnum/policies.html __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

oud >> and they will be wanting to use the magnum service. So, it only make sense >> to type openstack magnum cluster or mcluster which is shorter. >> >> >> On 21 March 2017 at 02:24, Qiming Teng wrote: >>> >>> On Mon, Mar 20, 2017 at 03:35:18PM -0400, Jay

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

Clint, On Mar 20, 2017, at 3:02 PM, Clint Byrum mailto:cl...@fewbar.com>> wrote: Excerpts from Adrian Otto's message of 2017-03-20 21:16:09 +: Jay, On Mar 20, 2017, at 12:35 PM, Jay Pipes mailto:jaypi...@gmail.com><mailto:jaypi...@gmail.com>> wrote: On 03/20/201

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

Dean, Thanks for your reply. > On Mar 20, 2017, at 2:18 PM, Dean Troyer wrote: > > On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto > wrote: >> the argument is actually the service name, such as “ec2”. This is >> the same way the openstack cli works. Perhaps there

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

Jay, On Mar 20, 2017, at 12:35 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On 03/20/2017 03:08 PM, Adrian Otto wrote: Team, Stephen Watson has been working on an magnum feature to add magnum commands to the openstack client by implementing a plugin: https://review.openstack.o

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

ack.org >> Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum >> commands in osc? >> >> On 03/20/2017 03:08 PM, Adrian Otto wrote: >>> Team, >>> >>> Stephen Watson has been working on an magnum feature to add m

Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

Kevin, I added that to the list for consideration.Feel free to add others to the list on the team agenda using our Wiki page. Adrian > On Mar 20, 2017, at 12:27 PM, Fox, Kevin M wrote: > > What about coe? > > Thanks, > Kevin > ___

[openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

Team, Stephen Watson has been working on an magnum feature to add magnum commands to the openstack client by implementing a plugin: https://review.openstack.org/#/q/status:open+project:openstack/python-magnumclient+osc In review of this work, a question has resurfaced, as to what the client co

Re: [openstack-dev] [containers][magnum] Make certs insecure in magnum drivers

I have opened the following bug ticket for this issue: https://bugs.launchpad.net/magnum/+bug/1663757 Regards, Adrian On Feb 10, 2017, at 1:46 PM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: What I’d like to see in this case is to use secure connections by default, and t

Re: [openstack-dev] [containers][magnum] Make certs insecure in magnum drivers

What I’d like to see in this case is to use secure connections by default, and to make workarounds for self signed certificates or other optional workarounds for those who need them. I would have voted against patch set 383493. It’s also not linked to a bug ticket, which we normally require prio

Re: [openstack-dev] [requirements] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

I voted to merge [1] and [2]: [1] https://review.openstack.org/#/c/429753/ [2] https://review.openstack.org/#/c/430941/ FFE approved for Magnum, provided this does not cause problems for other projects. Adrian On Feb 8, 2017, at 7:25 AM, Adrian Otto mailto:adrian.o...@rackspace.com>>

Re: [openstack-dev] [requirements] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

We are actively working to verify that magnum-ui works with the adjusted requirements.txt, and as soon as we have confirmed this change is non-disruptive, I will be ready to approve the FFE. Adrian > On Feb 7, 2017, at 4:54 PM, Richard Jones wrote: > > It looks like Magnum-UI only has one xst

[openstack-dev] [magnum] PTL Candidacy for Pike

, because I want Magnum to be my primary focus. I look forward to your vote, and continued success together. Thanks, Adrian Otto __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

[openstack-dev] [Magnum] Feature freeze coming today

Team, I will be starting our feature freeze today. We have a few more patches to consider for merge before we enter the freeze. I’ll let you all know when each has been considered, and we are ready to begin the freeze. Thanks, Adrian

Re: [openstack-dev] [containers][magnum] Magnum team at Summit?

he PTG. This might give us a chance to source further input from a wider audience than our PTG attendees. Thoughts? Thanks, Adrian On 18 Jan 2017 8:36 p.m., "Adrian Otto" mailto:adrian.o...@rackspace.com>> wrote: Josh, > On Jan 18, 2017, at 10:18 AM, Josh Berkus > mailt

Re: [openstack-dev] [containers][magnum] Magnum team at Summit?

Josh, > On Jan 18, 2017, at 10:18 AM, Josh Berkus wrote: > > Magnum Devs: > > Is there going to be a magnum team meeting around OpenStack Summit in > Boston? > > I'm the community manager for Atomic Host, so if you're going to have > Magnum meetings, I'd like to send you some Atomic engineers

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) > wrote: > > On 1/16/17, 11:52 AM, "Ian Cordasco" wrote: > >> -Original Message- >> From: Rob C >> Reply: OpenStack Development Mailing List (not for usage questions) >> >> Date: January 16, 2017 at 10:33:20 >> To: OpenStack De

Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages

Team, We discussed this in today’s team meeting: http://eavesdrop.openstack.org/meetings/containers/2017/containers.2017-01-03-16.00.html Our consensus was to start iterating on this in-tree and break it out later into a separate repo once we have reasonably mature drivers, and/or further guid

Re: [openstack-dev] [Congress] Magnum_driver

Ruben, I found the following two reviews: https://review.openstack.org/397150 Magnum_driver for congress https://review.openstack.org/397151 Test for magnum_driver Are these what you are referring to, or is it something else? Thanks, Adrian > On Nov 14, 2016, at 4:13 AM, Ruben wrote: > > H

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

Jaycen and Yatin, You have each been added as new core reviewers. Congratulations to you both, and thanks for stepping up to take on this new role! Cheers, Adrian > On Nov 7, 2016, at 11:06 AM, Adrian Otto wrote: > > Magnum Core Team, > > I propose Jaycen Grant (jvgrant)

[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

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

Thank Doug for organizing this. In our session, I mentioned that Magnum is working through some of the issues now, and will touch on a portion of these concerns in one of our sessions: Thursday, October 27, 2:40pm-3:20pm CCIB - P1 - Room 124/125

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

I plan to attend, but may be a few minutes late. Apologies in advance. Adrian > On Oct 24, 2016, at 8:23 PM, Doug Wiegley > wrote: > > As part of a requirements mailing list thread [1], the idea of a servicevm > working group, or a common framework for reference openstack service VMs, > came

[openstack-dev] [Magnum] Magnum Sessions for Barcelona Summit Attendees

016/summit-schedule/global-search?t=Magnum:> If there are any additional topics you would like to cover with the team, please add them to our Friday afternoon meetup: https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17216 Thanks, Adria

[openstack-dev] [Magnum] PTL Candidacy

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

Re: [openstack-dev] [tc] persistently single-vendor projects

I am struggling to understand why we would want to remove projects from our big tent at all, as long as they are being actively developed under the principles of "four opens". It seems to me that working to disqualify such projects sends an alarming signal to our ecosystem. The reason we made th

Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun] nova-docker alternatives ?

s/mentally/centrally/ Autocorrect is not my friend. On Jul 29, 2016, at 11:26 AM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Yasmin, One option you have is to use the libvirt-lxc nova virt driver, and use an image that has a docker daemon installed on it. That would give you

Re: [openstack-dev] [nova] [container] [docker] [magnum] [zun] nova-docker alternatives ?

Yasmin, One option you have is to use the libvirt-lxc nova virt driver, and use an image that has a docker daemon installed on it. That would give you a way to place docker containers on a data plane the uses no virtualization, but you need to individually manage each instance. Another option i

Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

On Jul 27, 2016, at 1:26 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Here is the guideline to evaluate an API change: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html . In particular, I highlight the followings: """ The following types of changes are

Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

On Jul 27, 2016, at 1:26 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Here is the guideline to evaluate an API change: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html . In particular, I highlight the followings: """ The following types of changes are

Re: [openstack-dev] [Magnum] Select our project mascot/logo

How about a shark? Something along these lines: http://www.logoground.com/logo.php?id=10554 On Jul 25, 2016, at 3:54 PM, Hongbin Lu wrote: Hi team, OpenStack want to promote individual projects by choosing a mascot to represent the project. The idea is to create a family of logos for OpenSt

Re: [openstack-dev] [magnum] Proposing Spyros Trigazis for Magnum core reviewer team

+1 -- Adrian On Jul 22, 2016, at 10:28 AM, Hongbin Lu mailto:hongbin...@huawei.com>> 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.

Re: [openstack-dev] Quesion about Openstack Magnum

Wally, We can help you by IRC in #openstack-containers on Freenode. I see you’re in there getting help now. This mailing list is for development discussion, so we’ll end this thread, and engage with you on IRC instead. Thanks, Adrian On Jul 5, 2016, at 11:47 AM, zhihao wang mailto:wangzhihao

Re: [openstack-dev] [Magnum] The Magnum Midcycle

Rackspace is willing to host in Austin, TX or San Antonio, TX, or San Francisco, CA. -- Adrian On Jun 7, 2016, at 1:35 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Hi all, Please find the Doodle pool below for selecting the Magnum midcycle date. Presumably, it will be a 2 days event.

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

I am really struggling to accept the idea of heterogeneous clusters. My experience causes me to question whether a heterogeneus cluster makes sense for Magnum. I will try to explain why I have this hesitation: 1) If you have a heterogeneous cluster, it suggests that you are using external intel

Re: [openstack-dev] [magnum][lbaas] Operator-facing installation guide

Brandon, Magnum uses neutron’s LBaaS service to allow for multi-master bays. We can balance connections between multiple kubernetes masters, for example. It’s not needed for single master bays, which are much more common. We have a blueprint that is in design stage for de-coupling magnum from n

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

> On May 25, 2016, at 12:43 PM, Ben Swartzlander wrote: > > On 05/25/2016 06:48 AM, Sean Dague wrote: >> I've been watching the threads, trying to digest, and find the way's >> this is getting sliced doesn't quite slice the way I've been thinking >> about it. (which might just means I've been th

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

> On May 24, 2016, at 12:09 PM, Mike Perez wrote: > > On 12:24 May 24, Thierry Carrez wrote: >> Morgan Fainberg wrote: >>> [...] If we are accepting golang, I want it to be clearly >>> documented that the expectation is it is used exclusively where there is >>> a demonstrable case (such as with

Re: [openstack-dev] [higgins] Should we rename "Higgins"?

Before considering a project rename.m, I suggest you seek guidance from the OpenStack technical committee, and/or the OpenStack-infra team. There is probably a simple workaround to the concern voiced below. -- Adrian > On May 24, 2016, at 1:37 AM, Shuu Mutou wrote: > > Hi all, > > Unfortunat

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

> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) wrote: > > Tom, > > Devil's advocate here.. :) > > Can you offer examples of other OpenStack API services which behave in > this way with a API? The more common pattern is actually: or: Examples: # trove resize-instance # n

[openstack-dev] [magnum] Proposed Revision to Magnum's Mission

Magnum Team, In accordance with our Fishbowl discussion yesterday at the Newton Design Summit in Austin, I have proposed the following revision to Magnum’s mission statement: https://review.openstack.org/311476 The idea is to narrow the scope of our Magnum project to allow us to focus on maki

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

com>> wrote: >Thierry Carrez wrote: >> Adrian Otto wrote: >>> This pursuit is a trap. Magnum should focus on making native container >>> APIs available. We should not wrap APIs with leaky abstractions. The >>> lowest common denominator of all COEs is an remarkab

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> On Apr 20, 2016, at 2:49 PM, Joshua Harlow wrote: > > Thierry Carrez wrote: >> Adrian Otto wrote: >>> This pursuit is a trap. Magnum should focus on making native container >>> APIs available. We should not wrap APIs with leaky abstractions. The >>> l

Re: [openstack-dev] [Magnum]Cache docker images

Hongbin, Both of approaches you suggested may only work for one binary format. If you try to use docker on a different system architecture, the pre-cache of images makes it even more difficult to get the correct images built and loaded. I suggest we take an approach that allows the Baymodel cre

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

ce I heard agreements and >> disagreements from different people. It would be great if all of you >> can join the session and share your opinions and use cases. I wish we >> will have a productive discussion. >> >> Best regards, >> Hongbin >> >>>

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Please don't miss the point here. We are seeking a solution that allows a location to place a client side encrypted blob of data (A TLS cert) that multiple magnum-conductor processes on different hosts can reach over the network. We *already* support using Barbican for this purpose, as well as

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

design summit to discuss it as a team. Best regards, Hongbin From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: April-11-16 12:54 PM To: OpenStack Development Mailing List (not for usage questions) Cc: foundat...@lists.openstack.org<mailto:foundat...@lists.openstack.org> Subject: Re

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Amrith, I respect your point of view, and agree that the idea of a common compute API is attractive… until you think a bit deeper about what that would mean. We seriously considered a “global” compute API at the time we were first contemplating Magnum. However, what we came to learn through the

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

On Apr 8, 2016, at 3:15 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Hi team, I would like to give an update for this thread. In the last team, we discussed several options to introduce Chronos to our mesos bay: 1. Add Chronos to the mesos bay. With this option, the mesos bay will

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

+1 On Mar 31, 2016, at 11:18 AM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: 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. Hi

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

+1 On Mar 31, 2016, at 11:18 AM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: 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. Hi

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

r sites fro upstream? Thanks -steve On 3/29/16, 11:02 AM, "Adrian Otto" mailto:adrian.o...@rackspace.com>> wrote: Steve, I¹m very interested in having an image locally cached in glance in each of the clouds used by OpenStack infra. The local caching of the glance images will produ

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

Steve, I’m very interested in having an image locally cached in glance in each of the clouds used by OpenStack infra. The local caching of the glance images will produce much faster gate testing times. I don’t care about how the images are built, but we really do care about the performance outc

Re: [openstack-dev] [containers][horizon][magnum-ui] - Stable version for Liberty?

Marcos, Great question. The current intent is to backport security fixes and critical bugs, and to focus on master for new feature development. Although we would love to expand scope to backport functionality, I’m not sure it’s realistic without an increased level of commitment from that group

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

> On Mar 24, 2016, at 7:48 AM, Hongbin Lu wrote: > > > >> -Original Message- >> From: Assaf Muller [mailto:as...@redhat.com] >> Sent: March-24-16 9:24 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing

[openstack-dev] [magnum] Streamline adoption of Magnum

Team, This thread is a continuation of a branch of the previous High Availability thread [1]. As the Magnum PTL, I’ve been aware of a number of different groups who have started using Magnum in recent months. For various reasons, there have been multiple requests for information about how to tu

Re: [openstack-dev] [magnum] High Availability

Team, Time to close down this thread and start a new one. I’m going to change the subject line, and start with a summary. Please restrict further discussion on this thread to the subject of High Availability. Thanks, Adrian On Mar 22, 2016, at 11:52 AM, Daneyon Hansen (danehans) mailto:daneh

Re: [openstack-dev] [magnum] High Availability

, Adrian On Mar 17, 2016, at 6:13 PM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Hongbin, One alternative we could discuss as an option for operators that have a good reason not to use Barbican, is to use Keystone. Keystone credentials store: http://specs.openstack.org/ope

[openstack-dev] [magnum] PTL Candidacy

rking integration. Further leverage Neutron through Kuryr, and demonstrate ways to integrate alternative options. I look forward to your vote, and to continued success together. Thanks, Adrian Otto [1] https://review.openstack.org/2

Re: [openstack-dev] [magnum] High Availability

some point in the future, justifying the use of an alternate. Adrian > On Mar 17, 2016, at 4:55 PM, Adrian Otto wrote: > > Hongbin, > >> On Mar 17, 2016, at 2:25 PM, Hongbin Lu wrote: >> >> Adrian, >> >> I think we need a boarder set of inputs in

Re: [openstack-dev] [magnum] High Availability

I have trouble understanding that blueprint. I will put some remarks on the whiteboard. Duplicating Barbican sounds like a mistake to me. -- Adrian > On Mar 17, 2016, at 12:01 PM, Hongbin Lu wrote: > > The problem of missing Barbican alternative implementation has been raised > several times

Re: [openstack-dev] [magnum] High Availability

ks, Adrian Best regards, Hongbin -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: March-17-16 4:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] High Availability I have trouble understanding that

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

Hi, Voting has concluded. Welcome, Shu Muto to the magnum-UI core team! I will announce your new status at today's team meeting. Thanks, Adrian > On Mar 14, 2016, at 5:40 PM, Shuu Mutou wrote: > > Hi team, > > Thank you very much for vote to me. > I'm looking forward to work more with our

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

onfirm it in the design summit/ML/team meeting. Frankly, it doesn’t seem to be. Then individuals or companies who are passionate about an alternative OS can develop the features for that OS. Corey On Sat, Mar 5, 2016 at 12:30 AM Hongbin Lu mailto:hongbin...@huawei.com>> wrote: From: A

Re: [openstack-dev] Branch miss-match between server and client in Kilo

Hi there Janki. Thanks for catching that. I think we can address this by creating a branch for the client that aligns with kilo. I’ve triaged the magnum bug on this, and I’m willing to help drive it to resolution together. Regards, Adrian On Mar 9, 2016, at 8:16 PM, Janki Chhatbar mailto:jank

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

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 _

Re: [openstack-dev] [magnum][magnum-ui] Liaisons for I18n

Kato, I have confirmed with Shu Muto, who will be assuming our I18n Liaison role for Magnum until further notice. Thanks for raising this important request. Regards, Adrian > On Mar 3, 2016, at 6:53 AM, KATO Tomoyuki wrote: > > I added Magnum to the list... Feel free to add your name and IRC

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

Steve, On Mar 4, 2016, at 2:41 PM, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: From: Adrian Otto mailto:adrian.o...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Fr

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

Hongbin, To be clear, this pursuit is not about what OS options cloud operators can select. We will be offering a method of choice. It has to do with what we plan to build comprehensive testing for, and the implications that has on our pace of feature development. My guidance here is that we re

Re: [openstack-dev] [magnum][magnum-ui] Liaisons for I18n

Yuanying, I would be happy to appoint Shu Muto for that role. I’ll check in with him about that. Thanks, Adrian On Mar 1, 2016, at 6:11 PM, 大塚元央 mailto:yuany...@oeilvert.org>> wrote: Hi team, Shu Muto is interested in to became liaisons from magnum-ui. He put great effort into translating

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

penStack deployments) and CoreOS (is highly adopted/tested in Kub community and Mesosphere DCOS uses it as well). We can implement CoreOS support as driver and users can use it as reference implementation. --- Egor ________ From: Adrian Otto mailto:adrian.o...@rackspace.com

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

Consider this: Which OS runs on the bay nodes is not important to end users. What matters to users is the environments their containers execute in, which has only one thing in common with the bay node OS: the kernel. The linux syscall interface is stable enough that the various linux distributio

Re: [openstack-dev] [magnum] containers across availability zones

ocker > daemon config. > > On Wed, Feb 24, 2016 at 6:01 PM, Vilobh Meshram > wrote: >> +1 from me too for the idea. Please file a blueprint. Seems feasible and >> useful. >> >> -Vilobh >> >> >> On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto >>

Re: [openstack-dev] [magnum] containers across availability zones

Ricardo, Yes, that approach would work. I don’t see any harm in automatically adding tags to the docker daemon on the bay nodes as part of the swarm heat template. That would allow the filter selection you described. Adrian > On Feb 23, 2016, at 4:11 PM, Ricardo Rocha wrote: > > Hi. > > Has

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

Thanks everyone for your votes. Welcome Ton and Egor to the core team! Regards, Adrian > On Feb 1, 2016, at 7:58 AM, Adrian Otto wrote: > > Magnum Core Team, > > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. > Please respond with your

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

Agreed. > On Jan 31, 2016, at 10:46 PM, 王华 wrote: > > 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 d

[openstack-dev] [Magnum] New Core Reviewers

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

Re: [openstack-dev] [magnum] Planning Magnum Midcycle

Team, We have selected Feb 18-19 for the Midcycle, and will be hosted by HPE. Please save the date. The exact location is forthcoming, and is expected to be Sunnyvale. Thanks, Adrian > On Jan 11, 2016, at 11:29 AM, Adrian Otto wrote: > > Team, > > We are planning a mid c

[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

Hongbin, I’m not aware of any viable options besides using a nonvoting gate job. Are there other alternatives to consider? If not, let’s proceed with that approach. Adrian > On Jan 7, 2016, at 3:34 PM, Hongbin Lu wrote: > > Clark, > > That is true. The check pipeline must pass in order to en

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

This sounds like a source-of-truth concern. From my perspective the solution is not to create redundant quotas. Simply quota the Magnum resources. Lower level limits *could* be queried by magnum prior to acting to CRUD the lower level resources. In the case we could check the maximum allowed num

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

various runtime environments focused around OpenStack. Regards -steve From: Adrian Otto mailto:adrian.o...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, December 7, 201

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 threads for executing the >>

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

China 100193 Follow your heart. You are miracle! Adrian Otto ---17/12/2015 07:00:37 am---Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom mailto:tom.camm...@hpe.com>> wrote: From: Adrian Otto mailto:adrian.o...@rackspace.com>> To: "OpenStack D

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

Clint, I think you are categorically dismissing a very real ops challenge of how to set correct system limits, and how to adjust them in a running system. I have been stung by this challenge repeatedly over the years. As developers we *guess* at what a sensible default for a value will be for a

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

Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom wrote: > > I don’t see a benefit from supporting the old API through a microversion > when the same functionality will be available through the native API. +1 [snip] > Have we had any discussion on adding a v2 API and what changes (beyond > r

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

On Dec 16, 2015, at 2:25 PM, James Bottomley mailto:james.bottom...@hansenpartnership.com>> wrote: On Wed, 2015-12-16 at 20:35 +, Adrian Otto wrote: Clint, On Dec 16, 2015, at 11:56 AM, Tim Bell mailto:tim.b...@cern.ch>> wrote: -Original Message- From: Clint Byru

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

Clint, > On Dec 16, 2015, at 11:56 AM, Tim Bell wrote: > >> -Original Message- >> From: Clint Byrum [mailto:cl...@fewbar.com] >> Sent: 15 December 2015 22:40 >> To: openstack-dev >> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum >> Resources >> >> Hi! Can I offer a c

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

Vilobh, Thanks for advancing this important topic. I took a look at what Tim referenced how Nova is implementing nested quotas, and it seems to me that’s something we could fold in as well to our design. Do you agree? Adrian On Dec 14, 2015, at 10:22 PM, Tim Bell mailto:tim.b...@cern.ch>> wro

Re: [openstack-dev] Mesos Conductor usingcontainer-createoperations

On Dec 12, 2015, at 9:19 AM, Ton Ngo mailto:t...@us.ibm.com>> wrote: Hi Hongbin, The proposal sounds reasonable: basically it provides an agnostic alternative to the single command line that a user can invoke with docker or kubectl. If the user needs more advanced support (environment variabl

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

Until I see evidence to the contrary, I think adding some bootstrap complexity to simplify the process of bay node image management and customization is worth it. Think about where most users will focus customization efforts. My guess is that it will be within these docker images. We should ask

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

t;> wrote: Adrian, I would like to be an alternate. Regards Wanghua On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto mailto:adrian.o...@rackspace.com>> 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][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, Everett Toews wrote: >> H

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 in some bad networking en

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

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 as there is a huge eco

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 wi

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

Bharath, I agree with Hongbin on this. Let’s not expand magnum to deal with apps or appgroups in the near term. If there is a strong desire to add these things, we could allow it by having a plugin/extensions interface for the Magnum API to allow additional COE specific features. Honestly, it’s

Re: [openstack-dev] [Magnum][Testing] Reduce Functional testing on gate.

Eli, I like this proposed approach. We did have a discussion with a few Stackers from openstack-infra in Tokyo to express our interest in using bare metal for gate testing. That’s still a way out, but that may be another way to speed this up further. A third idea would be to adjust the nova vir

Re: [openstack-dev] [kuryr] competing implementations

Sometimes producing alternate implementations can be more effective than abstract discussions because they are more concrete. If an implementation can be produced (possibly multiple different implementations by different contributors) in a short period of time without significant effort, that’s

Re: [openstack-dev] magnum on OpenStack Kilo

in the past as well. Adrian On Nov 2, 2015, at 4:22 PM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Bruce, That sounds like this bug to me: https://bugs.launchpad.net/magnum/+bug/1411333 Resolved by: https://review.openstack.org/148059 I think you need this: keystone s

  1   2   3   4   >