[openstack-dev] [Heat] Stack breakpoint

or internal steps within a resource - How to specify breakpoints: CLI argument or coded in template or both - How to handle resources with timer, e.g. wait condition: pause/resume timer value - New state for a resource: PAUSED Thanks. Ton Ngo, ___ OpenStack

[openstack-dev] [Heat] Stack breakpoint

of stepping: resource level or internal steps within a resource - How to specify breakpoints: CLI argument or coded in template or both - How to handle resources with timer, e.g. wait condition: pause/resume timer value - New state for a resource: PAUSED Thanks. Ton Ngo

Re: [openstack-dev] [Heat] Stack breakpoint

on the resource. Then to debug the scenario why did my WaitCondition fails, the user would set a breakpoint before the WaitCondition, or after any of the resources that the WaitCondition depends on. In this case, we would know that the timer will never get kicked off because of the dependency. Ton Ngo

[openstack-dev] [heat] Saving the original raw template in the DB

of the template in the raw template table for each stack if there is failure, and a new column in the stack table to hold the id. We can argue that the user should have the original template to resubmit, but it seems useful and convenient to save it in the DB. Ton Ngo

Re: [openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software config/software deployment

/lib/heat-config/heat-config-script Ton Ngo, From: Tao Tao/Watson/IBM@IBMUS To: OpenStack List openstack-dev@lists.openstack.org Date: 11/06/2014 12:09 PM Subject:[openstack-dev] [heat] How to expose the error messages if the heat stack creation fails with software

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

I was also thinking of using the environment to hold the breakpoint, similarly to parameters. The CLI and API would process it just like parameters. As for the state of a stack hitting the breakpoint, leveraging the FAILED state seems to be sufficient, we just need to add enough

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

To: openstack-dev@lists.openstack.org Date: 01/13/2015 09:20 AM Subject:Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints? On 01/13/2015 01:15 AM, Ton Ngo wrote: I was also thinking of using the environment to hold the breakpoint, similarly to parameters

Re: [openstack-dev] [heat-translator] Nominating new core reviewers

+1 for both. From: Sahdev P Zala/Durham/IBM@IBMUS To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/17/2015 12:39 PM Subject:[openstack-dev] [heat-translator] Nominating new core reviewers Hello, I am glad to nominate

[openstack-dev] [Magnum] New Kubernetes version 0.19 on Fedora Atomic

Then on the minion node, the api service could not be reached. Has anyone tried this and had any success? Thanks in advance for any pointer. Ton Ngo, __ OpenStack Development Mailing List (not for usage questions) Unsubscribe

Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint

Hi Vilobh, Do we need to do something similar for a Swarm bay? Ton Ngo, From: Vilobh Meshram vilobhmeshram.openst...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Mailing List

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

+1, seems like the best choice. Ton Ngo, From: Hongbin Lu hongbin...@huawei.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/16/2015 06:33 AM Subject:Re: [openstack-dev] [magnum] Magnum template manage

Re: [openstack-dev] [magnum][kolla] Stepping down as a Magnum corereviewer

Hi Steve, It will certainly be a loss to not have your constant presence for guidance. Your sensible approach to solving hard problems has many times given clarity to the solution. I am sure many in the team takes you as a role model, so I think from time to time we will likely approach you

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

Thanks Eli for the analysis. I notice that the time to download the image is only around 1:15 mins out of some 21 mins to set up devstack. So it seems trying to reduce the size of the image won't make a significant improvement in the devstack time. I wonder how the image size affects the VM

Re: [openstack-dev] [Magnum][Testing] Reduce Functional testingongate.

We discussed this topics at the last design summit and a BP has been opened to track the effort: https://blueprints.launchpad.net/magnum/+spec/ubuntu-image-build Ton, From: Gregory Haynes To: openstack-dev Date: 11/13/2015 10:03

Re: [openstack-dev] [magnum] Failed to create swarm baywithfedora-21-atomic-5-d181.qcow2

Hi Mars, Your paste shows that the docker service is not starting, and all the following services like swarm-agent fails because of the dependency. The error message INVALIDARGUMENT seems odd, I have seen elsewhere but not with docker. If you log into the node, you can check the docker

Re: [openstack-dev] [magnum] Document adding --memory option to create containers

We should reserve time at the next summit to discuss putting together a detailed user guide, laying down a skeleton so contributors can start filling in different parts. Otherwise as we observe, everything is falling into the quick start guide. Ton Ngo, From: "Qiao,Liyong"

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

Hi Ryan, There was a talk in the last Summit on this topics to explore the options with Magnum, Senlin, Heat, Kubernetes: https://www.openstack.org/summit/tokyo-2015/videos/presentation/exploring-magnum-and-senlin-integration-for-autoscaling-containers A demo was shown with Senlin

Re: [openstack-dev] [magnum] Steps to upload magnum images

Thanks Hongbin for the useful info. I don't see the "apply" link either. It looks like the group is set to "Invite Only", so I will need to ping Steve Dake. Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "openstack-dev@lists.openstack.

Re: [openstack-dev] [Magnum] API response on k8s failure

no object named "Pod" is registered Clearly the error handling from the k8s handler needs to be improved. If the bug above is different from what you found, I think opening a new bug would be best. Ton Ngo, From: Adrian Otto <adrian.o...@rackspace.com> To: "Ope

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

Would it make sense to ask the opposite of Wanghua's question: should pod/service/rc be deprecated if the user can easily get to the k8s api? Even if we want to orchestrate these in a Heat template, the corresponding heat resources can just interface with k8s instead of Magnum. Ton Ngo, From

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

, hence the complication. Thanks Hongbin, Steve for the suggestion. If we don't see any fundamental flaw, we can proceed with the initial sub-optimal implementation and refine it later with the service domain implementation. Ton Ngo, From: Vikas Choudhary <choudharyvika...@gmail.

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

with handling the password and would actually match the intended usage in k8s. Ton Ngo, From: Ton Ngo/Watson/IBM@IBMUS To: "OpenStack Development Mailing List \(not for usage questions \)" <openstack-dev@lists.openstack.org> Date: 09/20/2015 09:57 PM Su

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

is: is this approach reasonable for the time, or is there a better approach? Ton Ngo, __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

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

d fill the pod with the inputted values (image, command, etc.). Similarly, in marathon, we could generate an app based on inputs. A key advantage of that is simple and doesn’t require COE-specific knowledge. Best regards, Hongbin From: Ton Ngo [mailto:t...@us.ibm.com] Sent: December-10-15 8:18 PM T

Re: [openstack-dev] Mesos Conductor using container-create operations

on how this would work. Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 12/09/2015 03:09 PM Subject:Re: [openstack-dev] Mesos Con

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

luster auto-scaling (https://github.com/kubernetes/kubernetes/pull/15304), which has implementation for GCE, but OpenStack support can be added as well. — Egor From: Ton Ngo <t...@us.ibm.com<mailto:t...@us.ibm.com>> Reply-To: "OpenStack Development Mailing Lis

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

+1 Ton Ngo, From: Shuu Mutou <shu-mu...@rf.jp.nec.com> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Cc: Haruhiko Katou <har-ka...@ts.jp.nec.com> Date: 06/10/2016 02:41 AM Subject:[openstack-dev] [magn

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

Thanks Ricardo for sharing the data, this is really encouraging! Ton, From: Ricardo Rocha To: "OpenStack Development Mailing List (not for usage questions)" Date: 06/17/2016 08:16 AM Subject:[openstack-dev]

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

Hi Egor, Do we need to add a cinder volume to the master nodes for Kubernetes as well? We did not run Docker on the master node before so the volume was not needed. Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: Egor Guz <e...@walmartlabs.com>, OpenStack Develop

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

for your votes. Welcome Ton and Egor to the core team! Regards, Adrian > On Feb 1, 2016, at 7:58 AM, Adrian Otto <adrian.o...@rackspace.com> wrote: > > Magnum Core Team, > > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewer

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

There seems to be different concerns, so it would be helpful to consider them separately: Ability to accommodate different distros How to support given limited resources: gate tests, developers From the discussion at the midcycle, I think we do have agreement that Magnum must be able to

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

I would agree that #2 is the most flexible option, providing a well defined path for additional frameworks such as Kubernetes and Swarm. I would suggest that the current Marathon framework be refactored to use this new hook, to serve as an example and to be the supported framework in Magnum. This

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

it's good before switching. One question: I notice the image built by DIB is 871MB, similar to the manually built image, while the public image from Atomic is 486MB. It might be worthwhile to understand the difference. Ton Ngo, From: Yolanda Robla Mota <yolanda.robla-m...@hpe.

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

with development, and gate tests if it makes sense. Ton Ngo, From: Yolanda Robla Mota <yolanda.robla-m...@hpe.com> To: <openstack-dev@lists.openstack.org> Date: 03/29/2016 01:35 PM Subject:Re: [openstack-dev] [magnum] Generate atomic images using diski

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

+1 for Eli Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 03/31/2016 11:21 AM Subject:[openstack-dev] [magnum] Proposing El

Re: [openstack-dev] [magnum] How to document 'labels'

I would like to add some context for a bigger picture so we might arrive at a more general solution. Typically CLI options are fairly static so the help messages are usually coded directly in the client. This provides a good user experience by making the info readily available to the users. The

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

I would vote for the OSC pattern to make it easier for the users, since we already expect that migration path. Also agree with Tom that this is a significant change so we should write a spec to think through carefully. Ton, From: Adrian Otto To: "OpenStack

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

+1, it has been a pleasure to work with Spyros. Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 07/22/2016 01:30 PM Subject:[

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

ent", how about a beaver, known for building dams: https://commons.wikimedia.org/wiki/File:Beaver_%28PSF%29.jpg Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.ope

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

for a second I thought that would be a great life cycle operation for bays .. :) Ton, From: Adrian Otto To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/29/2016 11:31 AM Subject:

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

? If so, this does change the API, but does not seem to break backward compatibility. Ton Ngo, From: "Wenzhi Yu (yuywz)" <wenzhi...@163.com> To: "openstack-dev" <openstack-dev@lists.openstack.org> Date: 07/27/2016 04:13 AM Subject:[openstack-dev] [magn

[openstack-dev] [docker] [magnum] Magnum account on Docker Hub

this account was set up for OpenStack Magnum. Thanks in advance! Ton Ngo, __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [magnum] ssh and http connection lost

Hi Yasemin, How would you like to configure the networking? Which COE are you using? You may want to consult the Networking section in the user guide: https://github.com/openstack/magnum/blob/master/doc/source/userguide.rst#networking Ton Ngo, From: Yasemin DEMİRAL (BİLGEM BTE

Re: [openstack-dev] [magnum] ssh and http connection lost

you have installed Docker on your devstack server. Even then, it should not cause connectivity problem. For more help, you may want to use the IRC channel #openstack-containers. Ton Ngo, From: yasemin <yasemin.demi...@tubitak.gov.tr> To: "OpenStack Development M

Re: [openstack-dev] [Magnum] Does Docker-Swarm not support inter-node/vm inter-container networking ?

let container provides service to each other through Docker port mapping. The end point for the container service would be the IP address of the VM where the container is hosted together with the port mapped. You just cannot ping from one container to another across VM's in this mode. Ton Ngo

Re: [openstack-dev] [Magnum] Does Docker-Swarm not support inter-node/vm inter-container networking ?

Hi Greg, We should have patches in the next few weeks and the target is to have this functionality in the Newton cycle. Ton Ngo, From: "Waines, Greg" <greg.wai...@windriver.com> To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] Quesion about Openstack Magnum

Hi Wally, You can try using an IP address instead of the name "controller" for the "host" attribute. This should be in /etc/magnum/magnum.conf in the section [api]. Ton Ngo, From: zhihao wang <wangzhihao...@hotmail.com> To: "openst...@lists.ope

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

Aug 5, 2016 at 5:11 PM, Ton Ngo <t...@us.ibm.com> wrote: Hi Ricardo, For your question 1, you can modify the Heat template to not create the Cinder volume and tweak the call to configure-docker-storage.sh to use local storage. It should be fairly straightforward. You just need to m

Re: [openstack-dev] [Magnum] Next auto-scaling feature design?

mechanism for auto-scaling to handle complex scenarios. For this, Senlin is a candidate; upstream is another potential choice. We may want to revisit this topic as a design session in the next summit. Ton Ngo, From: Hongbin Lu <hongbin...@huawei.com> To: "OpenStack Development M

Re: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub

cket with docker and see if they will tell you who it belongs to (as in does it belong to one of the founders of Magnum) or if it belongs to some other third party.  Their support is very fast.  They may not be able to give you the answer if its not an openstacker. Regards -s

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

ssistant: Kendra Witherspoon (919) 254-0680 Inactive hide details for Ton Ngo---06/17/2016 12:10:33 PM---Thanks Ricardo for sharing the data, this is really encouraging! TTon Ngo---06/17/2016 12:10:33 PM---Thanks Ricardo for sharing the data, this is really encouraging! Ton, Fr

Re: [openstack-dev] [magnum] Fedora Atomic image that supports kubernetes external load balancer (for stable/mitaka)

Thanks Steve. We indeed have been using the image built by Yolanda's DIB elements and things have been stable. Dane and I have resolved the problems with the load balancer at least for the LBaaS v1. For LBaaS v2, we need to build a new image with Kubernetes 1.3 and we just got one built today.

Re: [openstack-dev] [magnum] Swarm Mode -- to come?

Hi Fabrizio, We had a discussion on Docker 1.12 but have not proceeded with any development yet. You are quite welcome to write a blueprint with details on how you envision it should work. This would help move the discussion along. Ton Ngo, From: Fabrizio Soppelsa <fsoppe...@mirantis.

[openstack-dev] [Magnum][Kuryr][Keystone] Securing services in container orchestration

for a solution. The Magnum and Kuryr teams have been discussing this topic for some time. We would welcome any suggestion. Ton Ngo, __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [Kuryr][Magnum] How stable is kuryr-kubernetes?

. We have been working with and Kuryr team on security issues and as soon as the new version is functional, we will resume the work on Magnum. We would be glad to work with you if you are interested. You can ping us on the Magnum IRC #openstack-containers. Ton Ngo, From: Antoni Segura