Thanks Egor, I will update.
On Fri, Oct 23, 2015 at 2:15 AM, Egor Guz <e...@walmartlabs.com> wrote: > thx, for clarification. do you mind to add this information to bp? > > I think we can get similar states through docker info against swarm, but > not sure about mesos. could you check? > > — > Egor > > From: Vikas Choudhary <choudharyvika...@gmail.com<mailto: > choudharyvika...@gmail.com>> > Date: Wednesday, October 21, 2015 at 16:04 > To: Walmart Associate <e...@walmartlabs.com<mailto:e...@walmartlabs.com>> > Subject: Re: [openstack-dev] [Magnum] Coe components status > > @Egor, > > Kubectl commnad is "kubectl get cs" > > > > On Wed, Oct 21, 2015 at 10:09 PM, Egor Guz <e...@walmartlabs.com<mailto: > e...@walmartlabs.com>> wrote: > Vikas, > > Could you clarify what do you mean under ’status’? I don’t seed this > command in kubectl, so I assume it is get or describe? > Also for Docker, is it info, inspect or stats? We can get app/container > details through Marathon API in Mesos, but it’s very depend what > information we are looking for ;) > > My two cents, I think we should implement/found common ground between 'kub > describe’, ‘docker inspect’ and 'curl http://${MASTER_IP}:8080/v2/tasks' > first. These commands > are very useful for troubleshooting. > > About 'magnum container’ command for all COEs, we should definitely > discuss this topic during summit. But challenge here that Marathon/Mesos > app/container definition is > very different form Kub model. > > — > Egor > > From: Vikas Choudhary <choudharyvika...@gmail.com<mailto: > choudharyvika...@gmail.com><mailto:choudharyvika...@gmail.com<mailto: > choudharyvika...@gmail.com>>> > Reply-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>>> > Date: Tuesday, October 20, 2015 at 20:56 > 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] Coe components status > > @ Eli , > > I will look into how to support this feature for other COEs also(mesos and > swarm). But anyways Magnum's goal is to provide users *atleast* what other > coes are providing (if not something extra). All coes dont have common > features, so we cant be very strict on providing common interface apis for > all coes. For example "magnum container" commands work only with swarm not > k8s or mesos. > It will not be justified if k8s is providing a way to monitor at more > granular level but magnum will not allow user to use it just beacuse other > coes does not provide this feature. > > Agree that it will be nice if could support this feature for all. I will > prefer to start with k8s first and if similar feature is supported by mesos > and swarm also, incrementally will implement that also. > > Regards > Vikas Choudhary > > On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong <liyong.q...@intel.com > <mailto:liyong.q...@intel.com><mailto:liyong.q...@intel.com<mailto: > liyong.q...@intel.com>>> wrote: > hi Vikas, > thanks for propose this changes, I wonder if you can show some examples > for other coes we currently supported: > swarm, mesos ? > > if we propose a public api like you proposed, we'd better to support all > coes instead of coe specific. > > thanks > Eli. > > > On 2015年10月20日 18:14, Vikas Choudhary wrote: > Hi Team, > > I would appreciate any opinion/concern regarding "coe-component-status" > feature implementation [1]. > > For example in k8s, using API > api/v1/namespaces/{namespace}/componentstatuses, status of each k8s > component can be queried. My approach would be to provide a command in > magnum like "magnum coe-component-status" leveraging coe provided rest api > and result will be shown to user. > > [1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status > > > > -Vikas Choudhary > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > ><mailto:openstack-dev-requ...@lists.openstack.org<mailto: > openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > BR, Eli(Li Yong)Qiao > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>< > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >
__________________________________________________________________________ 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-dev
