[openstack-dev] [openstack-helm] [Openstack-Helm] Denver PTG Schedule

[Pete Birley]

Hey!

The Openstack-Helm team has put together a rough schedule and outline for
the PTG:

   - https://etherpad.openstack.org/p/openstack-helm-ptg-stein

Really looking forward to seeing everyone all in Denver :)

Cheers

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

Re: [openstack-dev] [openstack-helm] [vote] Core Reviewer nomination for Chris Wedgwood

[Pete Birley]

An emphatic +1, Chris has really done some great work reviewing, and
contributing code.


On 7 August 2018 at 09:45, Tin Lam  wrote:

> +1
>
> On Tue, Aug 7, 2018 at 9:31 AM Alan Meadows 
> wrote:
>
>> +1
>>
>> On Fri, 2018-08-03 at 16:52 +, Richard Wellum > > wrote:
>>
>> >
>> > +1
>> >
>> > On Fri, Aug 3, 2018 at 11:39 AM Steve Wilkerson > > com>
>> > wrote:
>> >
>> > > +1
>> > >
>> > > On Fri, Aug 3, 2018 at 10:05 AM, MCEUEN, MATT 
>> > > wrote:
>> > >
>> > > > OpenStack-Helm core reviewer team,
>> > > >
>> > > > I would like to nominate Chris Wedgwood as core review for the
>> > > > OpenStack-Helm.
>> > > >
>> > > > Chris is one of the most prolific reviewers in the OSH community,
>> > > > but
>> > > > more importantly is a very thorough and helpful reviewer.  Many
>> > > > of my most
>> > > > insightful reviews are thanks to him, and I know the same is true
>> > > > for many
>> > > > other team members.  In addition, he is an accomplished OSH
>> > > > engineer and
>> > > > has contributed features that run the gamut, including Ceph
>> > > > integration,
>> > > > Calico support, Neutron configuration, Gating, and core Helm-
>> > > > Toolkit
>> > > > functionality.
>> > > >
>> > > > Please consider this email my +1 vote.
>> > > >
>> > > > A +1 vote indicates that you are in favor of his core reviewer
>> > > > candidacy,
>> > > > and a -1 is a veto.  Voting will be open for the next seven days
>> > > > (closing
>> > > > 8/10) or until all OpenStack-Helm core reviewers cast their vote.
>> > > >
>> > > > Thank you,
>> > > > Matt McEuen
>> > > >
>> > > > _
>> > > > _
>> > > > 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
>>
>
>
> --
> Regards,
>
> Tin Lam
>
__
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

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

[Pete Birley]

+1

On Thu, Apr 19, 2018, 1:24 AM Eduardo Gonzalez  wrote:

> +1
>
> 2018-04-19 8:21 GMT+02:00 Christian Berendt <
> bere...@betacloud-solutions.de>:
>
>> +1
>>
>> > On 18. Apr 2018, at 03:51, Jeffrey Zhang 
>> wrote:
>> >
>> > Since many of the contributors in the kolla-kubernetes project are
>> moved to other things. And there is no active contributor for months.  On
>> the other hand, there is another comparable project, openstack-helm, in the
>> community.  For less confusion and disruptive community resource, I propose
>> to retire the kolla-kubernetes project.
>> >
>> > More discussion about this you can check the mail[0] and patch[1]
>> >
>> > please vote +1 to retire the repo, or -1 not to retire the repo. The
>> vote will be open until everyone has voted, or for 1 week until April 25th,
>> 2018.
>> >
>> > [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
>> > [1] https://review.openstack.org/552531
>> >
>> > --
>> > Regards,
>> > Jeffrey Zhang
>> > Blog: http://xcodest.me
>> >
>> __
>> > 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
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: bere...@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> __
>> 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
>>
>
> __
> 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
>
__
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

Re: [openstack-dev] [k8s] OpenStack and Containers White Paper

[Pete Birley]

Chris,

I'd be happy to help out where I can, mostly related to OSH and LOCI. One
thing we should make clear is that both of these projects are agnostic to
each other: we gate OSH with both LOCI and kolla images, and conversely
LOCI has uses far beyond just OSH.

Pete

On Monday, April 2, 2018, Chris Hoge <ch...@openstack.org> wrote:

> Hi everyone,
>
> In advance of the Vancouver Summit, I'm leading an effort to publish a
> community produced white-paper on OpenStack and container integrations.
> This has come out of a need to develop materials, both short and long
> form, to help explain how OpenStack interacts with container
> technologies across the entire stack, from infrastructure to
> application. The rough outline of the white-paper proposes an entire
> technology stack and discuss deployment and usage strategies at every
> level. The white-paper will focus on existing technologies, and how they
> are being used in production today across our community. Beginning at
> the hardware layer, we have the following outline (which may be inverted
> for clarity):
>
> * OpenStack Ironic for managing bare metal deployments.
> * Container-based deployment tools for installing and managing OpenStack
>* Kolla containers and Kolla-Ansible
>* Loci containers and OpenStack Helm
> * OpenStack-hosted APIs for managing container application
>   infrastructure.
>* Magnum
>* Zun
> * Community-driven integration of Kubernetes and OpenStack with K8s
>   Cloud Provider OpenStack
> * Projects that can stand alone in integrations with Kubernetes and
>   other cloud technology
>* Cinder
>* Neutron with Kuryr and Calico integrations
>* Keystone authentication and authorization
>
> I'm looking for volunteers to help produce the content for these sections
> (and any others we may uncover to be useful) for presenting a complete
> picture of OpenStack and container integrations. If you're involved with
> one of these projects, or are using any of these tools in
> production, it would be fantastic to get your input in producing the
> appropriate section. We especially want real-world deployments to use as
> small case studies to inform the work.
>
> During the process of creating the white-paper, we will be working with a
> technical writer and the Foundation design team to produce a document that
> is consistent in voice, has accurate and informative graphics that
> can be used to illustrate the major points and themes of the white-paper,
> and that can be used as stand-alone media for conferences and
> presentations.
>
> Over the next week, I'll be reaching out to individuals and inviting them
> to collaborate. This is also a general invitation to collaborate, and if
> you'd like to help out with a section please reach out to me here, on the
> K8s #sig-openstack Slack channel, or at my work e-mail,
> ch...@openstack.org.
> Starting next week, we'll work out a schedule for producing and delivering
> the white-paper by the Vancouver Summit. We are very short on time, so
> we will have to be focused to quickly produce high-quality content.
>
> Thanks in advance to everyone who participates in writing this
> document. I'm looking forward to working with you in the coming weeks to
> publish this important resource for clearly describing the multitude of
> interactions between these complementary technologies.
>
> -Chris Hoge
> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>
>
> __
> 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
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

[Pete Birley]

Would be great to have Rich, an enthusiastic +1 from me :)

On Sat, Aug 12, 2017 at 11:38 AM, Serguei Bezverkhi (sbezverk) <
sbezv...@cisco.com> wrote:

> +1
>
> well deserved
>
> Serguei
>
> *From: *"Vikram Hosakote (vhosakot)" <vhosa...@cisco.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Friday, August 11, 2017 at 7:31 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum
> to core team
>
>
>
> Rich? Well, um ;)
>
>
>
> Although I’m not a kolla-kubernetes core and my vote does not matter at
> all, I’ll still give
>
> my +1 to Rich J.
>
>
>
> Amazing work in kolla-kubernetes Rich especially your recent contribution
> of the Python
>
> tool to automate the deployment of kolla-kubernetes.
>
>
>
> https://review.openstack.org/#/c/487972/
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC: vhosakot
>
>
>
> *From: *Michał Jastrzębski <inc...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Friday, August 11, 2017 at 12:01 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to
> core team
>
>
>
> Hello,
>
>
>
> It's my pleasure to start another core team vote. This time for our
>
> colleague rwellum. I propose that he joins kolla-kubernetes team.
>
>
>
> This is my +1 vote. Every kolla-kubernetes core has a vote and it can
>
> be veto'ed.
>
>
>
> Voting will last 2 weeks and will end at 25th of August.
>
>
>
> Cheers,
>
> Michal
>
>
>
> __
>
> 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
>
>
>
> __
> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

[Pete Birley]

Flavio,

Sounds great to me, look forward to catching up and plotting some
collaborative hacking :)

Catch you all at the PTG!

Cheers

Pete

On Fri, Feb 10, 2017 at 2:24 PM, Flavio Percoco <fla...@redhat.com> wrote:

> On 09/02/17 09:57 +0100, Flavio Percoco wrote:
>
>> Greetings,
>>
>> I was talking with Tony and he mentioned that he's recording a new demo
>> for
>> kuryr and, well, it'd be great to also use the containerized version of
>> TripleO
>> for the demo.
>>
>> His plan is to have this demo out by next week and that may be too tight
>> for the
>> containerized version of TripleO (it may be not, let's try). That said, I
>> think
>> it's still a good opportunity for us to sit down at the PTG and play with
>> this a
>> bit further.
>>
>> So, before we set a date and time for this, I wanted to extend the invite
>> to
>> other folks and see if there's some interest. It be great to also have
>> folks
>> from Kolla and openstack-helm joining.
>>
>> Looking forward to hearing ideas and hacking with y'all,
>> Flavio
>>
>
> So, given the interest and my hope to group as much folks from other teams
> as
> possible, what about we just schedule this for Wednesday at 09:00 am ?
>
> I'm not sure what room we can crash yet but I'll figure it out soon and let
> y'all know.
>
> Any objections/observations?
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

[Pete Birley]

Dan,

There's no way I could have put that any better than Tony!
Though he's given me a bit too much credit, I actually just extended his
work to make use of Lbaasv2, and never got round to fully making use of
OVN's native LoadBalancing.

Cheers

Pete

On Fri, Feb 10, 2017 at 12:34 AM, Antoni Segura Puimedon <celeb...@gmail.com
> wrote:

>
>
> On Thu, Feb 9, 2017 at 10:00 PM, Dan Sneddon <dsned...@redhat.com> wrote:
>
>> Pete, thanks for mentioning network isolation and segmentation. That's
>> my area of interest, since I'm focused on underlay networking for
>> TripleO and bare-metal networking in Ironic.
>>
>> Network isolation is going to be important for several reasons:
>>
>> 1) Separation of control and data plane in deployments
>> 2) Tenant isolation in multi-tenant Ironic BMaaS
>> 3) Network Function Virtualization (NFV) use cases
>>
>> The intention of the isolated networking model for TripleO was to
>> separate control and data plane, as well as tenant from administrative
>> traffic. A secondary goal was to make this highly configurable and
>> customizable. This has been well received by many operators who have
>> rigid security isolation requirements (such as PCI-DSS for financial
>> transactions), or those who customize their underlay network to
>> integrate into an existing networking topology. I'm thinking about how
>> to do something similar in Kubernetes, perhaps with Kuryr.
>>
>> The Harbor project looks very interesting. Do you have any more
>> information about how Harbor uses Raven to achieve isolation? Also, are
>> you saying that Harbor uses an older (prototype) version of Raven, or
>> are you referring to Raven itself as a prototype?
>>
>
> I can answer to some of that :-)
>
> Raven was the Python 3 asyncio based prototype my team built back
> when I was at Midokura for integrating Kubernetes and Neutron as
> something to then upstream to Kuryr with the help of the rest of the
> community (taking the lessons learned from the PoC and improving
> on it). So yes, Raven itself was a prototype (a quite functional one)
> and led to what we know today in Kuryr as the kuryr-kubernetes
> controller, which is now almost at the same level of features, missing
> just two patches for the service support.
>
> I have to note here, that Pete did some interesting modifications to
> Raven like OVN support addition and leveraging the watcher model
> to make, IIRC, the cluster services use the native OVN load balancer
> rather than neutron-lbaas.
>
> The Kuryr-kubernetes controller is built with pluggability in mind and it
> has a system of drivers (using stevedore) for acquiring resources.  This
> makes things like what Pete did easier to achieve with the new codebase
> and also pick yourself the level of isolation that you want. Let's say
> that you want
> to have the different OSt components pick different networks or even
> projects, you would just need to make a very small driver like [0] or [1]
> that could, for example, make an http request to some service that held
> a mapping, read some specific annotation, etc.
>
> In terms of isolation for deployments, we are starting discussion about
> leveraging the new CNI support for reporting multiple interfaces (still not
> implemented in k8s, but playing is fun) so that we can put the pods that
> need it both in the control and in the data plane, we'll probably need to
> tweak the interface of the drivers so that they can return an iterable.
>
>
> [0] https://github.com/openstack/kuryr-kubernetes/blob/master/
> kuryr_kubernetes/controller/drivers/default_project.py#L39
> [1] https://github.com/openstack/kuryr-kubernetes/
> blob/master/kuryr_kubernetes/controller/drivers/default_subnet.py#L56
>
>>
>> I'll be at the PTG Tuesday through Friday morning. I'm looking forward
>> to having some conversations about this topic.
>>
>> --
>> Dan Sneddon |  Senior Principal OpenStack Engineer
>> dsned...@redhat.com |  redhat.com/openstack
>> dsneddon:irc|  @dxs:twitter
>>
>> On 02/09/2017 09:56 AM, Pete Birley wrote:
>> > Hi Flavio,
>> >
>> > I've been doing some work on packaging Kuryr for use with K8s as an
>> > underlay for OpenStack on Kubernetes. When we met up in Brno the Harbor
>> > project I showed you used Tony's old Raven Prototype to provide the
>> > network isolation and segmentation in K8s. I've since begun to lay the
>> > groundwork for OpenStack-Helm to support similar modes of operation,
>> > allowing both service isolation and also combined networking between
>> > OpenStack and K8s, where pods and VMs 

Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

[Pete Birley]

Michal,

It's actually really easy to achieve in k8s, provided we make some
concessions: at least one keystone and neutron API pod needs to run in the
host's network namespace (and the supporting DB's). This may not be
acceptable for Tripple-O, but I'm pretty sure we could find a workable
solution without too much hair-loss :) I'd need to revisit to the Kolla-K8s
options but it would be really easy to add an additional region with
OpenStack-helm to provide further separation of roles if required.

Cheers

Pete

On Thu, Feb 9, 2017 at 6:04 PM, Michał Jastrzębski <inc...@gmail.com> wrote:

> So from kolla (and kolla-k8s) point of view, this is chicken egg problem:)
> We could use kuryr for our networking, but who will deploy kuryr? We don't
> have undercloud concept in any of kollas so far. With Kolla-ansible we
> really use host networking all the way and for k8s we have k8s networking
> infra.
>
> That being said, deployment of kuryr with kolla is well within our mission
> and well... it's there:) https://github.com/openstack/kolla-ansible/tree/
> master/ansible/roles/kuryr .
>
> If we consider tripleo case, where kuryr can be part of undercloud, we
> gain bunch of new possibilities, I'd love to have this discussion.
>
> Cheers,
> Michal
>
> On 9 February 2017 at 09:56, Pete Birley <pete@port.direct> wrote:
>
>> Hi Flavio,
>>
>> I've been doing some work on packaging Kuryr for use with K8s as an
>> underlay for OpenStack on Kubernetes. When we met up in Brno the Harbor
>> project I showed you used Tony's old Raven Prototype to provide the network
>> isolation and segmentation in K8s. I've since begun to lay the groundwork
>> for OpenStack-Helm to support similar modes of operation, allowing both
>> service isolation and also combined networking between OpenStack and K8s,
>> where pods and VMs can co-exist on the same Neutron Networks.
>>
>> I'm not sure I will have things fully functional within OpenStack-Helm by
>> the PTG, but it would be great to sit down and work out how we can ensure
>> that not only do we not end up replicating work needlessly, but also find
>> further opportunities to collaborate. I'll be in Atlanta all week, though I
>> think some of the OS-Helm and Kolla-K8s developers will be leaving on Wed,
>> would a particular day/time work best for you?
>>
>>
>> Cheers
>>
>> Pete (portdirect)
>>
>>
>> On Thu, Feb 9, 2017 at 8:57 AM, Flavio Percoco <fla...@redhat.com> wrote:
>>
>>> Greetings,
>>>
>>> I was talking with Tony and he mentioned that he's recording a new demo
>>> for
>>> kuryr and, well, it'd be great to also use the containerized version of
>>> TripleO
>>> for the demo.
>>>
>>> His plan is to have this demo out by next week and that may be too tight
>>> for the
>>> containerized version of TripleO (it may be not, let's try). That said,
>>> I think
>>> it's still a good opportunity for us to sit down at the PTG and play
>>> with this a
>>> bit further.
>>>
>>> So, before we set a date and time for this, I wanted to extend the
>>> invite to
>>> other folks and see if there's some interest. It be great to also have
>>> folks
>>> from Kolla and openstack-helm joining.
>>>
>>> Looking forward to hearing ideas and hacking with y'all,
>>> Flavio
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>
>> [image: Port.direct] <https://port.direct>
>>
>> Pete Birley / Director
>> pete@port.direct / +447446862551 <+44%207446%20862551>
>>
>> *PORT.*DIRECT
>> United Kingdom
>> https://port.direct
>>
>> This e-mail message may contain confidential or legally privileged
>> information and is intended only for the use of the intended recipient(s).
>> Any unauthorized disclosure, dissemination, distribution, copying or the
>> taking of any action in reliance on the information herein is prohibited.
>> E-mails are not secure and cannot be guaranteed to be error free as they
>> can be intercepted, amended, or contain viruses. Anyone who communicates
&g

Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

[Pete Birley]

Hi Flavio,

I've been doing some work on packaging Kuryr for use with K8s as an
underlay for OpenStack on Kubernetes. When we met up in Brno the Harbor
project I showed you used Tony's old Raven Prototype to provide the network
isolation and segmentation in K8s. I've since begun to lay the groundwork
for OpenStack-Helm to support similar modes of operation, allowing both
service isolation and also combined networking between OpenStack and K8s,
where pods and VMs can co-exist on the same Neutron Networks.

I'm not sure I will have things fully functional within OpenStack-Helm by
the PTG, but it would be great to sit down and work out how we can ensure
that not only do we not end up replicating work needlessly, but also find
further opportunities to collaborate. I'll be in Atlanta all week, though I
think some of the OS-Helm and Kolla-K8s developers will be leaving on Wed,
would a particular day/time work best for you?


Cheers

Pete (portdirect)


On Thu, Feb 9, 2017 at 8:57 AM, Flavio Percoco <fla...@redhat.com> wrote:

> Greetings,
>
> I was talking with Tony and he mentioned that he's recording a new demo for
> kuryr and, well, it'd be great to also use the containerized version of
> TripleO
> for the demo.
>
> His plan is to have this demo out by next week and that may be too tight
> for the
> containerized version of TripleO (it may be not, let's try). That said, I
> think
> it's still a good opportunity for us to sit down at the PTG and play with
> this a
> bit further.
>
> So, before we set a date and time for this, I wanted to extend the invite
> to
> other folks and see if there's some interest. It be great to also have
> folks
> from Kolla and openstack-helm joining.
>
> Looking forward to hearing ideas and hacking with y'all,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [all] New deadline for PTG Travel Support Program

[Pete Birley]

Thierry,

Thanks! As an independent contributor, it can be really hard to finance
these international trips, especially when there is no commercial element.
It is therefore really great, and appreciated, that you have extended this
program from the Summit to cover the PTG.

Cheers,

Pete

On Thu, Jan 12, 2017 at 4:51 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Hi everyone,
>
> The PTG Travel Support Program helps contributors that are not otherwise
> funded to join their team gathering at the Project Teams Gathering. See
> http://www.openstack.org/ptg#tab_travel for more explanations.
>
> The Travel Support Program applications were organized in two phases,
> and the second (and last) phase is closing very soon. It was originally
> set to close on January 15, but we'll accept applications until
> end-of-day Tuesday, January 17th. Apply now if you need it:
>
> https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta
>
> These submissions will be evaluated next week and grantees will be
> notified by Friday, January 20th.
>
> NB: People who did not get accepted during the first phase are
> automatically re-considered in phase 2, without needing to re-apply.
>
> This email is also the occasion to remind you to register for the event
> if you haven't yet!  Prices will increase on January 24 and February 14.
> Book now at:
>
> https://pikeptg.eventbrite.com/
>
> Finally, if you haven't booked your hotel yet, I encourage you to book
> ASAP in the event hotel itself using the PTG room block. It helps us
> keep the costs under control and helps you share the most time with the
> event participants. The hotel block closes on January 27. Book now using
> this link:
>
> https://www.starwoodmeeting.com/events/start.action?id=
> 1609140999=381BF4AA
>
> Thanks!
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
>



-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Pete Birley]

I'll reply to Britts comments, and then duck out, unless explicitly asked
back, as I don't want to (totally) railroad this conversation:

The Kolla containers entry-point is a great example of how the field have
moved on. While it was initially required, in the Kkubernetes world the
Kolla ABI is actually more of a hindrance than help, as it makes the
containers much more of a 'black-box' to use. In the other Openstack on
Kubernetes projects I contribute to, and my own independent work, in we
actually just define the entry point to the container directly in the k8s
manifest and make no use of Kolla's entry point and config mechanisms,
either running another 'init' container to build and bind mount the
configuration (Harbor), or use Kubernetes configmap object to achieve the
same result (Openstack Helm). It would be perfectly possible for Kolla
Ansible (and indeed Salt) to take a similar approach - meaning that rather
maintaining an ABI that works for all platforms, Kolla would be free to
just ensure that the required binaries were present in images.

I agree that this cannot happen overnight, but think that when appropriate
we should take stock of where we are and how to plot a course that lets all
of our projects flourish without competing for resources, or being so
entwined that we become technically paralyzed and overloaded.

Sorry, Sam and Michal! You can have your thread back now :)

On Fri, Jan 6, 2017 at 1:17 AM, Britt Houser (bhouser) <bhou...@cisco.com>
wrote:

> I think both Pete and Steve make great points and it should be our long
> term vision.  However, I lean more with Michael that we should make that a
> separate discussion, and it’s probably better done further down the road.
> Yes, Kolla containers have come a long way, and the ABI has been stable for
> awhile, but the vast majority of that “for awhile” was with a single
> deployment tool: ansible.  Now we have kolla-k8s and kolla-salt.  Neither
> one is fully featured yet as ansible, which to me means I don’t think we
> can say for sure that ABI won’t need to change as we try to support many
> deployment tools.  (Someone remind me, didn’t kolla-mesos change the ABI?)
> Anyway, the point is I don’t think we’re at a point of maturity to be
> certain the ABI won’t need changing.  When we have 2-3 deployment tools
> with enough feature parity to say, “Any tool should be able to deploy kolla
> containers” then I think it make sense to have that discussion.  I just
> don’t think we’re there yet.  And until the point, changes to the ABI will
> be quite painful if each project is in outside of the kolla umbrella, IMHO.
>
>
>
> Thx,
>
> britt
>
>
>
> *From: *Pete Birley <pete@port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 6:47 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
> Also coming from the perspective of a Kolla-Kubernetes contributor, I am
> worried about the scope that Kolla is extending itself to.
>
>
>
> Moving from a single repo to multiple repo's has made the situation much
> better, but by operating under a single umbrella I feel that we may
> potentially be significantly limiting the potential for each deliverable.
> Alex Schultz, Steve and Sam raise some good points here.
>
>
>
> The interdependency between the projects is causing issues, the current
> reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and
> unsustainable in my opinion. This is both because it limits the flexibility
> that we have as Kolla-Kubernetes developers, but also because it places
> burden and rigidity on Kolla-Ansible. This will ultimately prevent both
> projects from being able to take advantage of the capabilities offered to
> them by the deployment mechanism they use.
>
>
>
> Like Steve, I don't think the addition of Kolla-aSlt should affect me, and
> as a result don't feel I should have any say in the project. That said, I'd
> really like to see it happen in one form or another - as having a wide
> variety of complementary projects and tooling for OpenStack deployment can
> only be a good thing for the community if correctly managed.
>
>
>
> When Kolla started it was very experimental, containers (In their modern
> form) were a relatively new construct, and it took on the audacious task of
> trying to package and deploy OpenStack using the tooling that was available
> at the time. I really feel that this effort has succeeded admirably, and
> conversations like this are a result of that. Kolla is one of the most
> active projec

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Pete Birley]

gt; thing?  What if kolla-mesos was still about?  I think we can all agree this
> gets out of hand quickly.
>
> Yes, people are religious about the tools they use, and deployment tools
> are no different.  I think scoping them all under the same umbrella project
> is a mistake in the long term.  The folks that want to focus on Ansible
> should be able to focus wholly on Ansible with like-minded folks, same for
> Salt, same for whatever.  Having them remain together for the sake of
> sharing a name isn't sustainable in the long term -- let each do what they
> do well.  As far as being able to talk and share experiences in deployments
> or whatever, let's not act as if IRC channels have walls we can't reach
> across.  As part of the kolla-kubernetes community, it's imperative that I
> can reach across the gap to work with people in the Helm and Kubernetes
> community.  If the deployment tools existed separately, there's nothing
> stopping them from asking either.
>
> But in regards to the question, if kolla-salt is to be a thing, I think
> the PTL and the kolla team proper can decide that.  As a contributor for
> kolla-kubernetes, it does not and should not affect me.
>
> On Thu, Jan 5, 2017 at 3:14 PM, Doug Hellmann <d...@doughellmann.com>
> wrote:
>
>> Excerpts from Michał Jastrzębski's message of 2017-01-05 11:45:49 -0800:
>> > I think total separation of projects would require much larger
>> > discussion in community. Currently we agreed on having kolla-ansible
>> > and kolla-k8s to be deliverables under kolla umbrella from historical
>> > reasons. Also I don't agree that there is "little or no overlap" in
>> > teams, in fact there is ton of overlap, just not 100%. Many
>> > contributors (myself included) jump between deliverables today.
>>
>> OK, that's good to know. It wasn't clear from some of the initial
>> messages in this thread, which seemed to imply otherwise.
>>
>> Doug
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [kuryr] Kuryr Kubernetes Demo

[Pete Birley]

Ilya,

That's a great demo, thanks for sharing! - I'm quite interested in how we
could potentially use this in collaboration with Kolla-Kubernetes to
provide a unified Kubernetes-OpenStack environment, and will explore this
over the next couple of weeks.

Cheers

Pete

On Mon, Dec 19, 2016 at 2:11 AM, Ilya Chukhnakov <ichukhna...@mirantis.com>
wrote:

> Hello, fellow kuryrs!
>
> I'd like to share a demo [1] that shows how Kuryr enables OpenStack
> Neutron networking for Kubernetes and allows Pods to access Nova VMs and
> vice versa.
>
> [1] https://asciinema.org/a/51qn06lgz78gcbzascpl2du4w
>
> ---
> Regards,
>
> Ilya
>
> __
> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [kolla][kolla-kubernetes] Call for Kolla-kubernetes use cases contribution

[Pete Birley]

way to get the ball rolling would be
for everyone who is interested in Kolla-Kubernetes, to specify how you
would like to consume Kolla-Kubernetes and how you expect the project
to 'feel' in use?

To provide some assistance in this I've prepared a set of bullet
points of things to potentially consider, though this should not be
viewed a prescriptive set of points by any means:

* How do you expect operations on day one to be performed?

* How much do you need or want to be able to modify the output we
produce to meet your organization's specific requirements?

* How do you expect to interact with your deployment, and perform day
2 operations.

This exercise should not be a long and arduous process but should
enable us to move much more quickly in future toward producing a
cohesive set of building blocks that work for every member of the
community, and additionally, move the ecosystem as a whole further
forward.

Cheers

Pete (portdirect)

[1] https://github.com/stackanetes/stackanetes#stackanetes
[2] https://github.com/sapcc/openstack-helm#openstack-helm
[3] https://github.com/att-comdev/aic-helm#aic-helm
[4] https://github.com/portdirect/harbor#harbor
[5] https://github.com/hyperhq/hypernetes#what-is-hypernetes
[6] https://github.com/kubernetes/helm#kubernetes-helm
[7] 
https://github.com/openstack/kolla-kubernetes/blob/master/specs/kolla-kubernetes-arch.rst
[8] 
https://blueprints.launchpad.net/kolla-kubernetes/+spec/installation-docs-refactor
[9] https://github.com/openstack/fuel-ccp#ccp-overview
[10] https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-services

On Thu, Dec 15, 2016 at 3:43 AM, duon...@vn.fujitsu.com
<duon...@vn.fujitsu.com> wrote:
> Dear Kollish,
>
> As consensus from last weekly meeting [1], we need to define use cases for 
> kolla-kubernetes,
> so we can have more concrete ideas about what we should do next for Ocata 
> cycle and next cycles.
>
> After discussed on IRC [2], I created a patchset [3] for tracking use cases 
> evolving. If you have ideas, please submit or comment to
> this patchset.
>
> [1] 
> http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-12-14-16.00.log.html
> [2] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2016-12-15.log.html#t2016-12-15T02:48:07
> [3] https://review.openstack.org/#/c/411043/
>
>
> Thank you,
>
> duonghq
> PODC - Fujitsu Vietnam Ltd.
>
>
>
> __
> 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



-- 
Pete Birley / Director
pete@port.direct / +447446862551

PORT.DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination,
distribution, copying or the taking of any action in reliance on the
information herein is prohibited. E-mails are not secure and cannot be
guaranteed to be error free as they can be intercepted, amended, or
contain viruses. Anyone who communicates with us by e-mail is deemed
to have accepted these risks. Port.direct is not responsible for
errors or omissions in this message and denies any responsibility for
any damage arising from the use of e-mail. Any opinion and other
statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the
company.

__
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

Re: [openstack-dev] [kolla] How to handle doc in kolla and kolla-ansible

[Pete Birley]

I think Jeffrey's raised a good point here. Though I agree we should keep
the development side under a single umbrella/namespace, to better
co-ordinate our efforts, I think it makes more sense to move the end-user
documentation and to the repo that it's associated with. I feel this is the
right approach as it makes it much less likely for users to confuse/mix
documents. With this in mind would it not make sense to spit out the docs
as follows?

   - Kolla: images (building/specs), contributing, development
   - Kolla-ansible: deployment via ansible, ansible specific specs
   - Kolla-kubernetes: deployment via k8s, k8s specific specs

- Pete

On Mon, Nov 21, 2016 at 10:13 AM, Jeffrey Zhang <zhang.lei@gmail.com>
wrote:

> Then what's the case of kolla-kubernetes?
>
> On Mon, Nov 21, 2016 at 5:54 PM, Paul Bourke <paul.bou...@oracle.com>
> wrote:
> > Propose all docs stay under the kolla namespace
> > (http://docs.openstack.org/developer/kolla).
> >
> > Steve mentioned that we should try to keep all components (e.g. mailing
> list
> > tags) under the same umbrella which I agree with.
> >
> > On 21/11/16 08:05, Jeffrey Zhang wrote:
> >>
> >> After the split, we have two projects and two develop docs[0][1].
> >> These two sites have lots of duplicated lines.
> >>
> >> So will we split the doc site?
> >> if so, we need to remove the duplicated doc in the repos.
> >> if not, we need to remove one site's doc.
> >>
> >> [0] http://docs.openstack.org/developer/kolla
> >> [1] http://docs.openstack.org/developer/kolla-ansible/
> >>
> >
> > 
> __
> > 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
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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
>



-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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

Re: [openstack-dev] [kolla] Obtaining version information for Docker container

[Pete Birley]

I've been thinking about this a bit as well, and think that we should
consider using the docker label schema (http://label-schema.org/rc1/) as a
solution for #1, it would be possible to add labeling to kolla-build to add
these labels simply. This solution is gaining traction in the docker
community, and integrates well with external tools e.g.
https://microbadger.com. One of the maintainers of this project (Adrian
Mouat) works in the same room as me and I've cc'd him in case he has any
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and
currently it is not possible to query labels from within a container. I
think Steve's suggestion of a simple shell tool to query the containers
package manager(s) and produce a report is probably the right way to go:
but we should draw up a specification that scoped what data we collected in
such a manifest as if we simply do the equivalent of 'rpm -qa' then I think
Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake) <std...@cisco.com>
wrote:

> Zhu,
>
> This isn’t the first time this question has been asked :)
>
> Since this is a technical matter, I’ve copied openstack-dev for a wider
> audience.  I don’t have a clear solution to obtaining version manifests for
> container content or the upstream container version.  Perhaps someone in
> our broader community may have an answer.
>
> The best I’ve got is we could add a general shell command that can be run
> with docker exec to obtain a proper version manifest of both 1 and 2
> (formatted in YAML or plaintext).  This could be placed in the base
> container image to enable a general diagnostic and certificate of origin
> tool.
>
> Perhaps someone has a better solution?
>
> Regards
> -steve
>
>
> From: "zhu.z...@zte.com.cn" <zhu.z...@zte.com.cn>
> Date: Friday, November 18, 2016 at 1:56 AM
> To: Steven Dake <std...@cisco.com>
> Subject: 
>
> Hello，nice to meet you. I am a contributor of Kolla.
> Excuse me, I have a question to bother you.
> The question is that how to get openstack component version from a running
> container or image.
> you know , the version info is wrapped by the container, it is not easy to
> get them
> there are two type of versions
> one: version in a image, two: version in a running container
> two is easy, for example , we can get it by calling docker exec...
> but how to get the one, Is there any way, Thanks.
>
> __
> 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
>
>


-- 

[image: Port.direct] <https://port.direct>

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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