Re: [openstack-dev] [kolla] [requirements] Stepping down as core reviewer

[Steven Dake (stdake)]

Swapnil,

Pleasure working with you - hope to see you around the computerverse.

Cheers
-steve


On 10/16/18, 5:34 AM, "ʂʍɒρƞįł Ҟưȴķɒʁʉɨ"  wrote:

Dear OpenStackers,

For a few months now, I am not able to contribute to code or reviewing
Kolla and Requirements actively given my current responsibilities, I
would like to take a step back and release my core reviewer ability
for the Kolla and Requirements repositories.

I want to use this moment to thank the everyone I have had a chance to
work alongside with and I may have troubled. It has been both an honor
and privilege to serve this community and I will continue to do so.

In the new cloudy world I am sure the paths will cross again. Till
then, Sayo Nara, Take Care.

Best Regards,
Swapnil (coolsvap)

__
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] [tc] [all] TC Report 18-40

[Steven Dake (stdake)]

Chris,

Thanks for all the hard work you have put into this.  FWIW I found value in 
your reports, but perhaps because I am not involved in the daily activities of 
the TC.

Cheers
-steve


On 10/2/18, 8:25 AM, "Chris Dent"  wrote:


HTML: https://anticdent.org/tc-report-18-40.html

I'm going to take a break from writing the TC reports for a while.
If other people (whether on the TC or not) are interested in
producing their own form of a subjective review of the week's TC
activity, I very much encourage you to do so. It's proven an
effective way to help at least some people maintain engagement.

I may pick it up again when I feel like I have sufficient focus and
energy to produce something that has more value and interpretation
than simply pointing at
[the IRC logs](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/).
However, at this time, I'm not producing a product that is worth the
time it takes me to do it and the time it takes away from doing
other things. I'd rather make more significant progress on fewer
things.

In the meantime, please join me in congratulating and welcoming the
newly elected members of the TC: Lance Bragstad, Jean-Philippe
Evrard, Doug Hellman, Julia Kreger, Ghanshyam Mann, and Jeremy
Stanley.


-- 
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent

__
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] Committing proprietary plugins to OpenStack

[Steven Dake (stdake)]

?Shyam,


Our policy, decided long ago, is that we would work with third party components 
(such as plugins) for nova, cinder, neutron, horizon, etc that were proprietary 
as long as the code that merges into Kolla specifically is ASL2.


What is your plugin for?  if its for nova, cinder, neutron, horizon, it is 
covered by this policy pretty much wholesale.  If its a different type of 
system, some debate may be warranted by the core team.


Cheers

-steve


From: Shyam Biradar 
Sent: Wednesday, September 12, 2018 5:01 AM
To: Andreas Jaeger
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Committing proprietary plugins to OpenStack

Yes Andreas, whatever deployment scripts we will be pushing it will be under 
apache license.

[logo]

Shyam Biradar   Software Engineer | DevOps
M  +91 8600266938 | 
shyam.bira...@trilio.io | 
trilio.io



On Wed, Sep 12, 2018 at 5:24 PM, Andreas Jaeger 
mailto:a...@suse.com>> wrote:
On 2018-09-12 13:21, Shyam Biradar wrote:
Hi,

We have a proprietary openstack plugin. We want to commit deployment scripts 
like containers and heat templates to upstream in tripleo and kolla project but 
not actual product code.

Is it possible? Or How can we handle this case? Any thoughts are welcome.

It's first a legal question - is everything you are pushing under the Apache 
license as the rest of the project that you push to?

And then a policy of kolla project, so let me tag them

Andreas
--
 Andreas Jaeger 
aj@{suse.com,opensuse.org} Twitter: 
jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 
Nürnberg,
 Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][project navigator] kolla missing in project navigator

[Steven Dake (stdake)]

Thierry,

Kolla likely belongs in the packaging recipes in the map.  Kolla-Ansible 
belongs in the lifecycle tools.

FWIW, I'm agree with Jean on the location of OpenStack-Ansible in the map.  
This is a deployment tool, not really a set of recipes.  I think the name 
"openstack-ansible" as a project is what causes all the confusion.  Some folks 
see it as a set of playbooks by its naming, but really its a lifecycle 
management tool simply using Ansible as a dependent technology.

Jimmy,

Thanks for your help in sorting out the project navigator.  This is greatly 
appreciated.

Cheers
-steve


From: Thierry Carrez 
Sent: Monday, August 20, 2018 7:31 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][project navigator] kolla missing in 
project navigator

Eduardo,

"Kolla" was originally left out of the map (and therefore the new
OpenStack components page) because the map only shows deliverables that
are directly usable by deployers. That is why "Kolla-Ansible" is listed
there and not "Kolla".

Are you making the case that Kolla should be used directly by deployers
(rather than run it though Ansible with Kolla-Ansible), and therefore
should appear as a deployment option on the map as well ?

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

__
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] Dropping core reviewer

[Steven Dake (stdake)]

?Kollians,


Thanks for the kind words.


I do plan to stay involved in the OpenStack community - specifically targeting 
governance and will definitely be around - irc - mls - summits - etc :)


Cheers

-steve



From: Surya Singh 
Sent: Wednesday, August 8, 2018 10:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Dropping core reviewer

words are not strong enough to appreciate your immense contribution and help in 
OpenStack community.
Projects like Kolla, Heat and Magnum are still rocking and many more to come in 
future from you.
Hope to see you around.

Wish you all the luck !!
-- Surya

On Wed, Aug 8, 2018 at 6:15 PM Paul Bourke 
mailto:paul.bou...@oracle.com>> wrote:
+1. Will always have good memories of when Steve was getting the project
off the ground. Thanks Steve for doing a great job of building the
community around Kolla, and for all your help in general!

Best of luck,
-Paul

On 08/08/18 12:23, Eduardo Gonzalez wrote:
> Steve,
>
> Is sad to see you leaving kolla core team, hope to still see you around
> IRC and Summit/PTGs.
>
> I truly appreciate your leadership, guidance and commitment to make
> kolla the great project it is now.
>
> Best luck on your new projects and board of directors.
>
> Regards
>
>
>
>
>
> 2018-08-07 16:28 GMT+02:00 Steven Dake (stdake) 
> mailto:std...@cisco.com>
> <mailto:std...@cisco.com<mailto:std...@cisco.com>>>:
>
> Kollians,
>
>
> Many of you that know me well know my feelings towards participating
> as a core reviewer in a project.  Folks with the ability to +2/+W
> gerrit changes can sometimes unintentionally harm a codebase if they
> are not consistently reviewing and maintaining codebase context.  I
> also believe in leading an exception-free life, and I'm no exception
> to my own rules.  As I am not reviewing Kolla actively given my
> OpenStack individually elected board of directors service and other
> responsibilities, I am dropping core reviewer ability for the Kolla
> repositories.
>
>
> I want to take a moment to thank the thousands of people that have
> contributed and shaped Kolla into the modern deployment system for
> OpenStack that it is today.  I personally find Kolla to be my finest
> body of work as a leader.  Kolla would not have been possible
> without the involvement of the OpenStack global community working
> together to resolve the operational pain points of OpenStack.  Thank
> you for your contributions.
>
>
> Finally, quoting Thierry [1] from our initial application to
> OpenStack, " ... Long live Kolla!"
>
>
> Cheers!
>
> -steve
>
>
> [1] https://review.openstack.org/#/c/206789/
> <https://review.openstack.org/#/c/206789/>
>
>
>
>
>
> __
> 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
> <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://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://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-dev] [kolla] Dropping core reviewer

[Steven Dake (stdake)]

Kollians,


Many of you that know me well know my feelings towards participating as a core 
reviewer in a project.  Folks with the ability to +2/+W gerrit changes can 
sometimes unintentionally harm a codebase if they are not consistently 
reviewing and maintaining codebase context.  I also believe in leading an 
exception-free life, and I'm no exception to my own rules.  As I am not 
reviewing Kolla actively given my OpenStack individually elected board of 
directors service and other responsibilities, I am dropping core reviewer 
ability for the Kolla repositories.


I want to take a moment to thank the thousands of people that have contributed 
and shaped Kolla into the modern deployment system for OpenStack that it is 
today.  I personally find Kolla to be my finest body of work as a leader.  
Kolla would not have been possible without the involvement of the OpenStack 
global community working together to resolve the operational pain points of 
OpenStack.  Thank you for your contributions.


Finally, quoting Thierry [1] from our initial application to OpenStack, " ... 
Long live Kolla!"


Cheers!

-steve


[1] https://review.openstack.org/#/c/206789/



__
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] ptl non candidacy

[Steven Dake (stdake)]

?Jeffrey,


Thanks for your excellent service as Kolla PTL.  You have served the Kolla 
community well.


Regards,

-steve


From: Jeffrey Zhang 
Sent: Tuesday, July 24, 2018 8:48 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [kolla] ptl non candidacy

Hi all,

I just wanna to say I am not running PTL for Stein cycle. I have been involved 
in Kolla project for almost 3 years. And recently my work changes a little, 
too. So I may not have much time in the community in the future. Kolla is a 
great project and the community is also awesome. I would encourage everyone in 
the community to consider for running.

Thanks for your support :D.
--
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

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

[Steven Dake (stdake)]

+1

On 5/31/18, 10:08 AM, "Borne Mace"  wrote:

Greetings all,

I would like to propose the addition of Steve Noyes to the kolla-cli 
core reviewer team.  Consider this nomination as my personal +1.

Steve has a long history with the kolla-cli and should be considered its 
co-creator as probably half or more of the existing code was due to his 
efforts.  He has now been working diligently since it was pushed 
upstream to improve the stability and testability of the cli and has the 
second most commits on the project.

The kolla core team consists of 19 people, and the kolla-cli team of 2, 
for a total of 21.  Steve therefore requires a minimum of 11 votes (so 
just 10 more after my +1), with no veto -2 votes within a 7 day voting 
window to end on June 6th.  Voting will be closed immediately on a veto 
or in the case of a unanimous vote.

As I'm not sure how active all of the 19 kolla cores are, your attention 
and timely vote is much appreciated.

Thanks!

-- Borne


__
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] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate

[Steven Dake (stdake)]

Mark,

The major constraint here is gate memory (which is maxed at 8gb).  This is 
barely enough to run compute-kit (which is tested).  Now that multiple nodes 
are a thing, it may be possible to run computekit on one node, and other 
services on other nodes.  (IOW the environment has changed, and may be more 
conducive to adding more gating).

Cheers
-steve

From: Mark Goddard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, April 30, 2018 at 4:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Zun][Kolla][Kolla-ansible] Verify Zun deployment 
in Kolla gate

Hi,

This is something I've been thinking about recently. In particular, I noticed a 
patch go by to fix the same issue in the magnum role that has been broken and 
fixed previously. Kolla needs to up its game in terms of CI testing.

At the very least, we need tests that verify that services can be deployed. 
Even if we don't verify that the deployed service is functional, this will be 
an improvement from where we are today.

As with many things, we won't get there in a single leap, but should look to 
incrementally improve test coverage, perhaps with a set of milestones spanning 
multiple releases.

I suggest our first step should be to add a set of experimental jobs for 
testing particular services. These would not run against every patch, but could 
be invoked on demand by commenting 'check experimental' on a patch in Gerrit. 
For many services this could be done simply by setting 'enable_=true' 
in config.

There are many paths we could take from there, but perhaps this would be best 
discussed at the next PTG?

Cheers,
Mark

On Mon, 30 Apr 2018, 14:07 Jeffrey Zhang, 
> wrote:
Thanks hongbin

In Kolla, one job is used to test multi OpenStack services. there are already 
two test scenarios.

1. without ceph
2. with ceph

each scenario test a serial of OpenStack services. like nova, neutron, cinder 
etc.
Zun or kuryr is not tested now.  But i think it is OK to add a new scenario to 
test network related
service, like zun and kuryr.

for tempest testing, there is a WIP bp for this[0]

[0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate

On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu 
> wrote:
Hi Kolla team,

Recently, I saw there are users who tried to install Zun by using Kolla-ansible 
and reported bugs to us whenever they ran into issues (e.g. 
https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of this 
usage pattern (Kolla + Zun) made me think that we need to have CI coverage to 
verify the Zun deployment setup by Kolla.

IMHO, the ideal CI workflow should be:

* Create a VM with different distros (i.e. Ubuntu, CentOS).
* Use Kolla-ansible to stand up a Zun deployment.
* Run Zun's tempest test suit [1] against the deployment.

My question for Kolla team is if it is reasonable to setup a Zuul job as 
described above? or such CI jobs already exist? If not, how to create one?

[1] https://github.com/openstack/zun-tempest-plugin

Best regards,
Hongbin

__
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
__
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]Core nomination for Mark Goddard (mgoddard) as kolla core member

[Steven Dake (stdake)]

+1



From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, April 26, 2018 at 5:32 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard 
(mgoddard) as kolla core member

Kolla core reviewer team,

It is my pleasure to nominate
​
mgoddard for kolla core team.
​
Mark has been working both upstream and downstream with kolla and
kolla-ansible for over two years, building bare metal compute clouds with
ironic for HPC. He's been involved with OpenStack since 2014. He started
the kayobe deployment project which complements kolla-ansible. He is
also the most active non-core contributor for last 90 days[1]
​​
Consider this nomination a +1 vote from me

A +1 vote indicates you are in favor of
​
mgoddard as a candidate, a -1
is a
​​
veto. Voting is open for 7 days until
​May

​4​
th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/90

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

Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out of Kolla images

[Steven Dake (stdake)]

Mark,

TLDR good proposal

I don’t think Paul was proposing what you proposed.  However:

You make a strong case for separately packaging the api (mostly which Is 
setcfg.py and the json API + docs + samples).  I am super surprised nobody has 
ever proposed this in the past, but now is as good of a time as any to propose 
a good model for managing the JSON->setcfg.py API.  We could unit test this 
with extreme clarity, document with extreme clarity, and provide an easier path 
for people to submit changes to the API that they require to run the OpenStack 
containers.  Finally, it would provide complete semver semantics for managing 
change and provide perfect backwards compatibility.

A separate repo for this proposed api split makes sense to me.  I think 
initially we would want to seed with the kolla core team but be open to anyone 
that reviews + contributes to join the kolla-api core team (just as happens 
with other kolla deliverables).

This should reduce cross-project developer friction which was an implied but 
unstated problem in the various threads over the last week and produce the many 
other beneficial effects APIs produce along with the benefits you stated above.

I’m not sure if this approach is technically sound –but I’d be in favor of this 
approach if it were not too disruptive, provided full backwards compatibility 
and was felt to be an improvement by the consumers of kolla images.  I don’t 
think deprecation is something that is all that viable with an API model like 
the one we have nor this new repo and think we need to set clear boundaries 
around what would/would not be done.

I do know that a change of this magnitude is a lot of work for the community to 
take on – and just like adding or removing any deliverable in kolla, would 
require a majority vote from the CR team.

Also, repeating myself, I don’t think the current API is good nor perfect, I 
don’t think perfection is necessarily possible, but this may help drive towards 
that mythical perfection that interested parties seek to achieve.

Cheers
-steve

From: Mark Goddard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, April 6, 2018 at 12:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out of 
Kolla images


On Thu, 5 Apr 2018, 20:28 Martin André, 
> wrote:
On Thu, Apr 5, 2018 at 2:16 PM, Paul Bourke 
> wrote:
> Hi all,
>
> This mail is to serve as a follow on to the discussion during yesterday's
> team meeting[4], which was regarding the desire to move start scripts out of
> the kolla images [0]. There's a few factors at play, and it may well be best
> left to discuss in person at the summit in May, but hopefully we can get at
> least some of this hashed out before then.
>
> I'll start by summarising why I think this is a good idea, and then attempt
> to address some of the concerns that have come up since.
>
> First off, to be frank, this is effort is driven by wanting to add support
> for loci images[1] in kolla-ansible. I think it would be unreasonable for
> anyone to argue this is a bad objective to have, loci images have very
> obvious benefits over what we have in Kolla today. I'm not looking to drop
> support for Kolla images at all, I simply want to continue decoupling things
> to the point where operators can pick and choose what works best for them.
> Stemming from this, I think moving these scripts out of the images provides
> a clear benefit to our consumers, both users of kolla and third parties such
> as triple-o. Let me explain why.

It's still very obscure to me how removing the scripts from kolla
images will benefit consumers. If the reason is that you want to
re-use them in other, non-kolla images, I believe we should package
the scripts. I've left some comments in your spec review.

+1 to extracting and packaging the kolla API. This will make it easier to test 
and document, allow for versioning, and make it a first class citizen rather 
than a file in the build context of the base image. Plus, if it really is as 
good as some people are arguing, then it should be shared.

For many of the other helper scripts that get bundled into the kolla images, I 
can see an argument for pulling these up to the deployment layer. These could 
easily be moved to kolla-ansible, and added via config.json. I guess it would 
be useful to know whether other deployment tools (tripleo) are using any of 
these - if they are shared then perhaps the images are the best place for them.


> Normally, to run a docker image, a user will do 'docker run
> helloworld:latest'. In any non trivial application, config needs to be
> provided. In the vast majority of cases this is either provided via a bind
> mount 

Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out of Kolla images

[Steven Dake (stdake)]

+1.


From: Mark Goddard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, April 6, 2018 at 11:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out of 
Kolla images

One benefit of the kolla API that I've not seen mentioned yet (sorry if I 
missed it) is that you can change files on the host without affecting the 
running container. Bind mounts don't have this property. This is handy for 
reconfiguration/upgrade operations, where we write out a new set of config 
before recreating/restarting the container. COPY_ONCE is the king of immutable 
here, but even for COPY_ALWAYS, this works as long as the container doesn't 
restart while the config files are being written.

Mark

On 5 April 2018 at 21:41, Michał Jastrzębski 
> wrote:
So I'll re-iterate comment which I made in BCN. In previous thread we
praised how Kolla provided stable API for images, and I agree that it
was great design choice (to provide stable API, not necessarily how
API looks), and this change would break it. So *if* we decide to do
it, we need to follow deprecation, that means we could deprecate these
files in this release and start removing them in next.

Support for LOCI in kolla-ansible is good thing, but I don't think
changing Kolla image API is required for that. LOCI provides base
image arument, so we could simply create base-image with all the
extended-start and set-config mechanisms and some shim to source
extended-start script that belongs to particular container. We will
need kolla layer image anyway because set_config is there to stay (as
Martin pointed out it's valuable tool fixing real issue and it's used
by more projects than just kolla-ansible). We could add another script
that would look like extended_start.sh -> source
$CONTAINER_NAME-extended-start.sh and copy all kolla's extended start
scripts to dir with proper naming (I believe this is solution that Sam
came up with shortly after BCN). This is purely techincal and not that
hard to do, much quicker and easier than deprecating API...

On 5 April 2018 at 12:28, Martin André 
> wrote:
> On Thu, Apr 5, 2018 at 2:16 PM, Paul Bourke 
> > wrote:
>> Hi all,
>>
>> This mail is to serve as a follow on to the discussion during yesterday's
>> team meeting[4], which was regarding the desire to move start scripts out of
>> the kolla images [0]. There's a few factors at play, and it may well be best
>> left to discuss in person at the summit in May, but hopefully we can get at
>> least some of this hashed out before then.
>>
>> I'll start by summarising why I think this is a good idea, and then attempt
>> to address some of the concerns that have come up since.
>>
>> First off, to be frank, this is effort is driven by wanting to add support
>> for loci images[1] in kolla-ansible. I think it would be unreasonable for
>> anyone to argue this is a bad objective to have, loci images have very
>> obvious benefits over what we have in Kolla today. I'm not looking to drop
>> support for Kolla images at all, I simply want to continue decoupling things
>> to the point where operators can pick and choose what works best for them.
>> Stemming from this, I think moving these scripts out of the images provides
>> a clear benefit to our consumers, both users of kolla and third parties such
>> as triple-o. Let me explain why.
>
> It's still very obscure to me how removing the scripts from kolla
> images will benefit consumers. If the reason is that you want to
> re-use them in other, non-kolla images, I believe we should package
> the scripts. I've left some comments in your spec review.
>
>> Normally, to run a docker image, a user will do 'docker run
>> helloworld:latest'. In any non trivial application, config needs to be
>> provided. In the vast majority of cases this is either provided via a bind
>> mount (docker run -v hello.conf:/etc/hello.conf helloworld:latest), or via
>> environment variables (docker run --env HELLO=paul helloworld:latest). This
>> is all bog standard stuff, something anyone who's spent an hour learning
>> docker can understand.
>>
>> Now, lets say someone wants to try out OpenStack with Docker, and they look
>> at Kolla. First off they have to look at something called set_configs.py[2]
>> - over 400 lines of Python. Next they need to understand what that script
>> consumes, config.json [3]. The only reference for config.json is the files
>> that live in kolla-ansible, a mass of jinja and assumptions about how the
>> service will be run. Next, they need to figure out how to bind mount the
>> config files and config.json into the container in a way that can be
>> consumed by set_configs.py (which by the way, 

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On April 2, 2018 at 6:00:15 AM, Martin André 
(m.an...@redhat.com<mailto:m.an...@redhat.com>) wrote:

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.

At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

Martin,

Personally I think all of OpenStack projects that have a dependency or inverse 
dependency should cross-gate.  For example, Nova should gate on kolla-ansible, 
and at one point I think they agreed to this, if we submitted gate work to do 
so.  We never did that.

Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and they 
will follow the standard mechanism used in OpenStack 
experimental->non-voting->voting (if people are on-call to resolve problems).  
I don't think gating is relevant to equal footing.  TripleO for the moment has 
chosen to gate on their own image builds, which is fine.  If the gating should 
be enhanced, write the gates :)

Here is a simple definition from the internet:

"with the same 
rights<https://www.macmillandictionary.com/us/dictionary/american/right_3> and 
conditions<https://www.macmillandictionary.com/us/dictionary/american/condition_1>
 as someone you are 
competing<https://www.macmillandictionary.com/us/dictionary/american/competing> 
with"

Does that mean if you want to split the kolla repo into 40+ repos for each 
separate project, the core team will do that?  No.  Does that mean if there is 
a reasonable addition to the API the patch would merge?  Yes.

Thats right, deployment tools compete, but they also cooperate and collaborate. 
 The containers (atleast from my perspective) are an area where Kolla has 
chosen to collaborate.  FWIW I also think we have chosen to collobrate a bit in 
areas we compete (the deployment tooling itself).  Its a very complex topic.  
Splitting the governance and PTLs doesn't change the makeup of the core review 
team who ultimately makes the decision about what is reasonable.

|

> I would invite the TripleO team who did integration with the Kolla API to
> provide their thoughts.

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it

Most of Kolla unfortunately is undocumented.  The API is simple and 
straightforward enough that TripleO, OSH, and several proprietary vendors (the 
ones Jeffrey mentioned) have managed to implement deployment tooling that 
consume the API.  Documentation for any part of Kolla would be highly valued - 
IMO it is the Kolla project's biggest weakness.

up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

Another thing that comes for free with Kolla, the extend_start.sh
scripts are for the most part only useful in the context of
kolla_ansible. For instance, hardcoding path for log dirs to
/var/log/kolla and changing groups to 'kolla'.
In TripleO, we've chosen to not depend on the extend_start.sh scripts
whenever possible for this exact reason.

I don't disagree.  I was never fond of extend_start, and thought any special 
operations it provided belong in the API itself.  This is why there are mkdir 
operations and chmod/chown -R operations in the API.  The JSON blob handed to 
the API during runtime is where the API begins and ends.  The implementation 
(what set_cfg.py does with start.sh and extend_start.sh) are not part of the 
API but part of the API implementation.

I don't think I said anywhere the API is perfectly implemented.  I'm not sure 
I've ever seen this mythical perfection thing in an API anyway :)

Patches are welcome to improve the API to make it more general, as long as they 
maintain backward compatibility.


The other critical kolla feature we're making extensive use of in
TripleO is the ability to customize the image in any imaginable way
thanks to the template override mechanism. There would be no
containerized deployments via TripleO without it.


We knew people would find creative ways to use the plugin templating 
technology, and help drive adoption of Kolla as a standard...

Kolla is a great framework for building container images for OpenStack
services any project can consume. We

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On March 31, 2018 at 12:35:31 PM, Jeremy Stanley 
(fu...@yuggoth.org<mailto:fu...@yuggoth.org>) wrote:

On 2018-03-31 18:06:07 + (+0000), Steven Dake (stdake) wrote:
> I appreciate your personal interest in attempting to clarify the
> Kolla mission statement.
>
> The change in the Kolla mission statement you propose is
> unnecessary.
[...]

I should probably have been more clear. The Kolla mission statement
right now says that the Kolla team produces two things: containers
and deployment tools. This may make it challenging for the team to
avoid tightly coupling their deployment tooling and images, creating
a stratification of first-class (those created by the Kolla team)
and second-class (those created by anyone else) support for
deployment tools using those images.


The problems raised in this thread (tension - tight coupling - second class 
citizens - stratification) was predicted early on - prior to Kolla 1.0.  That 
prediction led to the creation of a technical solution - the Kolla API.   This 
API permits anyone to reuse the containers as they see fit if they conform 
their implementation to the API.  The API is not specifically tied to the 
Ansible deployment technology.  Instead the API is tied to the varying 
requirements that various deployment teams have had in the past around 
generalized requirements for making container lifecycle management a reality 
while running OpenStack services and their dependencies inside containers.

Is the intent to provide "a container-oriented deployment solution
and the container images it uses" (kolla-ansible as first-class
supported deployment engine for these images) or "container images
for use by arbitrary deployment solutions, along with an example
deployment solution for use with them" (kolla-ansible on equal
footing with competing systems that make use of the same images)?

My viewpoint is as all deployments projects are already on an equal footing 
when using Kolla containers.

I would invite the TripleO team who did integration with the Kolla API to 
provide their thoughts.

I haven't kept up with OSH development, but perhaps that team could provide 
their viewpoint as well.


Cheers

-steve


--
Jeremy Stanley
__
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] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On March 31, 2018 at 6:45:03 AM, Jeremy Stanley 
(fu...@yuggoth.org) wrote:
[...]
Given this, it sounds like the current Kolla mission statement of
"provide production-ready containers and deployment tools for
operating OpenStack clouds" could use some adjustment to drop the
production-ready containers aspect for further clarity. Do you
agree?
[...]

I appreciate your personal interest in attempting to clarify the Kolla mission 
statement.

The change in the Kolla mission statement you propose is unnecessary.

Regards

-steve


Jeremy Stanley
__
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] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On March 30, 2018 at 2:17:09 AM, Thierry Carrez 
(thie...@openstack.org) wrote:

There is a 3rd option, which I've been advocating for a while.

The tension here lies in the fact that the Kolla team is both a
low-level provider (Kolla the docker image provider) and a higher-level
deployment provider (kolla-ansible, kolla-k8s). The low-level images are
used outside of the team (TripleO, openstack-helm), in the team
(kolla-ansible) and in the team but by a different group (kolla-k8s).

The proposals on the table only partly resolve that tension. Keeping
kolla-k8s in kolla, spinning it out or merging it with OSH still make
kolla both a low-level and a high-level provider. As long as
kolla-ansible shares naming and is produced by the exact same team
producing Kolla itself, anything else than kolla-ansible will stay a
second-class consumer, breeding validation fears like the one described
above.

For the structure to match the technical goals, I wonder if "Kolla"
should not focus on low-level image production, with the various
higher-level Kolla consumers being set up as separate projects on an
equal footing. I understand that Kolla and Kolla-Ansible are currently
mostly the same group of people, but nothing in OpenStack prevents
anyone from being part of two teams. Setting up discrete groups would
actually encourage people interested in Kolla but not so much in
Kolla-Ansible to join the Kolla team. It would encourage the Kolla team
to treat all consumers equally and test their images on those various
consumers equally.

So my 3rd option would be to split the current Kolla team into three
teams with different names, matching the three deliverables that this
team currently has. Then if kolla-k8s needs to be sunset or merged with
OSH, so be it.

--
Thierry Carrez (ttx)


Just got back from Ready Player One.  Good Movie!

Thanks Thierry for offering up your advocated position.

When contributors joined the Kolla project, we had a clear mission of providing 
containers and deployment tools.  Our ultimate objective was to make deployment 
*EASY* and solve from my perspective as PTL at the time what was OpenStack's 
number one pain point.

What you're asking is for people to divide their time between two separate 
projects and take responsibility for making containers functional for other 
projects.

Currently the core team has been generous with our time reviewing people's work 
in addition with +2/+As that want to use other deployment tools with Kolla 
containers, as referenced by TripleO, OSH, as well as a variety of other 
proprietary deployment tools.  Some of these contributors are also core 
reviewers themselves.  I don't expect this work would slow down under the 
current governance model of Kolla as we provide a very clear API to use when 
interfacing with Kolla.  Hence we do not *make it hard* to contribute to the 
containers deliverable.  The same cannot be said in your proposed governance 
model.

What your proposal asks is for contributors that came to scratch an itch to 
scratch a bunch of other itches that may not be to their interest, attend twice 
as meetings, attend twice as many PTG sessions or midcycles and grow some 
amount of expertise in understanding the various problems of other deployment 
projects.  Ultimately I have a big concern this would drive contributors away, 
rather than solve a perceived second order problem with our current governance 
model.

Regards,
-steve

[1] is for more reading about the structure or Kolla.

[1] https://www.ansible.com/blog/openstack-kolla

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/maila man/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-dev] [kolla] Dropping off kolla-kubernetes core reviewer team

[Steven Dake (stdake)]

Hey folks,

As many core reviewers in Kolla core teams may already know, I am focused on 
OpenStack board of director work and adjacent community work.  This involves 
bridging the OpenStack ecosystem and its various strategic focus areas with 
adjacent community projects that make sense.  My work in this area has led to 
my technical involvement in a Layer 7 networking project (https://istio.io) – 
specifically around the multicloud use case and connecting OpenStack 
public/private clouds with other cloud providers.  As a result, I don’t have 
time to commit to properly furthering the development of kolla-kubernetes nor 
providing reviews for this specific Kolla project deliverable.

I do plan to stay involved in Kolla as a reviewer in the other Kolla core teams 
and I am deeply committed to furthering OpenStack’s strategic focus areas in my 
board of director’s service.

If you are curious about these SFAs, you might consider reading:
https://blogs.cisco.com/cloud/openstack-solving-for-integration-in-open-source-adjacent-communities

Regards,
-steve

__
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] core nomination for caoyuan

[Steven Dake (stdake)]

+1

From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, March 11, 2018 at 7:13 PM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

sorry for a typo.

The vote is open for 7 days until Mar 19th.

On Mon, Mar 12, 2018 at 10:06 AM, Jeffrey Zhang 
> wrote:
​​Kolla core reviewer team,

It is my pleasure to nominate caoyuan for kolla core team.

caoyuan's output is fantastic over the last cycle. And he is the most
active non-core contributor on Kolla project for last 180 days[1]. He
focuses on configuration optimize and improve the pre-checks feature.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/180
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me



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

Re: [openstack-dev] [Election] PTL Election Results & Conclusion

[Steven Dake (stdake)]

Agreed!

Congratulations to all our newly elected PTLs.  For past PTLs, thanks a bunch 
for your service!

The election process I'm certain is very difficult to execute, and as a 
community member, I'd like to thank the election officials for their work.

Cheers
-steve

On 2/15/18, 2:47 AM, "Thierry Carrez"  wrote:

Kendall Nelson wrote:
> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process possible.
> 
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs: [...]

Congrats to all newly-elected PTLs, and thanks to the election officials
for their service !

On the stats side, we renewed 17 of the 64 PTLs, so around 27%. Our
usual renewal rate is more around 35%, but we did renew more at the last
elections (40%) so this is likely why we didn't renew as much as usual
this time.

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


__
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] PTL non candidacy

[Steven Dake (stdake)]

Cheers Michal.  Thank you for your service.

Regards
-steve

From: Vikram Hosakote 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 31, 2018 at 1:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] PTL non candidacy

Thanks for being a great PTL for kolla Michał ☺

You’re not announcing your non-candidacy for drinking with your
OpenStack friends and this does not mean we can’t drink together ;)

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 10, 2018 13, 2017 at 10:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] PTL non candidacy

Hello,

A bit earlier than usually, but I'd like to say that I won't be
running for PTL reelection for Rocky cycle. I had privilege of being
PTL of Kolla for last 3 cycles and I would like to thank Kolla
community for this opportunity and trust. I'm very proud of what we've
accomplished over last 3 releases and I'm sure we will accomplish even
greater things in the future!

It's good for project to change leadership every now and then. I would
encourage everyone in community to consider running, I can promise
that this job is ... very interesting;) and extremely rewarding!

Thank you all for support and please, support new PTL as much as you
supported me.

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

Re: [openstack-dev] [kolla] Policy regarding template customisation

[Steven Dake (stdake)]

Agree, the “why” of this policy is stated here:
https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html

Paul, I think your corrective actions sound good.  Perhaps we should also 
reword “essential” to some other word that is more lenient.

Cheers
-steve

From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation

Thank Paul for pointing this out.

for me, I prefer to consist with 2)

There are thousands of configuration in OpenStack, it is hard for Kolla to
add every key/value pair in playbooks. Currently, the merge_config is a more
better solutions.




On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke 
> wrote:
Hi all,

I'd like to revisit our policy of not templating everything in kolla-ansible's 
template files. This is a policy that was set in place very early on in 
kolla-ansible's development, but I'm concerned we haven't been very consistent 
with it. This leads to confusion for contributors and operators - "should I 
template this and submit a patch, or do I need to start using my own config 
files?".

The docs[0] are currently clear:

"The Kolla upstream community does not want to place key/value pairs in the 
Ansible playbook configuration options that are not essential to obtaining a 
functional deployment."

In practice though our templates contain many options that are not necessary, 
and plenty of patches have merged that while very useful to operators, are not 
necessary to an 'out of the box' deployment.

So I'd like us to revisit the questions:

1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters 
to operators via key/value config options?

2) Or, is it to be a solid reference implementation, where any degree of 
customisation implies a clear 'bring your own configs' type policy.

If 1), then we should potentially:

* Update ours docs to remove the referenced paragraph
* Look at reorganising files like globals.yml into something more maintainable.

If 2),

* We should make it clear to reviewers that patches templating options that are 
non essential should not be accepted.
* Encourage patches to strip down existing config files to an absolute minimum.
* Make this policy more clear in docs / templates to avoid frustration on the 
part of operators.

Thoughts?

Thanks,
-Paul

[0] 
https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization

__
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

[openstack-dev] [kolla] Re: About maridb 10.1 on kolla

[Steven Dake (stdake)]

Michal wanted to test on multinode.  Not sure if he ever got there.

Anyway - feel free to take over the patch.  Even though gerrit doesn't care 
about co-authors, co-authors might, and we want to keep a tidy history of 
authorship for CLA reasons, so please use the

"Co-AUthored-by: first last " at the conclusion of your commit log.

Thanks


CHeers
-steve



On December 26, 2017 at 2:03:44 AM, Xinliang Liu 
(xinliang@linaro.org) wrote:

On 26 December 2017 at 15:47, Xinliang Liu  wrote:
> On 26 December 2017 at 15:38, Marcin Juszkiewicz
>  wrote:
>>
>>
>> 26.12.2017 08:05 "Xinliang Liu"  napisał(a):
>>
>> Hi Steven,
>>
>> I have tested your patch[1] that works for one node Debian MariaDB
>> 10.1 deployment.
>> But the whole change seems be not updated for long time. Your last
>> updated patch 12 was in May.
>>
>>
>> Xinliang: you can update patch in review too. Gerrit cares about change-id
>> field and do not care about author. So refresh patch from review and send
>> with "git review".
>
> OK. will update soon.

Done.
__
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] Ansiblize init-runonce script

[Steven Dake (stdake)]

I wrote that script ages ago.  I needed it in the repo  so I could consistently 
deploy.  It may still be entirely tailored around my environment ☺

That said, I had always hoped someone would make a generic cloud bootstrap for 
Kolla based upon the work in that script originally.  Maybe this is the time.

Cheers
-steve

From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, November 28, 2017 at 7:48 PM
To: Samuel Yaple , OpenStack Development Mailing List 

Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script

yes. it is not
​recommend to use in prod env, i never used this script. But
the reality is
lots users are using it, at least in the test environment.
and there are patches trying to make this script ​
idempotent
​ recently.​

2017年11月28日 23:28，"Sam Yaple" >写道：
For what its worth, this init-runonce script was never meant for production 
usage. Ops *shouldn't* be running it like you suggest. It was historically for 
use in the gate and a quick-n-dirty environment setup for testing.

If you want to get into writing operations scripts, thats your prerogative, but 
it was discussed before and mostly considered a bad idea.

Thanks,
SamYaple



 Original Message 
Subject: Re: [openstack-dev] [kolla] Ansiblize init-runonce script
Local Time: November 28, 2017 8:10 AM
UTC Time: November 28, 2017 1:10 PM
From: zhang.lei@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
>

in my opinion,


idempotent scrip
t is very necessary.
for several reason

- there is already some idempotent logical in the script
- it is common that this script failed by wrong configuration,
  after fix the config,
ops will want to run this script again.

On Tue, Nov 28, 2017 at 7:14 PM, Paul Bourke 
> wrote:
I think this came up before at one stage. My position is I don't see the need 
to ansible-ise small shell scripts. init-runonce is currently just an easy to 
understand sequence of openstack commands provided to help people test/demo 
their setups. Unless we want to make it more than that, i.e. make it 
idempotent, customizable, etc. I don't see the need to wheel in Ansible.

On 28/11/17 03:23, Jeffrey Zhang wrote:
hi

check this [0]. I tried to convert it  to ansible playbooks.

[0] https://review.openstack.org/523072

On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani 
 
>> wrote:

Hi,

While exploring kolla-ansible I ran into a few issues with
init-runonce script. This lead to following bugs and patches:

https://launchpad.net/bugs/1732963 
https://review.openstack.org/51

https://review.openstack.org/521190


But it was highlighted that instead of fixing/changing the
script, 'ansibilzing' it would be the ideal solution.
Hence I hereby formally propose the same.

My thoughts:
* Playbook Name: init-stack.yml

* Playbook path can be:
kolla-ansible/ansible/init-stack.yml

* The play can be executed like:
$ kolla-ansible init-stack -i 

* The cirros test image should be downloaded in /tmp

* What should be the behavior if the play is run multiple times
against the same stack?
   - some error message OR
   - simply ignore the action

Kindly provide suggestions.

--
Best Regards,
Ravi J.

__
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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team

[Steven Dake (stdake)]

+1

Cheers
-steve

On 11/3/17, 2:59 AM, "Michał Jastrzębski"  wrote:

It's my great pleasure to start another voting for core team addition!

Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
Voting will be open for 14 days (until 16th of Nov).

Consider this mail my +1 vote

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

Re: [openstack-dev] [tc] [kolla] [PTL] who can start the official meeting?

[Steven Dake (stdake)]

Dims,

This was just a fella in the kolla community experimenting without attempting 
to cause harm.  IOW he didn’t know exactly what he was doing which is helpful 
when messing with the meeting bots (.

No harm done anyway, so no need to take any corrective action in implementation.

Cheers
-steve

On 10/11/17, 11:15 AM, "Davanum Srinivas"  wrote:

Swapnil,

Dunno if it was malicious or someone just trying to understand how things 
work.

Worth reaching out to jinke [1]

[1] 
http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=e2593c113d64868b44f27a9fba15a564855236c6

Thanks,
Dims

On Wed, Oct 11, 2017 at 12:35 PM, Swapnil Kulkarni  
wrote:
> On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski  
wrote:
>> I haven't seen "malicious" meeting starters yet, let's hope that won't
>> happen:) On the other hand, ad-hoc chair change can, and did, happen,
>> so I agree with fungi - I don't think we need to put restrictions on
>> that.
>>
>> On 11 October 2017 at 09:11, Jeremy Stanley  wrote:
>>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote:
>>> [...]
 The problem here is if we know who are most likely to chair the
 meeting e.g. [1] we can allow them to start the meeting.
>>> [...]
>>>
>>> I'm pretty certain I wouldn't want to have to propose a patch to
>>> update that every time I needed someone to chair a meeting in my
>>> absence. This doesn't seem like a common enough issue to warrant the
>>> added complexity and red tape of access controls on our meeting
>>> automation.
>>> --
>>> Jeremy Stanley
>>>
>>> 
__
>>> 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
>
> Michal,
>
> I just gave one instance of malicious meeting attempt [1] happened
> today and it happened to be kolla meeting so I noticed its not correct
> timing for the same. I would put it as permission-ed access rather
> than restriction, because as much as we want to keep it open we need
> to maintain the genuineness of meeting. I would not want to stumble
> into a junk log file while I am reading it later looking for
> something.
>
>
> [1] 
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.html
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [TripleO][Kolla] Concerns about containers images in DockerHub

[Steven Dake (stdake)]

Sam,

Agreed this matches my experience. Building one by one though will result in 
massive image size sprawl.

Regards
-steve

From: Sam Yaple 
Reply-To: "s...@yaple.net" , "OpenStack Development Mailing 
List (not for usage questions)" 
Date: Thursday, October 19, 2017 at 10:37 PM
To: Gabriele Cerami 
Cc: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images 
in DockerHub



On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami 
> wrote:
On 19 Oct, Sam Yaple wrote:
> So it seems tripleo is building *all* images and then pushing them.
> Reworking your number leads me to believe you will be consuming 10-15GB in
> total on Dockerhub. Kolla images are only the size that you posted when
> built as seperate services. Just keep building all the images at the same
> time and you wont get anywhere near the numbers you posted.

Makes sense, so considering the shared layers
- a size of 10-15GB per build.
- 4-6 builds rotated per release
- 3-4 releases

- a size of 1-2GB per build
- 4-6 builds rotated per release
- 3-4 releases

At worst you are looking at 48GB not 360GB. Dont worry so much there!

total size will be approximately be 360GB in the worst case, and 120GB in
the best case, which seems a bit more reasonable.

Thanks for he clarifications

__
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] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Steven Dake (stdake)]

Steve,

I can see how #1 might be a problem in general and should be addressed in 
reasonable ways.

For #2, I think your analysis of the tech in use is accurate and if a new 
policy is made it be general yet inclusive enough to permit lifecycle 
management tools to improve and grow.

Regards
-steve

On 10/16/17, 8:57 AM, "Steven Hardy" <sha...@redhat.com> wrote:

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <std...@cisco.com> 
wrote:
> Emilien,
>
> I generally thought the stable policy seemed reasonable enough for 
lifecycle management tools.  I’m not sure what specific problems you had in 
TripleO although I did read your review.  Kolla was just tagged with the stable 
policy, and TMK, we haven’t run into trouble yet, although the Kolla project is 
stable and has been following the stable policy for about 18 months.  If the 
requirements are watered down, the tag could potentially be meaningless.  We 
haven’t experienced this specific tag enough to know if it needs some 
refinement for the specific use case of lifecycle management tools.  That said, 
the follows release policy was created to handle the special case of lifecycle 
management tool’s upstream sources not being ready for lifecycle management 
tools to release at one coordinated release time.

We initially felt the policy was reasonable too, but there are a
couple of specific recurring pain points:

1. Services land features which require installer/management tool
updates late in the cycle, or the work to update the configuration
tooling just doesn't happen fast enough during a given cycle.

2. Vendor integrations, similar to (1) but specific to enabling vendor
backends e.g for Neutron etc - the work to enable configuring specific
vendor plugins tends to lag the upstream releases (sometimes
significantly) because most vendors are focussed on consuming the
stable branch releases, not the development/master releases.

In an ideal world the answer would be for everyone working on these
integrations to land the installer (e.g puppet/TripleO/Kolla/...)
patches earlier, but even with the concessions around cycle-trailing
deadlines we're finding that there is ongoing pressure to backport
integrations which (according to stable-maint policy) are strictly
"features" but are actually more integration or enablement of features
which do exist in the version of OpenStack we're deploying.

Several releases ago (before we adopted stable: follows-policy) we
tried to solve this by allowing selected feature backports, but this
was insufficiently well defined (and thus abused) so we need some way
to enable vendor integrations and exposure of new features in the
underlying services, without allowing a backport-everything floodgate
to open ;)

I think one difference between TripleO/Puppet and Kolla here is AFAIK
Kolla has several ways to customize the configuration of deployed
services in a fairly unconstrained way, whereas the openstack puppet
modules and TripleO publish interfaces via a somewhat more static
module and "service plugin" model, which improves discoverability of
features e.g for the TripleO UI but causes a headache when you
discover support for a new vendor Neutron plugin is required well
after the upstream release deadline has passed.

Hope that helps clarify somewhat?

Steve

__
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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Steven Dake (stdake)]

Emilien,

I generally thought the stable policy seemed reasonable enough for lifecycle 
management tools.  I’m not sure what specific problems you had in TripleO 
although I did read your review.  Kolla was just tagged with the stable policy, 
and TMK, we haven’t run into trouble yet, although the Kolla project is stable 
and has been following the stable policy for about 18 months.  If the 
requirements are watered down, the tag could potentially be meaningless.  We 
haven’t experienced this specific tag enough to know if it needs some 
refinement for the specific use case of lifecycle management tools.  That said, 
the follows release policy was created to handle the special case of lifecycle 
management tool’s upstream sources not being ready for lifecycle management 
tools to release at one coordinated release time.

Kollians?  Any problems thus far with the stable policy?

Cheers
-steve


On 10/16/17, 4:27 AM, "Thierry Carrez"  wrote:

Emilien Macchi wrote:
> [...]
> ## Proposal
> 
> Proposal 1: create a new policy that fits for projects like installers.
> I kicked-off something here: https://review.openstack.org/#/c/511968/
> (open for feedback).
> Content can be read here:
> 
http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
> Tag created here: https://review.openstack.org/#/c/511969/ (same,
> please review).
> 
> The idea is really to not touch the current stable policy and create a
> new one, more "relax" that suits well for projects like installers.
> 
> Proposal 2: change the current policy and be more relax for projects
> like installers.
> I haven't worked on this proposal while it was something I was
> considering doing first, because I realized it could bring confusion
> in which projects actually follow the real stable policy and the ones
> who have exceptions.
> That's why I thought having a dedicated tag would help to separate them.
> 
> Proposal 3: no change anywhere, projects like installer can't claim
> stability etiquette (not my best option in my opinion).
> 
> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
> this need), please get involved in the review process.

My preference goes to proposal 1, however rather than call it "relaxed"
I would make it specific to deployment/lifecycle or cycle-trailing
projects.

Ideally this policy could get adopted by any such project. The
discussion started on the review and it's going well, so let's see where
it goes :)

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


__
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 is now stable:follows-policy project

[Steven Dake (stdake)]

Folks,

The addition of this project maturity tag is a great achievement!  This is one 
of many factors used by Operators to determine maturity of OpenStack projects.  
Glad to see our project’s persistence in this area paid off for the kolla and 
kolla-ansible deliverables.

Good work all!

Regards,
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 18, 2017 at 12:49 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Kolla is now stable:follows-policy project

As of today Kolla got this tag. That doesn't really mean we change
anything in our model as tag is given to projects which already
follows rules of stable policy, but that makes it official:)

Keep up with good work Kolla team!

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

Re: [openstack-dev] [tripleo] not running PTL during Queens

[Steven Dake]

Emilien,

While I haven't worked closely on the implementation of TripleO, it has
been a pleasure working with you as the PTL of TripleO.  Your a great
example of how to perform the service of the PTL and really demonstrate how
cross-project collaboration can work effectively to achieve common goals.

Regards
-steve


On Sun, Jul 30, 2017 at 9:52 PM, Emilien Macchi  wrote:

> Hi,
>
> After 3 cycles of Puppet OpenStack PTL and 2 cycles of TripleO PTL, I
> decided to do a little break on this role and give the opportunity to
> let other people taking it.
> A few months ago, I wrote a blog post about my personal thoughts on
> what leadership means to me and what I've learnt by being PTL:
> http://my1.fr/blog/my-journey-as-an-openstack-ptl/
>
> My hope is to see new leaders in our project and maintain the
> OpenStack values as strong as we've tried to push over the last years.
> I'll still be around but hopefully stepping down will allow me to
> focus on some other things (still TripleO of course), including my
> position at the Technical Committee.
>
> Thanks all for your trust, your patience, your tolerance and more than
> anything else: your hard work.
> I'm looking forward to continuing this adventure :-)
> --
> Emilien Macchi
>
> __
> 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] [tc][kolla] Distribute Ansible module with Kolla

[Steven Dake]

Doung,

The TC cannot provide legal advice as they are not attorneys (forgive me if
there are TC members that also have legal credentials coupled with a legal
degree).  I'd suggest contacting your specific companies legal counsel.  If
that doesn't yield results, you might try the legal list.

The dev mailer is no place for this discussion.

Regards
-steve


On Mon, Jul 31, 2017 at 11:06 PM, duon...@vn.fujitsu.com <
duon...@vn.fujitsu.com> wrote:

> Cross-post from [1]
>
> Hello everyone,
>
> I'm looking for legal advice about distribute Ansible module within Kolla.
> In order to implement one feature in Kolla, I need developing one
> Ansible strategy plugin, which in turn need to include and inherit from
> a couple modules from Ansible. Kolla does not use the plugin directly,
> but Kolla will invoke Ansible (through popen) and Ansible uses this plugin.
>
> The question is, can I distribute this plugin along with Kolla-Ansible
> deliverable?
>
> [1] http://lists.openstack.org/pipermail/legal-discuss/2017-
> July/000478.html
>
> Thanks,
>
> Ha Quang Duong (Mr.)
> IRC 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
>
__
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] [relmgt] Non-candidacy for the Queens cycle Release management PTL

[Steven Dake]

On Thu, Jul 27, 2017 at 6:58 AM, Doug Hellmann 
wrote:

> Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500:
> > >
> > > I have multiple reasons for not running this cycle. First, as part of
> my
> > > expanded role at the Foundation my travel commitments increased a bit.
> > > The Release management PTL role requires regular work: I ended up doing
> > > a relatively bad job at PTLing this cycle, by being away during a
> number
> > > of critical weeks. Fortunately, I could count on the presence of the
> > > other team members (especially dhellmann and dims) to keep things under
> > > control!
> >
> > Thank you Thierry and team for the great work. Depite what you say, I
> > don't think anyone has felt the impact, so - great job!
> >
> > Sean
> >
>
> +1 to that -- With your guidance we have solidified the processes
> the team uses so well that we can all share the load. That's exactly
> the sort of situation we need for all of our cross-project teams.
>
> Doug
>
>
+2

The release management team has managed to automate and nearly fully
distribute the workload across the various teams working on OpenStack
projects and their deliverables.

A huge improvement from where PTLs in Mitaka and prior were manually
tagging and signing deliverables, handling the release note process, and
all other sorts of minutia that required extreme care and focus.

A fine example of cross project team collaboration.

Regards
-steve


> __
> 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] [ironic] Looking for a good end-to-end demo of ironic integrated within openstack

[Steven Dake]

Greg,

This may not be exactly what your looking for but close.  (Ocata - NB no
inspector implementation)

Ocata video (no audio):
https://www.youtube.com/watch?v=rHCCUP2odd8=52s

Or check out this more extensive (with audio track) video of real-world
usage of ironic:
https://www.youtube.com/watch?v=V389ecbzjFs

Regards
-steve

On Thu, Jul 20, 2017 at 7:44 AM, Waines, Greg 
wrote:

> hey there,
>
>
>
> I’m an ironic newbie ...
>
> where can I find a good / relatively-current (e.g. PIKE) demo of Ironic
> integrated within OpenStack ?
>
>
>
> Greg.
>
> __
> 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] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

[Steven Dake]

On Mon, Jul 17, 2017 at 10:13 AM, Emilien Macchi  wrote:

> On Mon, Jul 17, 2017 at 5:32 AM, Flavio Percoco  wrote:
> > On 14/07/17 08:08 -0700, Emilien Macchi wrote:
> >>
> >> On Fri, Jul 14, 2017 at 2:17 AM, Flavio Percoco 
> wrote:
> >>>
> >>>
> >>> Greetings,
> >>>
> >>> As some of you know, I've been working on the second phase of TripleO's
> >>> containerization effort. This phase if about migrating the docker based
> >>> deployment onto Kubernetes.
> >>>
> >>> These phase requires work on several areas: Kubernetes deployment,
> >>> OpenStack
> >>> deployment on Kubernetes, configuration management, etc. While I've
> been
> >>> diving
> >>> into all of these areas, this email is about the second point,
> OpenStack
> >>> deployment on Kubernetes.
> >>>
> >>> There are several tools we could use for this task. kolla-kubernetes,
> >>> openstack-helm, ansible roles, among others. I've looked into these
> tools
> >>> and
> >>> I've come to the conclusion that TripleO would be better of by having
> >>> ansible
> >>> roles that would allow for deploying OpenStack services on Kubernetes.
> >>>
> >>> The existing solutions in the OpenStack community require using Helm.
> >>> While
> >>> I
> >>> like Helm and both, kolla-kubernetes and openstack-helm OpenStack
> >>> projects,
> >>> I
> >>> believe using any of them would add an extra layer of complexity to
> >>> TripleO,
> >>> which is something the team has been fighting for years years -
> >>> especially
> >>> now
> >>> that the snowball is being chopped off.
> >>>
> >>> Adopting any of the existing projects in the OpenStack communty would
> >>> require
> >>> TripleO to also write the logic to manage those projects. For example,
> in
> >>> the
> >>> case of openstack-helm, the TripleO team would have to write either
> >>> ansible
> >>> roles or heat templates to manage - install, remove, upgrade - the
> charts
> >>> (I'm
> >>> happy to discuss this point further but I'm keepping it at a high-level
> >>> on
> >>> purpose for the sake of not writing a 10k-words-long email).
> >>>
> >>> James Slagle sent an email[0], a couple of days ago, to form TripleO
> >>> plans
> >>> around ansible. One take-away from this thread is that TripleO is
> >>> adopting
> >>> ansible more and more, which is great and it fits perfectly with the
> >>> conclusion
> >>> I reached.
> >>>
> >>> Now, what this work means is that we would have to write an ansible
> role
> >>> for
> >>> each service that will deploy the service on a Kubernetes cluster.
> >>> Ideally
> >>> these
> >>> roles will also generate the configuration files (removing the need of
> >>> puppet
> >>> entirely) and they would manage the lifecycle. The roles would be
> >>> isolated
> >>> and
> >>> this will reduce the need of TripleO Heat templates. Doing this would
> >>> give
> >>> TripleO full control on the deployment process too.
> >>>
> >>> In addition, we could also write Ansible Playbook Bundles to contain
> >>> these
> >>> roles
> >>> and run them using the existing docker-cmd implementation that is
> coming
> >>> out
> >>> in
> >>> Pike (you can find a PoC/example of this in this repo[1]).
> >>>
> >>> Now, I do realize the amount of work this implies and that this is my
> >>> opinion/conclusion. I'm sending this email out to kick-off the
> discussion
> >>> and
> >>> gather thoughts and opinions from the rest of the community.
> >>>
> >>> Finally, what I really like about writing pure ansible roles is that
> >>> ansible
> >>> is
> >>> a known, powerfull, tool that has been adopted by many operators
> already.
> >>> It'll
> >>> provide the flexibility needed and, if structured correctly, it'll
> allow
> >>> for
> >>> operators (and other teams) to just use the parts they need/want
> without
> >>> depending on the full-stack. I like the idea of being able to separate
> >>> concerns
> >>> in the deployment workflow and the idea of making it simple for users
> of
> >>> TripleO
> >>> to do the same at runtime. Unfortunately, going down this road means
> that
> >>> my
> >>> hope of creating a field where we could collaborate even more with
> other
> >>> deployment tools will be a bit limited but I'm confident the result
> would
> >>> also
> >>> be useful for others and that we all will benefit from it... My hopes
> >>> might
> >>> be a
> >>> bit naive *shrugs*
> >>
> >>
> >> Of course I'm biased since I've been (a little) involved in that work
> >> but I like the idea of :
> >>
> >> - Moving forward with our containerization. docker-cmd will help us
> >> for sure for this transition (I insist on the fact TripleO is a
> >> product that you can upgrade and we try to make it smooth for our
> >> operators), so we can't just trash everything and switch to a new
> >> tool. I think the approach that we're taking is great and made of baby
> >> steps where we try to solve different problems.
> >> - Using more Ansible - the right way - when it makes sense : with the
> 

Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

[Steven Dake]

On Fri, Jul 14, 2017 at 10:26 AM, James Slagle 
wrote:

> On Fri, Jul 14, 2017 at 12:16 PM, Fox, Kevin M  wrote:
> > https://xkcd.com/927/
>
> That's cute, but we aren't really trying to have competing standards.
> It's not really about competition between tools.
>
> > I don't think adopting helm as a dependency adds more complexity then
> writing more new k8s object deployment tooling?
>
> That depends, and will likely end up containing a fair amount of
> subjectivity. What we're trying to do is explore choices around
> tooling.
>
> >
> > There are efforts to make it easy to deploy kolla-kubernetes
> microservice charts using ansible for orchestration in kolla-kubernetes.
> See:
> > https://review.openstack.org/#/c/473588/
> > What kolla-kubernetes brings to the table is a tested/shared base k8s
> object layer. Orchestration is done by ansible via TripleO, and the
> solutions already found/debugged to how to deploy OpenStack in containers
> on Kubernetes can be reused/shared.
>
> That's good, and we'd like to reuse existing code and patterns. I
> admit to not being super famliliar with kolla-kubernetes. Are there
> reusable components without having to also use Helm?
>
> > See for example:
> > https://github.com/tripleo-apb/ansible-role-k8s-keystone/blob/
> 331f405bd3f7ad346d99e964538b5b27447a0ebf/provision-keystone-
> apb/tasks/main.yaml
>
> Pretty sure that was just a POC/example.
>
> >
> > I don't see much by way of dealing with fernet token rotation. That was
> a tricky bit of code to get to work, but kolla-kubernetes has a solution to
> it. You can get it by: helm install kolla/keystone-fernet-rotate-job.
> >
> > We designed this layer to be shareable so we all can contribute to the
> commons rather then having every project reimplement their own and have to
> chase bugs across all the implementations. The deployment projects will be
> stronger together if we can share as much as possible.
> >
> > Please reconsider. I'd be happy to talk with you more if you want.
>
> James,


> Just to frame the conversation with a bit more context, I'm sure there
> are many individual features/bugs/special handling that TripleO and
> Kolla both do today that the other does not.
>
>
I think what you are saying in a nutshell is that TripleO and Kolla compete.


> TripleO had about a 95% solution for deploying OpenStack when
> kolla-ansible did not exist and was started from scratch. But, kolla
> made a choice based around tooling, which I contend is perfectly valid
> given that we are creating deployment tools. Part of the individual
> value in each deployment project is the underlying tooling itself.
>
>
I think what you are saying here is Kolla chose to compete on tooling.  I
haven't really given it a lot of thought; I'd say all are technical choices
made with Kolla had mostly to do with selecting wisely from the technical
ecosystem.


> I think what TripleO is trying to do here is not immediately jump to a
> solution that uses Helm and explore what alternatives exist. Even if
> the project chooses not to use Helm I still see room for collaboration
> on code beneath the Helm/whatever layer.
>
>
I believe it wise that you don't jump to any conclusion or solution that
does or doesn't use Helm.  I'd encourage you to understand how Kubernetes
works before making such technical choices.

All that said, there is clearly value in working together rather than
apart.  To me, that is more important then the technical choices you are
presented with.

Regards
-steve


> --
> -- James Slagle
> --
>
> __
> 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] [kolla] Looking for Docker images for Cinder, Glance etc for oVirt

[Steven Dake (stdake)]

Leni,

Reading their website, they reference the “kollagllue’ namespace.  That hasn’t 
been used for 2+ years (we switched to kolla).  They also said a “recent” 
change in the imges was made to deploy via Ansible “and they weren’t ready for 
that yet”.  That was 3 years ago.  I think those docs are all pretty old and 
could use some validation from the ovirt folks.

-Original Message-
From: Leni Kadali Mutungi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, July 8, 2017 at 11:03 AM
To: openstack-dev , "de...@ovirt.org" 

Cc: users 
Subject: [openstack-dev] [kolla] Looking for Docker images for Cinder,  Glance 
etc for oVirt

Hello all.

I am trying to use the Cinder and Glance Docker images you provide in
relation to the setup here:

http://www.ovirt.org/develop/release-management/features/cinderglance-docker-integration/

I tried to run `sudo docker pull
kollaglue/centos-rdo-glance-registry:latest` and got an error of not
found. I thought that it could possible to use a Dockerfile to spin up
an equivalent of it, so I would like some guidance on how to go about
doing that. Best practices and so on. Alternatively, if it is
possible, may you point me in the direction of the equivalent images
mentioned in the guides if they have been superseded by something else? 
Thanks.

CCing the oVirt users and devel lists to see if anyone has experienced
something similar.

--
- Warm regards
Leni Kadali Mutungi

__
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] [all][tc] How to deal with confusion around "hosted projects"

[Steven Dake]

Agree.

Regards
-steve

On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 06/28/2017 11:27 PM, Steven Dake wrote:
>
>
>>
>> On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <mord...@inaugust.com
>> <mailto:mord...@inaugust.com>> wrote:
>>
>> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC
>> workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The
>> thread went
>> in a lot of directions, including discussing GitHub mirroring
>> strategy,
>> what makes projects want to be official, the need for returning
>> to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>> <http://lists.openstack.org/pipermail/openstack-dev/2017-Jun
>> e/118368.html>
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we
>> should stop
>> using it. The issue is, merely stopping using it won't be enough.
>> We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to
>> see what
>> is a part of OpenStack and what's not. If you google "openstack
>> machine
>> learning", the first hits are Cognitive and Meteos, and it's
>> impossible
>> to tell that those are actually not OpenStack projects. One of
>> those has
>> been dead for 2 years -- having people think that those are
>> official
>> projects hurts all the OpenStack projects, by lowering
>> expectations
>> around what that means, in terms of quality, maintenance, or
>> community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's
>> nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even
>> with the
>> expansive "are you one of us" definition. Arguably the most
>> confusing
>> aspect is the "openstack/" prefix in the git repository name,
>> which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue
>> on the
>> edges, or you can treat the root cause. Neither of those options
>> is
>> really an OpenStack  governance change (or "big tent" change) --
>> they
>> are more about what to do with things that are actually *not* in
>> our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer
>> when
>> things are not official. The thread above discussed a lot of
>> potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could
>> find a
>> way to tag all projects on GitHub that are not official, or
>> mirror them
>> to another organization, or stop mirroring them altogether. We
>> could
>> remove the openstack/ prefix from all the projects we host. We
>> could
>> actively mark all wiki pages that are not about an official
>> project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is
>> that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop
>> offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> al

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Steven Dake]

On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor  wrote:

> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>
>> Hi everyone,
>>
>> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
>> working on "better communicating what is openstack", I started a
>> thread[1] about moving away from big tent terminology. The thread went
>> in a lot of directions, including discussing GitHub mirroring strategy,
>> what makes projects want to be official, the need for returning to a
>> past when everything was (supposedly) simpler, and naming fun.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June
>> /118368.html
>>
>> Many agreed that the "Big Tent" name (as a synonym to "official
>> openstack projects") is hurting more than it helps, and we should stop
>> using it. The issue is, merely stopping using it won't be enough. We
>> have tried, and the name sticks. You need to replace the name by
>> something that sticks more, or address the root cause directly.
>>
>> The central issue being discussed here is an issue of external
>> perception. It's hard for newcomers to the OpenStack world to see what
>> is a part of OpenStack and what's not. If you google "openstack machine
>> learning", the first hits are Cognitive and Meteos, and it's impossible
>> to tell that those are actually not OpenStack projects. One of those has
>> been dead for 2 years -- having people think that those are official
>> projects hurts all the OpenStack projects, by lowering expectations
>> around what that means, in terms of quality, maintenance, or community.
>>
>> The confusion mainly stems from the fact that OpenStack project
>> infrastructure is open to any open source project (and it's nobody's job
>> to clean up dead things). So you can find (on our wiki, on our
>> mailing-list, on our cgit farm, on our gerrit, on our GitHub
>> organization...) things that are actually not OpenStack, even with the
>> expansive "are you one of us" definition. Arguably the most confusing
>> aspect is the "openstack/" prefix in the git repository name, which
>> indicates some kind of brand association.
>>
>> I'd say we have two options. We can address the perception issue on the
>> edges, or you can treat the root cause. Neither of those options is
>> really an OpenStack  governance change (or "big tent" change) -- they
>> are more about what to do with things that are actually *not* in our
>> governance.
>>
>> Addressing the perception on the edges means making it clearer when
>> things are not official. The thread above discussed a lot of potential
>> solutions. We could give unofficial things a catchy group name
>> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
>> way to tag all projects on GitHub that are not official, or mirror them
>> to another organization, or stop mirroring them altogether. We could
>> remove the openstack/ prefix from all the projects we host. We could
>> actively mark all wiki pages that are not about an official project. We
>> could set up a separate Gerrit or separate ML for hosted projects
>> development discussions. The main issue with that approach is that it's
>> a *lot* of work, and it never completely eliminates the confusion.
>>
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>
> I disagree that this is removing the root cause.
>
> I believe this is reacting to a misunderstanding by hiding from it. I do
> not believe that doing this provides any value to us as a community.
>
> Even though we do not actually use github for development, we have
> implicitly accepted the false premise that github is a requirement. It is
> suggested that the existence of git repos in the openstack/ github org is
> confusing to people. And our reaction to that is to cut off access to our
> Open Source tools that we set up to collaboratively develop cloud software
> and tell people to go use the thing that people suggest is one of the
> causes of people being confused?
>
> * People are not 'confused' by what OpenStack is.
>
> Being "confused" is a passive-aggressive way of expressing that they
> DISAGREE with what OpenStack is. We still have _plenty_ of people who
> express that they think we should only be IaaS - so they're still going to
> be unhappy with cloudkitty, congress and karbor.
>

Monty,

I think you are right on the money on this second point although it is
missing a salient point.  There really are two problems here.

If we as a community disagree about the answer "What is OpenStack?" how
should we expect a Google search to answer this question for us?  Most
people that have been working on OpenStack for a long time might agree
there is a "common core" of projects that make up OpenStack.  I'll call
this as what you refer to as "OpenStack should only be an 

Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

[Steven Dake (stdake)]

Doug,

In short, a configmap takes a bunch of config files, bundles them in a 
kubernetes object called a configmap, and then ships them to etcd.  When a pod 
is launched, the pod mounts the configmaps using tmpfs and the raw config files 
are available for use by the openstack services.

Operating on configmaps is much simpler and safer than using a different 
backing database for the configuration data.

Hope the information helps.

Ping me in #openstack-kolla if you have more questions.

Regards
-steve


-Original Message-
From: Doug Hellmann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, June 8, 2017 at 10:12 AM
To: openstack-dev 
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla]
[helm] Configuration management with etcd / confd

Excerpts from Flavio Percoco's message of 2017-06-08 18:27:51 +0200:
> On 08/06/17 18:23 +0200, Flavio Percoco wrote:
> >On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote:
> >>On 06.06.2017 18:08, Emilien Macchi wrote:
> >>>Another benefit is that confd will generate a configuration file when
> >>>the application will start. So if etcd is down *after* the app
> >>>startup, it shouldn't break the service restart if we don't ask confd
> >>>to re-generate the config. It's good for operators who were concerned
> >>>about the fact the infrastructure would rely on etcd. In that case, we
> >>>would only need etcd at the initial deployment (and during lifecycle
> >>>actions like upgrades, etc).
> >>>
> >>>The downside is that in the case of containers, they would still have
> >>>a configuration file within the container, and the whole goal of this
> >>>feature was to externalize configuration data and stop having
> >>>configuration files.
> >>
> >>It doesn't look a strict requirement. Those configs may (and should) be
> >>bind-mounted into containers, as hostpath volumes. Or, am I missing
> >>something what *does* make embedded configs a strict requirement?..
> >
> >mmh, one thing I liked about this effort was possibility of stop 
bind-mounting
> >config files into the containers. I'd rather find a way to not need any
> >bindmount and have the services get their configs themselves.
> 
> Probably sent too early!
> 
> If we're not talking about OpenStack containers running in a COE, I guess 
this
> is fine. For k8s based deployments, I think I'd prefer having installers
> creating configmaps directly and use that. The reason is that depending 
on files
> that are in the host is not ideal for these scenarios. I hate this idea 
because
> it makes deployments inconsistent and I don't want that.
> 
> Flavio
> 

I'm not sure I understand how a configmap is any different from what is
proposed with confd in terms of deployment-specific data being added to
a container before it launches. Can you elaborate on that?

Doug

__
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] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

[Steven Dake (stdake)]

Flavio,

Atleast for the kubernetes variant of kolla, bindmounting will always be used 
as this is fundamentally how configmaps operate.  In order to maintain maximum 
flexilbility and compatibility with kubernetes, I am not keen to try a 
non-configmap way of doing things.

Regards
-steve

-Original Message-
From: Flavio Percoco 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, June 8, 2017 at 9:23 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] 
[helm] Configuration management with etcd / confd

On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote:
>On 06.06.2017 18:08, Emilien Macchi wrote:
>> Another benefit is that confd will generate a configuration file when
>> the application will start. So if etcd is down *after* the app
>> startup, it shouldn't break the service restart if we don't ask confd
>> to re-generate the config. It's good for operators who were concerned
>> about the fact the infrastructure would rely on etcd. In that case, we
>> would only need etcd at the initial deployment (and during lifecycle
>> actions like upgrades, etc).
>>
>> The downside is that in the case of containers, they would still have
>> a configuration file within the container, and the whole goal of this
>> feature was to externalize configuration data and stop having
>> configuration files.
>
>It doesn't look a strict requirement. Those configs may (and should) be
>bind-mounted into containers, as hostpath volumes. Or, am I missing
>something what *does* make embedded configs a strict requirement?..

mmh, one thing I liked about this effort was possibility of stop 
bind-mounting
config files into the containers. I'd rather find a way to not need any
bindmount and have the services get their configs themselves.

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

Re: [openstack-dev] [tc][kolla][stable][security][infra][all] guidelines for managing releases of binary artifacts

[Steven Dake (stdake)]

Doug,

Thanks for the resolution.  It is well written and sets appropriate guidelines. 
 I was expecting something terrible – I guess I shouldn’t have expectations 
ahead of a resolution.  Apologies for being a jerk on the ml.

Nice work.

I left some commentary in the review and left a vote of -1 (just a few things 
need tidying, not a -1 of the concept in general).

Regards
-steve


-Original Message-
From: Doug Hellmann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, May 30, 2017 at 2:54 PM
To: openstack-dev 
Subject: [openstack-dev] [tc][kolla][stable][security][infra][all]  
guidelines for managing releases of binary artifacts

Based on two other recent threads [1][2] and some discussions on
IRC, I have written up some guidelines [3] that try to address the
concerns I have with us publishing binary artifacts while still
allowing the kolla team and others to move ahead with the work they
are trying to do.

I would appreciate feedback about whether these would complicate
builds or make them impossible, as well as whether folks think they
go far enough to mitigate the risks described in those email threads.

Doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-May/116677.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117282.html
[3] https://review.openstack.org/#/c/469265/

__
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] [TripleO][Kolla] default docker storage backend for TripleO

[Steven Dake (stdake)]

My experience with BTRFS has been flawless.  My experience with overlayfs is 
that occasionally (older centos kernels) returned  as permissions 
(rather the drwxrwrw).  This most often happened after using the yum overlay 
driver.  I’ve found overlay to be pretty reliable as a “read-only” filesystem – 
eg just serving up container images, not persistent storage.

YMMV.  Overlayfs is the long-term filesystem of choice for the use case you 
outlined.  I’ve heard overlayfs has improved over the last year in terms of 
backport quality so maybe it is approaching ready.

Regards
-steve


From: Steve Baker 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, May 17, 2017 at 7:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
, "dwa...@redhat.com" 
Subject: Re: [openstack-dev] [TripleO][Kolla] default docker storage backend 
for TripleO



On Thu, May 18, 2017 at 12:38 PM, Fox, Kevin M 
> wrote:
I've only used btrfs and devicemapper on el7. btrfs has worked well. 
devicemapper ate may data on multiple occasions. Is redhat supporting overlay 
in the el7 kernels now?

overlay2 is documented as a Technology Preview graph driver in the Atomic Host 
7.3.4 release notes:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/release_notes/



_
From: Dan Prince [dpri...@redhat.com]
Sent: Wednesday, May 17, 2017 5:24 PM
To: openstack-dev
Subject: [openstack-dev] [TripleO][Kolla] default docker storage backend for
TripleO

TripleO currently uses the default "loopback" docker storage device.
This is not recommended for production (see 'docker info').

We've been poking around with docker storage backends in TripleO for
almost 2 months now here:

 https://review.openstack.org/#/c/451916/

For TripleO there are a couple of considerations:

 - we intend to support in place upgrades from baremetal to containers

 - when doing in place upgrades re-partitioning disks is hard, if not
impossible. This makes using devicemapper hard.

 - we'd like to to use a docker storage backend that is production
ready.

 - our target OS is latest Centos/RHEL 7

As we approach pike 2 I'm keen to move towards a more production docker
storage backend. Is there consensus that 'overlay2' is a reasonable
approach to this? Or is it too early to use that with the combinations
above?

Looking around at what is recommended in other projects it seems to be
a mix as well from devicemapper to btrfs.

[1] https://docs.openshift.com/container-platform/3.3/install_config/in
stall/host_preparation.html#configuring-docker-storage
[2] http://git.openstack.org/cgit/openstack/kolla/tree/tools/setup_RedH
at.sh#n30

I'd love to be able to use overlay2. I've CCed Daniel Walsh with the hope we 
can get a general overview of the maturity of overlay2 on rhel/centos.

I tried using overlay2 recently to create an undercloud and hit an issue doing 
a "cp -a *" on deleted files. This was with kernel-3.10.0-514.16.1 and 
docker-1.12.6.

I want to get to the bottom of it so I'll reproduce and raise a bug as 
appropriate.
__
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][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

[Steven Dake (stdake)]

Doug,

When a docker image is pushed to dockerhub (or quay.io, etc) a tag is 
specified.  If the tag already exists, it is overwritten.

Regards
-steve

-Original Message-
From: Doug Hellmann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, May 17, 2017 at 8:55 AM
To: openstack-dev 
Subject: Re: [openstack-dev]
[tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes]
do we want to be publishing binary container images?

Excerpts from Chris Dent's message of 2017-05-17 12:14:40 +0100:
> On Wed, 17 May 2017, Thierry Carrez wrote:
> 
> > Back to container image world, if we refresh those images daily and they
> > are not versioned or archived (basically you can only use the latest and
> > can't really access past dailies), I think we'd be in a similar 
situation ?
> 
> Yes, this.
> 

Is that how container publishing works? Can we overwrite an existing
archive, so that there is only ever 1 version of a published container
at any given time?

Doug

__
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] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

[Steven Dake (stdake)]

Michael,

There has been a lot of cost and risk analysis in this thread.

What hasn’t really been discussed at great detail is the “benefit analysis” 
which you have started.  I think we are all clear on the risks and the costs.

If we as a technical community are going to place a line in the sand and state 
“thou shall not ship containers to dockerhub” because of the risks inherent in 
such behavior, we are not integrating properly with the emerging container 
ecosystem.  Expecting operators to build their own images is a viable path 
forward.  Unfortunately, the lack of automation introduces significant 
cognitive load for many (based upon the Q in the #openstack-kolla channel on 
a daily basis).  This cognitive load could be (incorrectly) perceived by many 
to be “OpenStack doesn’t care about integrating with adjacent communities.”

On balance, the benefits to OpenStack of your proposal outweigh the costs.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, May 17, 2017 at 7:47 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] 
[tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes]
 do we want to be publishing binary container images?

On 17 May 2017 at 04:14, Chris Dent  wrote:
> On Wed, 17 May 2017, Thierry Carrez wrote:
>
>> Back to container image world, if we refresh those images daily and they
>> are not versioned or archived (basically you can only use the latest and
>> can't really access past dailies), I think we'd be in a similar situation
>> ?
>
>
> Yes, this.

I think it's not a bad idea to message "you are responsible for
archving your containers". Do that, combine it with good toolset that
helps users determine versions of packages and other metadata and
we'll end up with something that itself would be greatly appreciated.

Few potential user stories.

I have OpenStack <100 nodes and need every single one of them, hence
no CI. At the same time I want to have fresh packages to avoid CVEs. I
deploy kolla with tip-of-the-stable-branch and setup cronjob that will
upgrade it every week. Because my scenerio is quite typical and
containers already ran through gates that tests my scenerio, I'm good.

Another one:

I have 300+ node cloud, heavy CI and security team examining every
container. While I could build containers locally, downloading them is
just simpler and effectively the same (after all, it's containers
being tested not build process). Every download our security team
scrutinize contaniers and uses toolset Kolla provides to help them.
Additional benefit is that on top of our CI these images went through
Kolla CI which is nice, more testing is always good.

And another one

We are Kolla community. We want to provide testing for full release
upgrades every day in gates, to make sure OpenStack and Kolla is
upgradable and improve general user experience of upgrades. Because
infra is resource constrained, we cannot afford building 2 sets of
containers (stable and master) and doing deploy->test->upgrade->test.
However because we have these cached containers, that are fresh and
passed CI for deploy, we can just use them! Now effectively we're not
only testing Kolla's correctness of upgrade procedure but also all the
other project team upgrades! Oh, it seems Nova merged something that
negatively affects upgrades, let's make sure they are aware!

And last one, which cannot be underestimated

I am CTO of some company and I've heard OpenStack is no longer hard to
deploy, I'll just download kolla-ansible and try. I'll follow this
guide that deploys simple OpenStack with 2 commands and few small
configs, and it's done! Super simple! We're moving to OpenStack and
start contributing tomorrow!

Please, let's solve messaging problems, put burden of archiving on
users, whatever it takes to protect our community from wrong
expectations, but not kill this effort. There are very real and
immediate benefits to OpenStack as a whole if we do this.

Cheers,
Michal

> --
> Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

[Steven Dake (stdake)]

Dims,

The [tc] was in the subject tag, and the message was represented as indicating 
some TC directive and has had several tc members comment on the thread.  I did 
nothing wrong.

Regards
-steve


-Original Message-
From: Davanum Srinivas <dava...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, May 16, 2017 at 4:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] 
[tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes]
 do we want to be publishing binary container images?

Why drag TC into this discussion Steven? If the TC has something to
say, it will be in the form of a resolution with topic "formal-vote".
So please Stop!

Thanks,
Dims
    
    On Tue, May 16, 2017 at 12:22 AM, Steven Dake (stdake) <std...@cisco.com> 
wrote:
> Flavio,
>
> Forgive the top post – outlook ftw.
>
> I understand the concerns raised in this thread.  It is unclear if this 
thread is the feeling of two TC members or enough TC members care deeply about 
this issue to permanently limit OpenStack big tent projects’ ability to 
generate container images in various external artifact storage systems.  The 
point of discussion I see effectively raised in this thread is “OpenStack infra 
will not push images to dockerhub”.
>
> I’d like clarification if this is a ruling from the TC, or simply an 
exploratory discussion.
>
> If it is exploratory, it is prudent that OpenStack projects not be 
blocked by debate on this issue until the TC has made such ruling as to banning 
the creation of container images via OpenStack infrastructure.
>
> Regards
> -steve
>
> -Original Message-
> From: Flavio Percoco <fla...@redhat.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
> Date: Monday, May 15, 2017 at 7:00 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] 
[tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes]
 do we want to be publishing binary container images?
>
> On 15/05/17 12:32 -0700, Michał Jastrzębski wrote:
> >On 15 May 2017 at 12:12, Doug Hellmann <d...@doughellmann.com> wrote:
>
> [huge snip]
>
> >>> > I'm raising the issue here to get some more input into how to
> >>> > proceed. Do other people think this concern is overblown? Can we
> >>> > mitigate the risk by communicating through metadata for the 
images?
> >>> > Should we stick to publishing build instructions (Dockerfiles, 
or
> >>> > whatever) instead of binary images? Are there other options I 
haven't
> >>> > mentioned?
> >>>
> >>> Today we do publish build instructions, that's what Kolla is. We 
also
> >>> publish built containers already, just we do it manually on 
release
> >>> today. If we decide to block it, I assume we should stop doing 
that
> >>> too? That will hurt users who uses this piece of Kolla, and I'd 
hate
> >>> to hurt our users:(
> >>
> >> Well, that's the question. Today we have teams publishing those
> >> images themselves, right? And the proposal is to have infra do it?
> >> That change could be construed to imply that there is more of a
> >> relationship with the images and the rest of the community 
(remember,
> >> folks outside of the main community activities do not always make
> >> the same distinctions we do about teams). So, before we go ahead
> >> with that, I want to make sure that we all have a chance to discuss
> >> the policy change and its implications.
> >
> >Infra as vm running with infra, but team to publish it can be Kolla
> >team. I assume we'll be responsible to keep these images healthy...
>
> I think this is the gist of the concern and I'd like us to focus on 
it.
>
> As someone that used to consume these images from kolla's dockerhub 
account
> directly, I can confirm they are useful. However, I do share Doug's 
concern and
> the impact this may have on the community.
>
> From a release perspective

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

[Steven Dake (stdake)]

Flavio,

Forgive the top post – outlook ftw.

I understand the concerns raised in this thread.  It is unclear if this thread 
is the feeling of two TC members or enough TC members care deeply about this 
issue to permanently limit OpenStack big tent projects’ ability to generate 
container images in various external artifact storage systems.  The point of 
discussion I see effectively raised in this thread is “OpenStack infra will not 
push images to dockerhub”.

I’d like clarification if this is a ruling from the TC, or simply an 
exploratory discussion.

If it is exploratory, it is prudent that OpenStack projects not be blocked by 
debate on this issue until the TC has made such ruling as to banning the 
creation of container images via OpenStack infrastructure.

Regards
-steve

-Original Message-
From: Flavio Percoco 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, May 15, 2017 at 7:00 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] 
[tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes]
 do we want to be publishing binary container images?

On 15/05/17 12:32 -0700, Michał Jastrzębski wrote:
>On 15 May 2017 at 12:12, Doug Hellmann  wrote:

[huge snip]

>>> > I'm raising the issue here to get some more input into how to
>>> > proceed. Do other people think this concern is overblown? Can we
>>> > mitigate the risk by communicating through metadata for the images?
>>> > Should we stick to publishing build instructions (Dockerfiles, or
>>> > whatever) instead of binary images? Are there other options I haven't
>>> > mentioned?
>>>
>>> Today we do publish build instructions, that's what Kolla is. We also
>>> publish built containers already, just we do it manually on release
>>> today. If we decide to block it, I assume we should stop doing that
>>> too? That will hurt users who uses this piece of Kolla, and I'd hate
>>> to hurt our users:(
>>
>> Well, that's the question. Today we have teams publishing those
>> images themselves, right? And the proposal is to have infra do it?
>> That change could be construed to imply that there is more of a
>> relationship with the images and the rest of the community (remember,
>> folks outside of the main community activities do not always make
>> the same distinctions we do about teams). So, before we go ahead
>> with that, I want to make sure that we all have a chance to discuss
>> the policy change and its implications.
>
>Infra as vm running with infra, but team to publish it can be Kolla
>team. I assume we'll be responsible to keep these images healthy...

I think this is the gist of the concern and I'd like us to focus on it.

As someone that used to consume these images from kolla's dockerhub account
directly, I can confirm they are useful. However, I do share Doug's concern 
and
the impact this may have on the community.

From a release perspective, as Doug mentioned, we've avoided releasing 
projects
in any kind of built form. This was also one of the concerns I raised when
working on the proposal to support other programming languages. The problem 
of
releasing built images goes beyond the infrastructure requirements. It's the
message and the guarantees implied with the built product itself that are 
the
concern here. And I tend to agree with Doug that this might be a problem 
for us
as a community. Unfortunately, putting your name, Michal, as contact point 
is
not enough. Kolla is not the only project producing container images and we 
need
to be consistent in the way we release these images.

Nothing prevents people for building their own images and uploading them to
dockerhub. Having this as part of the OpenStack's pipeline is a problem.

Flavio

P.S: note this goes against my container(ish) interests but it's a
community-wide problem.

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

Re: [openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

[Steven Dake (stdake)]

+1


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, May 2, 2017 at 8:30 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla][kolla-ansible] Proposing Bertrand Lallau for 
kolla and kolla-ansible core

Hello,

It's my pleasure to start another core reviewer vote. Today it's
Bertrand (blallau). Consider this mail my +1 vote. Members of
kolla-ansible and kolla core team, please cast your votes:) Voting
will be open for 2 weeks (until 16th of May).

I also wanted to say that Bertrand went through our core mentorship
program (if only for few weeks because he did awesome job before too)
:)

Thank you,
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

Re: [openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

[Steven Dake (stdake)]

Monty,

I guess the obligatory joke “It is going to be a Rocky release ahead!” must be 
made. \o/

Regards
-steve


-Original Message-
From: Monty Taylor 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, April 28, 2017 at 2:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
, Openstack Users 

Subject: [openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

Hey everybody!

There isn't a ton more to say past the subject. The "R" release of 
OpenStack shall henceforth be known as "Rocky".

I believe it's the first time we've managed to name a release after a 
community member - so please everyone buy RockyG a drink if you see her 
in Boston.

For those of you who remember the actual election results, you may 
recall that "Radium" was the top choice. Radium was judged to have legal 
risk, so as per our name selection process, we moved to the next name on 
the list.

Monty

__
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] [kolla] OpenStack Kolla-Kubernetes Workshop: Demystifying the Gate - video conferencing information

[Steven Dake (stdake)]

Sasikiran,

Webex audio is sufficient for me – this is what I use all the time.  A headset 
helps, however.

For those that must dial in, the global dial-in is here: 
https://cisco.webex.com/cmp3200/webcomponents/widget/globalcallin/globalcallin.do?serviceType=MC=MC=MC=MC=383520252=383520252=383520252=383520252=1=1=1=1=ciscosales=ciscosales=ciscosales=globalcallin.php=globalcallin.php=globalcallin.php=false=false=false=2015755778=2015755778=2015755778=cmp3200=cmp3200=/webcomponents/widget/globalcallin/gcnredirector.do=/webcomponents/widget/globalcallin/gcnredirector.do=0
Those are listed as “toll” # ‘s but some may be local to you.

Regards
-steve




From: sasi kiran <sasikiran2...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, April 24, 2017 at 6:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] OpenStack Kolla-Kubernetes Workshop: 
Demystifying the Gate - video conferencing information

Hi,
I'm interested to join for this session.
Could you please let us know if there is any tollfree number inorder to call 
from India & Hungary or joining webex is sufficient enough for audio even?
BR,
Sasikiran

On Sun, Apr 23, 2017 at 2:59 AM, Steven Dake (stdake) 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:
As proposed earlier on the mailing list, A 2 week 6 session workshop has been 
organized From April 25th – May 4th Tu/W/Th for 45 minutes in length.

The agenda for this workshop is as follows:

Learn how OpenStack’s kolla-kubernetes gating functions to enable yourself to 
contribute more effectively to kolla-kubernetes.  This workshop will run for 
two weeks on Tuesday, Wednesday and Thursday for 45 minutes beginning April 
25th, 2017 and concluding May 4th, 2017 via Webex.  There is no need to 
actually have a camera; the only purpose of the video conferencing is to share 
a screen.  The workshop will be recorded.

Connection details are below:

I am using Webex for this video conferencing session.  Webex now supports 
Windows, Mac, and Linux.  To connect via Linux, use the web based version of 
Webex (not the client).  For those that can’t install a client, the web based 
version should meet your organization’s security requirements.

If your struggling to join the meeting, please join #openstack-kolla and speak 
up there.

Regards
-stevve

OpenStack Kolla-Kubernetes Workshop: Demystifying the Gate

Every Tuesday, Wednesday, Thursday, from Tuesday, April 25, 2017, to Thursday, 
May 4, 2017

17:00 UTC | 45 minutes

https://cisco.webex.com/ciscosales/j.php?MTID=m726d1915a1fa61470a810c9c9b01a4ef


Meeting number:

202 310 134

Meeting password:

openstack (67367822 from phones)



Join by phone

+1-866-432-9903<tel:(866)%20432-9903> Call-in toll-free number (US/Canada)

+1-408-525-6800<tel:(408)%20525-6800> Call-in toll number (US/Canada)

Access code: 202 310 134

Global call-in 
numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=383520252=1>
  |  Toll-free calling 
restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>





Add this 
meeting<https://cisco.webex.com/ciscosales/j.php?MTID=mcbc11be7ec7607e78d9ec079735bf0bb>
 to your calendar. (Cannot add from mobile devices.)




__
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://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] [kolla] Demystifying the kolla-kubernetes gate

[Steven Dake (stdake)]

Matt,

Anyone in the community is welcome to attend.

I just sent out a mail with the webex connection information.

At the bottom is an “add to calendar” button which (should) add this meeting to 
your calendar.  I haven’t tried this add to calendar button – so the standard 
disclaimer applies ☺

Regards
-steve

From: Matt Young <myo...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, April 20, 2017 at 4:27 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] Demystifying the kolla-kubernetes gate

Is there an invite for this?  I'm interested.

On Apr 19, 2017 1:20 PM, "Steven Dake (stdake)" 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:
Hey folks,

I am holding a workshop on how the kolla-kubernetes gate operates.  If you are 
interested in this workshop, please sign up here:

http://doodle.com/poll/bee7umevf43nwi6y

Regards,
-steve


__
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://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-dev] [kolla] OpenStack Kolla-Kubernetes Workshop: Demystifying the Gate - video conferencing information

[Steven Dake (stdake)]

As proposed earlier on the mailing list, A 2 week 6 session workshop has been 
organized From April 25th – May 4th Tu/W/Th for 45 minutes in length.

The agenda for this workshop is as follows:

Learn how OpenStack’s kolla-kubernetes gating functions to enable yourself to 
contribute more effectively to kolla-kubernetes.  This workshop will run for 
two weeks on Tuesday, Wednesday and Thursday for 45 minutes beginning April 
25th, 2017 and concluding May 4th, 2017 via Webex.  There is no need to 
actually have a camera; the only purpose of the video conferencing is to share 
a screen.  The workshop will be recorded.

Connection details are below:

I am using Webex for this video conferencing session.  Webex now supports 
Windows, Mac, and Linux.  To connect via Linux, use the web based version of 
Webex (not the client).  For those that can’t install a client, the web based 
version should meet your organization’s security requirements.

If your struggling to join the meeting, please join #openstack-kolla and speak 
up there.

Regards
-stevve

OpenStack Kolla-Kubernetes Workshop: Demystifying the Gate

Every Tuesday, Wednesday, Thursday, from Tuesday, April 25, 2017, to Thursday, 
May 4, 2017

17:00 UTC | 45 minutes

https://cisco.webex.com/ciscosales/j.php?MTID=m726d1915a1fa61470a810c9c9b01a4ef


Meeting number:

202 310 134

Meeting password:

openstack (67367822 from phones)



Join by phone

+1-866-432-9903 Call-in toll-free number (US/Canada)

+1-408-525-6800 Call-in toll number (US/Canada)

Access code: 202 310 134

Global call-in 
numbers
  |  Toll-free calling 
restrictions





Add this 
meeting
 to your calendar. (Cannot add from mobile devices.)



__
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] [daisycloud-core] [requirements][magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils

[Steven Dake (stdake)]

Zhijang,

You have a point a view whereby Kolla is never co-installed with other 
OpenStack projects.  I agree I have never heard of this happening.  That 
doesn’t mean it doesn’t happen.

Even given this line of thinking, I have an impossible time rationalizing Kolla 
as a special snowflake.  Kolla conforms (as best as we know how) to OpenStack 
wide processes.

Regards
-steve

From: "hu.zhiji...@zte.com.cn" <hu.zhiji...@zte.com.cn>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, April 19, 2017 at 11:24 PM
To: "hongbin...@gmail.com" <hongbin...@gmail.com>
Cc: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Then IMO,  the global requirements process seems against the intention of 
requirement.txt file. Since requirement.txt is per-project, not global. It is 
(just for example) Zun that treat docker-py-1.8 as a must. As for Kolla, both 
1.6 and 1.8 are OK. Then there is no need to force Kolla to change its 
requirement from "docker-py ＞=1.6.0" to "docker-py ＞=1.8.0" by the global 
requirements process, otherwise,  user may think Kolla really need a newer 
version, kind of easy to be misread.



We know it is valuable to upgrade requirements globally, as it is condusive to 
early bug detection of the co-installation circumstance. But can we not to do 
that detection in each project's CI by write it literally in each project's 
requirement.txt but just upgrade required packages globally in a dedicated CI 
that tests the projects which really need to be co-installed?



B. R.,

Zhijiang
Original Mail
Sender:  ＜hongbin...@gmail.com＞;
To:  ＜openstack-dev@lists.openstack.org＞;
Date: 2017/04/20 12:50
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Zun required docker-py to be 1.8 or higher because older version of docker-py 
didn't have the API we need. Sorry if it caused difficulties on your side but I 
don't think it is feasible to downgrade the version for now since it will 
affect a ton of other projects.
Best regards,
Hongbin

On Thu, Apr 20, 2017 at 12:15 AM, Steven Dake (stdake) 
＜std...@cisco.com<mailto:std...@cisco.com>＞ wrote:
Hu,

Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber stamp changes from the 
global requirements bot assuming  they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.

Taking a look at the specific issues you raised:

Pbr: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158
Here is the change: 
https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c
(from the infrastructure team)

Docker-py: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338
Here is the change: 
https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6
(from the magnum team)

oslo-utils: 
https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136
https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7
(I am not sure which team this is – the oslo team perhaps?)

I would recommend taking the changes up with the requirements team or the 
direct authors.

Regards
-steve



From: "hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>" 
＜hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>＞
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>＞
Date: Wednesday, April 19, 2017 at 8:45 PM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
＜openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>＞
Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils


Hello,



As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] ,

docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on

oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to

generate UUID.



IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to,

and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean

If we keep Kolla's requirement in Ocata as what it was in Newton, upper layer

user of Kolla like daisycloud-core project can still keep other things unchanged

to upgrade Kolla from stable/newton to stable/ocata. Otherwis

Re: [openstack-dev] [kolla] [daisycloud-core] [requirements] [magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils

[Steven Dake (stdake)]

Hu,

Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber stamp changes from the 
global requirements bot assuming they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.

Taking a look at the specific issues you raised:

Pbr: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158
Here is the change: 
https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c
(from the infrastructure team)

Docker-py: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338
Here is the change: 
https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6
(from the magnum team)

oslo-utils: 
https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136
https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7
(I am not sure which team this is – the oslo team perhaps?)

I would recommend taking the changes up with the requirements team or the 
direct authors.

Regards
-steve



From: "hu.zhiji...@zte.com.cn" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 19, 2017 at 8:45 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils


Hello,



As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] ,

docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on

oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to

generate UUID.



IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to,

and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean

If we keep Kolla's requirement in Ocata as what it was in Newton, upper layer

user of Kolla like daisycloud-core project can still keep other things unchanged

to upgrade Kolla from stable/newton to stable/ocata. Otherwise, we have to

upgrade from centos-release-openstack-newton to

centos-release-openstack-ocata(we do not use pip since it conflicts with yum

on files installed by same packages). But this kind of upgrade may be too

invasive that may impacts other applications.



I know that there were some discusstions about global requirements update

these days. So if not really need to do these upgrades by Kolla itself, can

we just keep the requirement unchanged as long as possible?



My 2c.



[1] 
https://github.com/openstack/kolla/commit/2f50beb452918e37dec6edd25c53e407c6e47f53

[2] 
https://github.com/openstack/kolla/commit/85abee13ba284bb087af587b673f4e44187142da

[3] 
https://github.com/openstack/kolla/commit/cee89ee8bef92914036189d02745c08894a9955b











B. R.,

Zhijiang
__
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-dev] [kolla] Demystifying the kolla-kubernetes gate

[Steven Dake (stdake)]

Hey folks,

I am holding a workshop on how the kolla-kubernetes gate operates.  If you are 
interested in this workshop, please sign up here:

http://doodle.com/poll/bee7umevf43nwi6y

Regards,
-steve

__
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][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Ok sounds fair.  I guess I had misunderstood what nova had done, and thought it 
was a path to success.

I’m happy we can have the conversation about a mentorship program now at least 
in the Kolla project.

I’m not sure how to evaluate the cost of the mentorship program in terms of 
core reviewer time.  Perhaps we should start there.  I know core reviewers are 
swamped for bandwidth, however, I also feel making time for mentorship is 
essential to the project’s long term health.

I am also not sure if we have more individuals interested.  If only Rich is 
interested, that is only one person to mentor.  If 100 people are interested, 
that is beyond our capacity as a team to handle ☺

To help sort out the time commitment for core reviewers, I have started a 
“sign-up sheet” for folks interested in mentoring here:
https://etherpad.openstack.org/p/kolla-mentorship-signup

Regards
-steve


From: "Serguei Bezverkhi (sbezverk)" <sbezv...@cisco.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, April 13, 2017 at 8:45 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

The idea is great, no doubt here, meaning mentoring and everything, but it 
should not come with price of reducing quality control. 2 x +2 +w should still 
be required from “regular” cores for PS to merge.

Serguei

From: Richard Wellum [mailto:richwel...@gmail.com]
Sent: Thursday, April 13, 2017 7:02 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

As a relatively new member of the openstack community I think the idea of a 
mentorship program is a good one; I'd like to throw my hat in the ring if the 
kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann 
<mriede...@gmail.com<mailto:mriede...@gmail.com>> wrote:
On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann <mriede...@gmail.com<mailto:mriede...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: 
> "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot to learn
> > from our peers in the OpenStack community and learning from their
>

Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Matt,

Thanks for the response.  It is helpful.

Regards
-steve

-Original Message-
From: Matt Riedemann <mriede...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, April 12, 2017 at 4:36 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> Hey folks,
>
>
>
> In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> “protocore” mentorship program for Kolla.  We would like to know what
> nova has learned from this effort.
>
>
>
> In today’s Kolla meeting we had broad consensus on the following:
>
> 1)   Kolla has participants that want to be core reviewers
>
> 2)   These participants don’t know how to become core reviewers
>
> 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> on how to do good reviews
>
>
>
> From that, we concluded some form of mentorship program for potential
> core reviewers was in order.  We got into some debate about _/how/_ the
> program should be rolled out.  Let’s use this thread to discuss how it
> should be rolled out since that seems to be the sticking point of the
> discussion.  I saw no dissent in the discussion that the basic concepts
> were a negative change.
>
>
>
> I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> from a core reviewer prior to merge.  Nova cores – would you mind
> defining your process (on the ml is fine) more thoroughly and your
> experiences so we can learn from you?
>
>
>
> All kolla contributors, feel free to debate the **how** such a
> mentorship program should be rolled out.  I think we have a lot to learn
> from our peers in the OpenStack community and learning from their
> experiences may be helpful.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> __
> 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
>

Nova has this thing? That's news to me. :)

I don't think Nova has a formal process for something like this. There 
was talk at the BCN summit about giving some people +2 rights on parts 
of the tree but not full core on everything. We never implemented that.

Maybe what you're referring to is how we consider a +1 from a domain 
expert like a +2, or at least something that's good to have before cores 
are looking into the change in more detail? For example, gibi is the 
lead for the versioned notifications effort and we/I generally look for 
his +1 on a change before digging into it, or approving it. We have 
similar unofficial things like this in other parts of Nova, or subteams, 
like Timofey and Pawel with the live migration subteam.

To be sure, someone that is leading a subteam effort and is looked to 
for their opinion on a whole series of changes eventually gets into the 
conversation when we're talking about potential core reviewers, in part 
because, at least I personally, am looking for not only strong code 
review skills but also leadership/ownership within the project, because 
those are also the people that tend to stick around awhile so I'm more 
comfortable investing my time into them (and building a trust 
relationship with them).

So that's all unofficial non-formal stuff and basically grew up 
organically around the subteam efforts that started several releases 
ago. I don't know if this helps you or not.

-- 

Thanks,

Matt

__
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-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Hey folks,

In today’s Kolla team meeting, the idea was proposed of adopting nova’s 
“protocore” mentorship program for Kolla.  We would like to know what nova has 
learned from this effort.

In today’s Kolla meeting we had broad consensus on the following:

1)   Kolla has participants that want to be core reviewers

2)   These participants don’t know how to become core reviewers

3)   The core reviewers in Kolla should mentor “protocore” reviewers on how 
to do good reviews

From that, we concluded some form of mentorship program for potential core 
reviewers was in order.  We got into some debate about _how_ the program should 
be rolled out.  Let’s use this thread to discuss how it should be rolled out 
since that seems to be the sticking point of the discussion.  I saw no dissent 
in the discussion that the basic concepts were a negative change.

I am aware that nova uses a +1 review from a “protocore” and a +2/+w from a 
core reviewer prior to merge.  Nova cores – would you mind defining your 
process (on the ml is fine) more thoroughly and your experiences so we can 
learn from you?

All kolla contributors, feel free to debate the *how* such a mentorship program 
should be rolled out.  I think we have a lot to learn from our peers in the 
OpenStack community and learning from their experiences may be helpful.

Regards
-steve

__
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] [election] TC non-candidacy

[Steven Dake (stdake)]

Mike,

Thank you for your service.

Regards
-steve


-Original Message-
From: Mike Perez 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, April 4, 2017 at 1:20 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [election] TC non-candidacy

Hi all,

Thanks for letting me serve as a TC member. I will not be running this time
around since fungi is serving from the OpenStack Foundation on the
committee and ttx is more deserving for re-election.

-- 
Mike Perez


__
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-dev] [kolla] Deployment Guide Documentation for kolla-kubernetes

[Steven Dake (stdake)]

Hey folks,

The deployment guide is shaping up nicely here:
https://review.openstack.org/#/c/447356/

If folks are interested giving the review a try:

git clone http://github.com/openstack/kolla-kubernetes
git fetch git://git.openstack.org/openstack/kolla-kubernetes 
refs/changes/56/447356/10 && git cherry-pick FETCH_HEAD
cd kolla-kubernetes
tox –e docs

Then open the docs in your web browser by opening 
kolla-kubernets/doc/build/html/index.html.

Note that fetch command will only work for the 10th iteration of the patch, 
whereas there may be a new rev in the review.

Regards
-steve

__
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-dev] [kolla] gate unwedged - please recheck your patches

[Steven Dake (stdake)]

Hey folks,

If you have submitted patches for kolla-ansible since Friday March 17, gerrit 
has likely voted -1 on them because the voting gate was broken.  I recommend a 
recheck which should clear up your patch for review and merge.

Regards
-steve
__
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] Proposing duonghq for core

[Steven Dake (stdake)]

+1!

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, March 8, 2017 at 1:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Proposing duonghq for core

Hello,

I'd like to start voting to include Duong (duonghq) in Kolla and
Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
21st of March).

Consider this my +1 vote.

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

[openstack-dev] [kolla] Making a deployment guide for kolla-kubernetes

[Steven Dake (stdake)]

Hey folks,

We decided in Wednesday’s 16:00 UTC Kolla meeting to start tackling some of the 
blocking items for 1.0.0 of kolla-kubernetes.  One of those items is a 
deployment guide.  The start of the deployment guide is here:
https://etherpad.openstack.org/p/kolla-kubernetes-deploy-guide-BP

We will be defining the deployment guide documentation using etherpad to ease 
collaboration.  Please follow the instructions.  If you have questions, ask on 
#openstack-kolla.

Regards
-steve

__
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][infra] does someone cares about Jenkins? I stopped.

[Steven Dake (stdake)]

Marcin,

You can submit a bug for issue #1 you raised and fix it yourself or another 
community member can fix it after a bug is filed.

Regarding issue #2, FWIW, I agree local mirroring is the answer.  Kolla needs 
to locally mirror several repositories in OpenStack Infra so the random 
failures we see in the Kolla gate cease to occur.  The review below is one of 
many that needs to be created.  The actual acking of the patch (the second +2) 
requires manual intervention from the openstack-infra team to create an AFS 
share.  My understanding is the openstack-infra team does not have enough 
people that understand AFS mirroring to effectively provide AFS mirroring 
services, however, does provide some AFS mirroring already.  As a result, this 
review needs a rebase and probably different Ubuntu repo IDs to work properly.

I’m done attempting to enable mirroring of the repositories Kolla needs in 
openstack-infra. If you want to take over the mirroring work, feel free.  I 
will commit to guiding you on mirror usage in kolla’s gates if you can get the 
mirrors Kolla needs into the infrastructure.

https://review.openstack.org/#/c/349278/

Regards,
-steve

-Original Message-
From: Marcin Juszkiewicz 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, March 2, 2017 at 2:13 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [kolla][infra] does someone cares about Jenkins? I 
stopped.

I am working on some improvements for Kolla. Part of that work is
sending patches for review.

Once patch is set for review.openstack.org there is a set of Jenkins
jobs started to make sure that patch does not break already working
code. And this is good thing.

How it is done is not good ;(

1. Kolla output is nightmare to debug.

There is --logs-dir option to provide separate logs for each image build
but it is not used. IMHO it should be as digging through such logs is
easier.

Several images feels like they try to do install again and again to pass
through what distribution consider a bug - like "user XY already exists"
bugs while Debian/Ubuntu are used as base distro. Which adds several
error messages to check/ignore.


2. Some jobs fail because "sometimes (not always) the gate can't access
some source on the internet".

I spent most of my career on building software. Having builds fail for
such reasons was hardly acceptable when building could take hours. So we
mirrored all sources and used own mirror(s) as fallback. On other
systems I used 10-20GB w3cache to handle that for me (because there was
no way to provide local mirror of used sources).

OpenStack infrastructure lacks any of it. Using "recheck" comment in
review to restart Jenkins jobs is not a solution - how many times it has
to fail to make sure that it is patch's fault not infrastructure one?



As a contributor I started to ignore Jenkins tests. Instead I do builds
on several machines to check does everything works with my patches. If
something does not then I update my patchset.

__
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] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake (stdake)]

Andy,

A monthly meeting as I have voiced before in this thread is not sufficient to 
enable good cross-project collaboration.  To rectify this, when Steve Hardy 
started this thread, I started the process of creating an IRC channel in 
#openstack-deployment.

I understand there has been one voice on this thread that wants #openstack-dev 
to be used for that communication.  There have been several others that do want 
a specific IRC channel.  Generally, there is consensus to use the 
#openstack-deployment channel as that is the name of the tag used in the 
mailing list.

Anyone is welcome.  Hope to see folks there.

Regards
-steve


From: Andy McCrae 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, March 1, 2017 at 8:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next 
steps for cross project collaboration

On 28 February 2017 at 08:25, Flavio Percoco 
> wrote:
On 28/02/17 08:01 +, Jesse Pretorius wrote:
On 2/28/17, 12:52 AM, "Michał Jastrzębski" 
> wrote:

   I think instead of adding yet-another-irc-channel how about create
   weekly meetings? We can rant in scheduled time and it probably will
   get more attention

Happy to meet, in fact I think it’ll be important for keeping things on track – 
however weekly is too often. I think once a month at most is perfectly fine.

Yes, monthly prolly better than weekly in this cas (if we ever decide to have 
these meetings).

Agreed - monthly sounds like a good start, we can always see how it goes and 
change up as required.
I think if the only change is that we have a WG added to the Wiki and a 
[deployments] tag added for the ML,
then we can't really expect to change much or have a large impact.

I'd love to see this build some momentum and come up with useful outcomes, 
which I think the PTG session
started really nicely. There are clearly quite a few common issues that we can 
address better as a collective.

Andy
__
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] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake (stdake)]

I think IRC is more effective for real time collaboration then waiting a week 
for a meeting.  We shouldn’t have to rant at all since we are all part of 
OpenStack ☺

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, February 27, 2017 at 5:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next 
steps for cross project collaboration

So first, I'd like to say that my poor English skills aren't enough to
emphasize how much I love this idea.
I think instead of adding yet-another-irc-channel how about create
weekly meetings? We can rant in scheduled time and it probably will
get more attention. That, mailing list with dedicated tag and WG would
be great imho. We could get some room in future PTGs too then.

Am I making sense?
Michal

On 27 February 2017 at 13:08, Jesse Pretorius
 wrote:
> Comments in-line
>
> On 2/27/17, 4:02 PM, "Steven Hardy"  wrote:
>
> If I go ahead and do this is "deployment" a sufficiently 
project-neutral
> term to proceed with?
>
> I think so.
>
> I'd suggest we start with an informal WG, which it seems just 
requires an
> update to the wiki, e.g no need for any formal project team at this 
point?
>
> A WG is what I had in mind.
>
> Likewise I know some folks have expressed an interest in an IRC 
channel
> (openstack-deployment?), I'm happy to start with the ML but open to 
IRC
> also if someone is willing to set up the channel.
>
> Personally I think we should use #openstack-dev instead. It’s the 
traditional place for cross-project communication, is less exclusive and much 
like this mailing list brings more people into the conversation.
>
> Perhaps we can start by using the tag "deployment" in all 
cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
> Sure, I don’t have any strong feelings about the tag. The tag 
[deployment] makes sense to me.
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
> __
> 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] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake]

On Mon, Feb 27, 2017 at 9:36 AM, Steven Hardy <sha...@redhat.com> wrote:

> On Mon, Feb 27, 2017 at 09:25:46AM -0700, Steven Dake wrote:
> >comments inline.
> >On Mon, Feb 27, 2017 at 9:02 AM, Steven Hardy <sha...@redhat.com>
> wrote:
> >
> >  Hi all,
> >
> >  Over the recent PTG, and previously at the design summit in
> Barcelona,
> >  we've had some productive cross-project discussions amongst the
> various
> >  deployment teams.
> >
> >  It's clear that we share many common problems, such as patterns for
> >  major
> >  version upgrades (even if the workflow isn't identical we've all
> >  duplicated
> >  effort e.g around basic nova upgrade workflow recently), container
> >  images
> >  and other common building blocks for configuration management.
> >
> >  Here's a non-exhaustive list of sessions where we had some good
> >  cross-project discussion, and agreed a number of common problems
> where
> >  collaboration may be possible:
> >
> >  https://etherpad.openstack.org/p/ansible-config-mgt
> >
> >  https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
> >
> >  https://etherpad.openstack.org/p/kolla-pike-ptg-images
> >
> >  https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-
> integration
> >
> >  If there is interest in continuing the discussions on a more regular
> >  basis,
> >  I'd like to propose we start a cross-project working group:
> >
> >  https://wiki.openstack.org/wiki/Category:Working_Groups
> >
> >  If I go ahead and do this is "deployment" a sufficiently
> project-neutral
> >  term to proceed with?
> >
> >WFM.  Anything longer such as "openstack-deployment-tools" doesn't
> show
> >up very well in IRC clients.  Forgive the bikeshedding;
> >"openstack-deploy-tools" is very project-neutral and shows up well in
> IRC
> >clients.
> >Â
> >
> >  I'd suggest we start with an informal WG, which it seems just
> requires
> >  an
> >  update to the wiki, e.g no need for any formal project team at this
> >  point?
> >
> >WFM.  Since we aren't really a project team but a collection of
> projects
> >working together, I don't think we need further formalization.
> >Â
> >
> >  Likewise I know some folks have expressed an interest in an IRC
> channel
> >  (openstack-deployment?), I'm happy to start with the ML but open to
> IRC
> >  also if someone is willing to set up the channel.
> >
> >+1 - I think an IRC channel would be the best way for real time
> >communication.
> >Â
> >
> >  Perhaps we can start by using the tag "deployment" in all
> cross-project
> >  ML
> >  traffic, then potentially discuss IRC (or even regular meetings) if
> it
> >  becomes apparrent these would add value beyond ML discussion?
> >
> >[deploy-tools] may be better unless that breaks people's email
> clients.
> >I am out of bandwidth personally for meetings, although others may be
> >interested in a meeting.  I'm not sure what value a regular meeting
> would
> >have and would need a chair, which may result in an inability to
> obtain
> >neutral ground.
> >IMO IRC and ML would be sufficient for this CP effort, however others
> may
> >have different viewpoints.
>
> No strong opinion, but FWIW I chose "deployment" because I'd like to see
> collaboration not only around tools, but also around experiences and
> abstract workflow (e.g we could have all shared experiences around, say,
> nova upgrades without necessarily focussing on any one tool).
>
> "deployment" seems like a catch-all and it uses less characters in the
> subject line ;)  But I'm happy to go with the consensus here.
>
> I agree ML/IRC should be sufficient, at least in the first instance.
>
> Steve,

openstack-deployment makes sense to me given the above.  The only downside
I see is there is a bit of overlap with #openstack-operators given the
objectives you stated.  I think that is a solvable problem.

I've registered #openstack-deployment and #openstack-deploy-tools
properly.  If the OpenStack deployment project members wish to proceed, I
will commit to doing the legwork of setting up the bots/etc on the final
name we come up with even if it isn't one of the above two :)

Regards
-steve

Thanks!
>
> Steve
>
> __
> 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] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake]

comments inline.

On Mon, Feb 27, 2017 at 9:02 AM, Steven Hardy  wrote:

> Hi all,
>
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
>
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
>
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
>
> https://etherpad.openstack.org/p/ansible-config-mgt
>
> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
>
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
>
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
>
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
>
> https://wiki.openstack.org/wiki/Category:Working_Groups
>
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
>
>
WFM.  Anything longer such as "openstack-deployment-tools" doesn't show up
very well in IRC clients.  Forgive the bikeshedding;
"openstack-deploy-tools" is very project-neutral and shows up well in IRC
clients.


> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
>
>
WFM.  Since we aren't really a project team but a collection of projects
working together, I don't think we need further formalization.


> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
>
>
+1 - I think an IRC channel would be the best way for real time
communication.


> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
>
[deploy-tools] may be better unless that breaks people's email clients.

I am out of bandwidth personally for meetings, although others may be
interested in a meeting.  I'm not sure what value a regular meeting would
have and would need a chair, which may result in an inability to obtain
neutral ground.

IMO IRC and ML would be sufficient for this CP effort, however others may
have different viewpoints.


> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.
>
>
Sounds good to me.  Waiting 3 months to see everyone face to face to
discuss cross-project deployment tool collaboration doesn't seem ideal.


> Thanks!
>
> Steve
>
> __
> 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] [kolla] PTG Day #1 Webex remote participation

[Steven Dake (stdake)]

Jeremy,

I understood your original message that it was a logistical nightmare to sort 
out scaling remote participation across the entire ODS or (now the new PTGs) 
and it is not a software tools problem but rather a logistics problem 
independent of whatever software platform is used.  I agree, even on a small 
scale in a ~10-20-person setting is difficult even though you were able to sort 
it out with the infrastructure team.

Michal will do the best he can to provide remote participation.  He called me 
this afternoon to verify I brought a mic and I did plan ahead and brought the 
best mic I could.  I brought only one mic as I had to borrow it from my 
daughter’s holiday stash.  It is an omni-directional gaming grade mic [1].  
There is only one of them and a litany of things could go wrong during the 
event which make remote participation for Kolla difficult or even an 
impossibility.

Neither Michal nor I can guarantee people will have a positive experience or 
any experience with remote participation as based upon my experience handling 
remote participation at previous midcycles as well as others experiences on 
this thread have already stated.  Michal as requested support, and I’ve 
personally provided the best level of support I can to our PTL.  If he wants to 
cancel remote participation, he should do so tonight as people will be 
expecting remote participation Monday at 9:00AM sharp.

If Michal wishes to proceed, I would highly recommend Michal request someone in 
the PTG sessions to proxy questions or statements from IRC as I have no 
speakers to connect with the microphone and the harmonics of everyone in the 
room connecting to webex may break the I/O of the mic.  The mic may also not 
pick up all conversations.

YMMV on the quality of the remote participation including a complete inability 
to participate remotely even though we have tried very hard to enable remote 
participation on a shoestring budget. 

Regards,
-steve

[1] 
https://www.amazon.com/Blue-Yeti-USB-Microphone-Blackout/dp/B00N1YPXW2/ref=sr_1_1?ie=UTF8=1487566448=8-1=yeti+blackout

-Original Message-
From: Jeremy Stanley 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, February 19, 2017 at 6:44 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

On 2017-02-19 23:17:27 + (+), Serguei Bezverkhi (sbezverk) wrote:
> @Jeremy if you have not tried thelatest webex, then sharing your
> Havana time frame webex experience is not very useful. I think you
> would agree if Havana release had some issues it would not
> automatically mean that newton has them :-)

It may seem that I was complaining about Webex, but really the bulk
of the issues were logistics-related. The way we do large rooms of
in-person participation is hard to capture with a conference call
system: managing local soundboards for all the microphones and
dozens of on-site computers scattered in different rooms, trying to
relay numerous streams over unstable network connections shared by
hundreds of on-site attendees, and the fact that it ends up being a
mostly one-way channel because making it possible for many remote
attendees to interject successfully into in-person conversations
probably requires a different style of discussion altogether.

At a smaller scale, we've successfully conferenced-bridged a couple
of remote participants into Infra team design summit sessions and
mid-cycles where there were between 10 and 20 people on site, but
that's substantially different from declaring the event is able to
support an arbitrary number of remote attendees. I've seen it work
out well in telepresence facilities, but not ad hoc installations
for conferences of the size we're talking about.
-- 
Jeremy Stanley

__
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] [kolla] PTG Day #1 Webex remote participation

[Steven Dake (stdake)]

Jeremy,

Completely makes sense.  I believe the prior experience the foundation has had 
with remote participation probably won’t be much improved at the Pike PTG as 
there is no dedicated production staff and I’m not sure what type of 
teleconference hardware Michal is bringing to the PTG.  Not to mention the fact 
that the wireless services may be in a DOS state because of the number of 
attendees.

Michal asked the foundation if remote participation was an option, and they 
stated it was.  Michal had then suggested to use zoom.us and promised remote 
participation, however, that didn’t get done until Friday.  Cisco isn’t 
donating the webex services in this case; I am as a community member and Kolla 
core.

I have also found during Kolla midcycle events we have held since the founding 
of Kolla and prior to the PTG (which is the new midcycle) that every midcycle 
event with remote participation is not very optimal for participants for the 
litany of reasons you mention.

Clearly in-person PTG participation is superior to the hacked-together 
telepresence we may have available at the PTG.  I do think whatever 
teleconference hardware Michal brings to summit is better than looking at the 
output of an Etherpad where all kinds of context is lost.

For folks attending from their office remotely, don’t expect a great 
experience.  Face to face participation is always better as Jeremy has stated.

Regards
-steve

-Original Message-
From: Jeremy Stanley <fu...@yuggoth.org>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, February 18, 2017 at 5:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

On 2017-02-18 15:46:19 + (+), Steven Dake (stdake) wrote:
[...]
> In the past the foundation has been wary of enabling remote
> participation.
[...]

Only wary because of prior experience: Cisco donated Webex service
and dedicated remote production staff for us throughout the Havana
design summit in Portland, OR. As one of the volunteers who agreed
to monitor the local systems, I can say that it was a suboptimal
solution at best. Supplied laptops acting as the "presenter"
consoles crashed/hung repeatedly, slight instabilities in conference
networking were a major impediment to streaming, omnidirectional
microphones placed throughout the conference rooms still failed to
pick up much of the conversation, and for those who did attempt to
participate remotely we heard numerous complaints about how they
couldn't follow heated discussions with dozens of participants in a
room together.
-- 
Jeremy Stanley

__
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] [kolla] PTG Day #1 Webex remote participation

[Steven Dake (stdake)]

Brandon,

Happy to help where I can.  I can’t be everywhere sadly.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, February 18, 2017 at 9:32 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation




____
From: Steven Dake (stdake) <std...@cisco.com>
Sent: Saturday, February 18, 2017 10:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation


Brandon,



It is really up to the individual projects to enable remote participation.  The 
foundation greenlit Kolla’s Monday and Tuesday design sessions enabling remote 
participation if the Kolla project did the legwork on providing the remote 
participation mechanism.



- This is great to know for future PTG's. I'm glad you sent this information 
out, and I will forward to any members on our team who are interested in 
attending the Kolla PTG sessions.



In the past the foundation has been wary of enabling remote participation.  I’m 
not sure why, however, your email brings up a good argument that remote 
participation makes it more difficult for the foundation to manage the events 
and puts extra strain on the already strained PTLs to self-organize such 
participation.



Hope that information helps.



- Very helpful; thank you! I think that it's great to enable remote 
participation. I'm just not sure where the line gets drawn now for those who 
receive financial assistance vs. those who can participate via web conferences. 
I'm not going any deeper than saying that it leaves some room 
improvement/clarification. (Oh, and that I personally like Zoom or even 
https://appear.in/).



- For our part, I know that some of our team members who will be really excited 
that there is now an opportunity to participate with at least one project at 
the PTG. Thanks, Steve.



Regards

-steve





From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, February 18, 2017 at 5:27 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation



This is a great idea Steve! I didn't realize that this option was available. 
Could all the sessions do this? We have some folks that aren't able to come due 
to budget constraints, but this would allow them to participate at the PTG 
sessions.



--

Brandon B. Jozsa



From: Steven Dake (stdake) <std...@cisco.com>
Sent: Saturday, February 18, 2017 2:16:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] PTG Day #1 Webex remote participation



Hey folks,



To take some load off Michal I’ve setup remote participation for day #1 of the 
PTG.



Michal had suggested he might setup zoom instead of webex, however, I haven’t 
seen that happen and several people have asked on IRC how remote participation 
will work at the PTG.  If Michal sets up remote participation in some othe 
rway, ignore this email (and he will follow up with a zoom.us calendar invite).



Note I feel like google hangouts is difficult to manage and is a non-starter 
because google Is not available to our worldwide participants.



See below for details:







From: Steven Dake <messen...@webex.com>
Reply-To: "Steven Dake (stdake)" <std...@cisco.com>
Date: Saturday, February 18, 2017 at 12:02 AM
To: "Steven Dake (stdake)" <std...@cisco.com>
Subject: (Forward to others) WebEx meeting invitation: Kolla PTG Day #1



You can forward this invitation to others.




Hello,


Steven Dake invites you to join this WebEx meeting.









Kolla PTG Day #1


Monday, February 20, 2017


9:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  6 hrs









Join WebEx meeting 
<https://cisco.webex.com/ciscosales/j.php?MTID=meee9d3a0d0ee3020f83cc6253dc356b1>




Meeting number:


204 403 514


Meeting password:


OpenStackKolla (67367822 from phones)




Join from a video conferencing system or application


Dial 204403...@cisco.webex.com


From the Cisco internal network, dial *267* and the 9-digit meeting number. If 
you are the host, enter your PIN when prompted.









Join by phone


+1-866-432-9903 Call-in toll-free number (US/Canada)


+1-408-525-6800 Call-in toll number (US/Canada)


Access code: 204 403 514


Global call-in 
numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=376657412=1>
  | 

Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

[Steven Dake (stdake)]

Brandon,

It is really up to the individual projects to enable remote participation.  The 
foundation greenlit Kolla’s Monday and Tuesday design sessions enabling remote 
participation if the Kolla project did the legwork on providing the remote 
participation mechanism.  In the past the foundation has been wary of enabling 
remote participation.  I’m not sure why, however, your email brings up a good 
argument that remote participation makes it more difficult for the foundation 
to manage the events and puts extra strain on the already strained PTLs to 
self-organize such participation.

Hope that information helps.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, February 18, 2017 at 5:27 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] PTG Day #1 Webex remote participation


This is a great idea Steve! I didn't realize that this option was available. 
Could all the sessions do this? We have some folks that aren't able to come due 
to budget constraints, but this would allow them to participate at the PTG 
sessions.



--

Brandon B. Jozsa

____
From: Steven Dake (stdake) <std...@cisco.com>
Sent: Saturday, February 18, 2017 2:16:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] PTG Day #1 Webex remote participation

Hey folks,

To take some load off Michal I’ve setup remote participation for day #1 of the 
PTG.

Michal had suggested he might setup zoom instead of webex, however, I haven’t 
seen that happen and several people have asked on IRC how remote participation 
will work at the PTG.  If Michal sets up remote participation in some othe 
rway, ignore this email (and he will follow up with a zoom.us calendar invite).

Note I feel like google hangouts is difficult to manage and is a non-starter 
because google Is not available to our worldwide participants.

See below for details:



From: Steven Dake <messen...@webex.com>
Reply-To: "Steven Dake (stdake)" <std...@cisco.com>
Date: Saturday, February 18, 2017 at 12:02 AM
To: "Steven Dake (stdake)" <std...@cisco.com>
Subject: (Forward to others) WebEx meeting invitation: Kolla PTG Day #1

You can forward this invitation to others.


Hello,

Steven Dake invites you to join this WebEx meeting.





Kolla PTG Day #1

Monday, February 20, 2017

9:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  6 hrs





Join WebEx meeting 
<https://cisco.webex.com/ciscosales/j.php?MTID=meee9d3a0d0ee3020f83cc6253dc356b1>


Meeting number:

204 403 514

Meeting password:

OpenStackKolla (67367822 from phones)


Join from a video conferencing system or application

Dial 204403...@cisco.webex.com<%20sip:204403...@cisco.webex.com>

From the Cisco internal network, dial *267* and the 9-digit meeting number. If 
you are the host, enter your PIN when prompted.





Join by phone

+1-866-432-9903 Call-in toll-free number (US/Canada)

+1-408-525-6800 Call-in toll number (US/Canada)

Access code: 204 403 514

Global call-in 
numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=376657412=1>
  |  Toll-free calling 
restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>





Add this 
meeting<https://cisco.webex.com/ciscosales/j.php?MTID=m6f4deae3cda67f3d4cda0c37004a615a>
 to your calendar. (Cannot add from mobile devices.)





Can't join the meeting? Contact support.<https://cisco.webex.com/ciscosales/mc>





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.




__
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-dev] [kolla] Kolla PTG Day #2

[Steven Dake (stdake)]

Hey folks,

To take some load off Michal I’ve setup remote participation for day #2 of the 
PTG.

Michal had suggested he might setup zoom instead of webex, however, I haven’t 
seen that happen and several people have asked on IRC how remote participation 
will work at the PTG.  If Michal sets up remote participation in some other 
way, ignore this email (and he will follow up with a zoom.us calendar invite).

Note I feel like google hangouts is difficult to manage and is a non-starter 
because google Is not available to our worldwide participants.

See below for details:


From: Steven Dake <messen...@webex.com>
Reply-To: "Steven Dake (stdake)" <std...@cisco.com>
Date: Saturday, February 18, 2017 at 12:07 AM
To: "Steven Dake (stdake)" <std...@cisco.com>
Subject: (Forward to others) WebEx meeting invitation: Kolla PTG Day #2

You can forward this invitation to others.


Hello,

Steven Dake invites you to join this WebEx meeting.





Kolla PTG Day #2

Saturday, February 18, 2017

9:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  8 hrs





Join WebEx meeting 
<https://cisco.webex.com/ciscosales/j.php?MTID=m74f22de7d1ae51144d0dfd8cc7de735e>


Meeting number:

200 758 630

Meeting password:

OpenStackKolla (67367822 from phones)


Join from a video conferencing system or application

Dial 200758...@cisco.webex.com<%20sip:200758...@cisco.webex.com>

From the Cisco internal network, dial *267* and the 9-digit meeting number. If 
you are the host, enter your PIN when prompted.





Join by phone

+1-866-432-9903 Call-in toll-free number (US/Canada)

+1-408-525-6800 Call-in toll number (US/Canada)

Access code: 200 758 630

Global call-in 
numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=376657207=1>
  |  Toll-free calling 
restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>





Add this 
meeting<https://cisco.webex.com/ciscosales/j.php?MTID=m380302785ac9f992737ebad83f912a8f>
 to your calendar. (Cannot add from mobile devices.)





Can't join the meeting? Contact support.<https://cisco.webex.com/ciscosales/mc>





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.






WebEx_Meeting.ics
Description: WebEx_Meeting.ics
__
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-dev] [kolla] PTG Day #1 Webex remote participation

[Steven Dake (stdake)]

Hey folks,

To take some load off Michal I’ve setup remote participation for day #1 of the 
PTG.

Michal had suggested he might setup zoom instead of webex, however, I haven’t 
seen that happen and several people have asked on IRC how remote participation 
will work at the PTG.  If Michal sets up remote participation in some othe 
rway, ignore this email (and he will follow up with a zoom.us calendar invite).

Note I feel like google hangouts is difficult to manage and is a non-starter 
because google Is not available to our worldwide participants.

See below for details:



From: Steven Dake <messen...@webex.com>
Reply-To: "Steven Dake (stdake)" <std...@cisco.com>
Date: Saturday, February 18, 2017 at 12:02 AM
To: "Steven Dake (stdake)" <std...@cisco.com>
Subject: (Forward to others) WebEx meeting invitation: Kolla PTG Day #1

You can forward this invitation to others.


Hello,

Steven Dake invites you to join this WebEx meeting.





Kolla PTG Day #1

Monday, February 20, 2017

9:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  6 hrs





Join WebEx meeting 
<https://cisco.webex.com/ciscosales/j.php?MTID=meee9d3a0d0ee3020f83cc6253dc356b1>


Meeting number:

204 403 514

Meeting password:

OpenStackKolla (67367822 from phones)


Join from a video conferencing system or application

Dial 204403...@cisco.webex.com<%20sip:204403...@cisco.webex.com>

From the Cisco internal network, dial *267* and the 9-digit meeting number. If 
you are the host, enter your PIN when prompted.





Join by phone

+1-866-432-9903 Call-in toll-free number (US/Canada)

+1-408-525-6800 Call-in toll number (US/Canada)

Access code: 204 403 514

Global call-in 
numbers<https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=376657412=1>
  |  Toll-free calling 
restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>





Add this 
meeting<https://cisco.webex.com/ciscosales/j.php?MTID=m6f4deae3cda67f3d4cda0c37004a615a>
 to your calendar. (Cannot add from mobile devices.)





Can't join the meeting? Contact support.<https://cisco.webex.com/ciscosales/mc>





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.






WebEx_Meeting.ics
Description: WebEx_Meeting.ics
__
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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Steven Dake]

On Thu, Feb 16, 2017 at 11:24 AM, Joshua Harlow 
wrote:

> Alex Schultz wrote:
>
>> On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe  wrote:
>>
>>> On Feb 16, 2017, at 10:07 AM, Doug Hellmann
>>> wrote:
>>>
>>> When we signed off on the Big Tent changes we said competition
 between projects was desirable, and that deployers and contributors
 would make choices based on the work being done in those competing
 projects. Basically, the market would decide on the "optimal"
 solution. It's a hard message to hear, but that seems to be what
 is happening.

>>> This.
>>>
>>> We got much better at adding new things to OpenStack. We need to get
>>> better at letting go of old things.
>>>
>>> -- Ed Leafe
>>>
>>>
>>>
>>>
>> I agree that the market will dictate what continues to survive, but if
>> you're not careful you may be speeding up the decline as the end user
>> (deployer/operator/cloud consumer) will switch completely to something
>> else because it becomes to difficult to continue to consume via what
>> used to be there and no longer is.  I thought the whole point was to
>> not have vendor lock-in.  Honestly I think the focus is too much on
>> the development and not enough on the consumption of the development
>> output.  What are the point of all these features if no one can
>> actually consume them.
>>
>>
> +1 to that.
>
> I've been in the boat of development and consumption of it for my *whole*
> journey in openstack land and I can say the product as a whole seems
> 'underbaked' with regards to the way people consume the development output.
> It seems we have focused on how to do the dev. stuff nicely and a nice
> process there, but sort of forgotten about all that being quite useless if
> no one can consume them (without going through much pain or paying a
> vendor).
>
> This has or has IMHO been a factor in why certain are companies (and the
> people they support) are exiting openstack and just going elsewhere.
>
> I personally don't believe fixing this is 'let the market forces' figure
> it out for us (what a slow & horrible way to let this play out; I'd almost
> rather go pull my fingernails out). I do believe it will require making
> opinionated decisions which we have all never been very good at.
>
>
I understand Samuel's situation and understand that a free market
capitalism as Doug mentioned appears to be how OpenStack has operated until
today.  For most of my life I was an ardent free market capitalist.  I have
heard many pundits on the news, blog posts, financial spam, etc say free
market capitalism is the best system humankind has found to managing the
flow of resources to people (In this thread's case the flow of contributors
to Chef).  Unfortunately this form of capitalism has resulted in all sorts
of disparity in terms of education, income, freedom, and many other aspects
of our society (which translated into technical components might be what we
see in the diversion of resources to other tools such as Ansible).  I would
pick on soda manufacturers now in the US for their usage of HFCS rather
then pure cane sugar in soda, however, you can hear me rant about that at
the PTG.

OpenStack is an experiment in governance.  Part of that experiment was the
Big Tent, which unlike a circus, was meant to encompass everyone's
political and technical viewpoints to arrive at harmonious working
relationships among the community.  This choice was excellent, however, it
has re-enforced a capitalist approach to developing and delivering
OpenStack.

There is however, always room for improvement in any system.  I'm not
suggesting we can live in some magical Star Trek universe where nobody
suffers and resources are endless via a replicator.

I am suggesting we can make improvements to our governance to solve some of
these problems by applying the approaches of "Conscious Capitalism" the
credo of which is outlined here [1].  How we go about applying these
approaches to OpenStack's governance process I am unclear on.  It is clear
that the few companies that have adopted this "movement" are clearly
improving the human experience for everyone involved, not just a limited
subset of blessed individuals.  I have only studied this subject for less
than 20 hours, but it seems like a big improvement on a free-market
capitalist system and something the entire OpenStack ecosystem should
examine.

[1]  https://www.consciouscapitalism.org/about/credo

Warm Regards,
-steve


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

Re: [openstack-dev] [kolla] Phoenix area meet up with the topic of Kolla Feb 15th @ 21:00 UTC

[Steven Dake (stdake)]

Hey folks,

Webex has undergone an upgrade and anyone from any geography can participate 
via Linux machines using a web browser rather than only a Mac or Windows 
client.  All of the information I previously offered about Linux clients no 
longer holds for this meetup February 15th @21:00 UTC.  The rest of the 
information is correct.

Hope to see you for the live stream or if your in the greater Phoenix area, in 
person!

Regards
-steve


From: "Steven Dake (stdake)" <std...@cisco.com>
Date: Tuesday, January 31, 2017 at 5:56 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: Toby Cardone <tcard...@redhat.com>
Subject: [kolla] Phoenix area meet up with the topic of Kolla Feb 15th @ 21:00 
UTC

Hey folks,

Toby Cardone has kindly organized a local (to me) community meetup hosted by 
the Red Hat Software User Group at Insight’s facilities in Tempe, AZ with the 
topic of Kolla on February 15th, 2017 at 21:00 UTC.  Several folks in the Kolla 
IRC channel have asked if remote participation is possible.  I asked Toby and 
he said that sounded great!

The meetup information in more detail is here:

If you are interested in participating the community seminar more information 
can be found here:
https://www.meetup.com/PhoenixRedHatSoftwareUserGroup/events/237219035/

You don’t need to register at the meetup site to attend remotely; only local 
attendance requires signup (to make sure the event’s facilities are not 
overbooked).  Much of this material may be old hat for the community in general 
although I do plan to provide a live demo of the current state of sausage 
making in kolla-kubernetes.

I am using webex for remote participation.  I know this is not ideal since it 
doesn’t run on Linux 64 bit.  One workaround is to use your phone, a 32bit 
android tablet, or a 32 bit linux vm (pretty sure this last one works but not 
100% positive) if you don’t have access to a mac or windows platform.  
Depending on attendance webex may be pokey – please take care to sign in up to 
15 minutes early in the event webex is overloaded.

The remote participation webex information follows:

Wednesday February 15th, 2017 @ 2PM MST (21:00 UTC)
Meeting: 
https://cisco.webex.com/ciscosales/j.php?MTID=mee2e81571288da5c183af4ae2fff0d8e
Meeting number (access code): 208 707 718
Password: OpenStackKolla
Passowrd on callin lines: 67367822
Global dialin #s: 
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=374661952=1

Regards,
-steve

__
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] Mascot

[Steven Dake (stdake)]

The mascot is absolutely fantastic!  Nice work to all involved!

Regards
-steve

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, February 13, 2017 at 7:53 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Mascot

And here we are, our mascot:) Feel free to use it in any Kolla related
presentation or tattoo studio.


https://www.dropbox.com/sh/94pukquiw425ji2/AAAl2wVmm72KHPLCAzR6Uboha?dl=0

__
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] [fuel][kolla][kuryr][openstack-ansible][openstack-helm] OpenStack on containers leaveraging kuryr

[Steven Dake (stdake)]

Flavio,

Somehow the fuel project and openstack-ansible project got left off the 
taglines.  I’m not sure if the fuel peeps saw this thread, but I know the 
openstack-ansible peeps didn’t see the thread.  As a result, I’ve added those 
taglines.  Hopefully we can include the broader deployment tools community  in 
the 1 hour session since the room seats 50 peeps.

Regards
-steve


-Original Message-
From: Flavio Percoco 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, February 10, 2017 at 7:24 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack 
on containers leaveraging kuryr

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

[openstack-dev] Reminder to use recheck rather then rebase to trigger a gate re-run: was Re: [kolla] unblocking the gate

[Steven Dake (stdake)]

Hey folks,

I’d like to remind kolla contributors of this email exchange from Feb 29th, 
2016 with the infra team.

I originally requested kolla contributors to rebase all of their patches to 
unblock the gate.  This was an incorrect request.  The infrastructure team 
quickly corrected my misunderstanding of how the gate worked.  Both Sam Yaple 
and I verified the infrastructure team was correct, and I’ve been having to get 
other people in the kolla team to verify it ever since since most folks think 
the gate jobs run against the patch they were last committed to.  Instead as 
Clark and Andreas point out, they run against master in every case.

Please re-read this thread for details on how this works.

Regards
-steve

-Original Message-
From: Clark Boylan <cboy...@sapwetik.org>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, February 29, 2016 at 7:16 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] unblocking the gate

On Mon, Feb 29, 2016, at 01:38 PM, Sam Yaple wrote:
> On Mon, Feb 29, 2016 at 6:42 PM, Clark Boylan <cboy...@sapwetik.org>
> wrote:
> 
    > > On Mon, Feb 29, 2016, at 09:09 AM, Steven Dake (stdake) wrote:
> > >
> > >
> > > On 2/29/16, 12:26 AM, "Andreas Jaeger" <a...@suse.com> wrote:
> > > >This is not needed, the CI system always rebases if you run tests. To
> > > >get current tests, a simple "recheck" is enough.
> > > >
> > > >Also, we test in the gate before merging - again after rebasing to 
head.
> > > >That should take care of not merging anything broken. Running recheck
> > > >after a larger change will ensure that you have recent results.
> > >
> > > Andreas,
> > >
> > > Thanks for the recheck information.  I thought the gate ran against 
what
> > > it was submitted with as head.  We don't have any gate jobs at present
> > > (or
> > > many) they are mostly check jobs, so its pre-merge checking that we 
need
> > > folks to do.
> > >
> > To clarify the check pipeline changes are merged into their target
> > branches before testing and the gate pipeline changes are merged into
> > the forward looking state of the world that Zuul generates as part of
> > gate testing. This means you do not need to rebase and create new
> > patchsets to get updated test results, just recheck.
> >
> >
> Unfortunately we do not have voting gates in Kolla that do building and
> deploying. This will change soon, but that would be where the confusion
> in
> the thread is coming from I believe. Our only indication is a "Green"
> check
> job at this time. This is why Steven is asking for a rebase to make the
> check gates green before we merge new patches.

I understand the situation with check vs gate tests, but my previous
statement (below) still holds. All you need to do is recheck. You only
need a rebase if you have run into a merge conflict.

> 
> You should only need to rebase and create a new patchset if a merge
> > conflict exists.

Clark


__
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] [kolla] Support for non-x86_64 architectures

[Steven Dake (stdake)]

Marcin,

I think this work is fantastic!

The Ocata feature deadline has passed.  Reference:
https://releases.openstack.org/ocata/schedule.html

The feature freeze deadline was January 25th 2017.  What this means is that 
this work will need to go into Pike instead of Ocata.  One of the reasons you 
haven’t seen much activity on the reviews is the core reviewer team is busy 
finalizing Ocata.  Once Jeffrey Zhang (our release liaison) branches ocata, 
this patch would be ready for review.  I would recommend filing a blueprint 
here:
https://blueprints.launchpad.net/kolla/+addspec

And point out the blueprint in IRC asking for a blueprint triage.  Any core 
reviewer can do that blueprint triage.  Blueprints are how some projects, but 
not all, track work in OpenStack.

The branch of Ocata should happen early this week.

Regards
-steve


-Original Message-
From: Marcin Juszkiewicz 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, February 10, 2017 at 11:21 AM
To: OpenStack Development Mailing List 
Cc: Gema Gomez 
Subject: [openstack-dev] [kolla] Support for non-x86_64 architectures

Hello

At Linaro I work on running OpenStack on AArch64 (arm64, 64-bit arm,
ARMv8a) architecture. We built Cinder, Glance, Heat, Horizon, Keystone,
Neutron and Nova for our use and deployed it several times.

But for next release we decided to move to use containers for delivering
components. This got me working on Kolla to get it working on our machines.

The problem is that Kolla targets only x86-64 architecture. I was not
surprised when saw that and do not blame anyone for it. That's quite
common behaviour nowadays when there is no Alpha nor Itanium on a market.

So I digged a bit and found patch [1] which added ppc64le architecture
support. Fetched, reviewed and decided that it can be used as a base for
my work.

1. https://review.openstack.org/#/c/423239/6

I cut all stuff about repositories and other ppc64le/ubuntu specific
issues and then edited it to take care of aarch64 as well. Then I posted
it to gerrit for review [2].

2. https://review.openstack.org/#/c/430940

Jenkins looks happy about it, I got some comments from few developers
(both in review and on irc) and handled them proper way.

I tested patch with "aarch64/ubuntu" and "aarch64/debian" images used as
a base. My target are CentOS (waiting for official image) and Debian.

Current state:

19:18 hrw@pinkiepie-centos:kolla$ docker images|grep kolla/ubuntu|wc -l
29
19:18 hrw@pinkiepie-centos:kolla$ docker images|grep kolla/debian|wc -l
124

During weekend I will run more builds to check all possible images.

If someone has some spare time then I would love to see my patch
reviewed. There is one change affecting x86-64: Debian/Ubuntu
repositories are split to base + architecture ones to allow for
architecture specific repos configuration.

__
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] [tripleo][kolla][openstack-helm][kuryr] OpenStack on containers leaveraging kuryr

[Steven Dake (stdake)]

Flavio,

I think Michal (inc0) was planning to reach out to the TripleO team to at least 
get one or more design sessions in Wednesday.  Kolla’s PTG schedule for Monday 
and Tuesday is packed with a wait list of topics.  I depart IIRC Wednesday at 
11AM – I had asked inc0 if we do these we do them Wednesday in the morning 
around 8-10 or 9-10 to catch the people that are leaving early.  As there isn’t 
a CP Design Track at the PTG (that I saw in the schedule), I believe the last 
proposal from someone (forgot who, apologies there) in the TripleO team was to 
shave a couple hours off Wednesday morning to sort out CP collaboration work.

If that isn’t what your proposal is about, wfm – I’d like to attend in any 
regard.  My travel is locked in as my daughter is performing Thursday so I need 
to be home by then (and BOS->AZ = 6 hr flight).  Other folks from Kolla have 
shown interest in participation in a cross-project effort on Wednesday and will 
be there all week.

Regards
-steve

-Original Message-
From: Flavio Percoco 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, February 9, 2017 at 1:57 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [tripleo][kolla][openstack-helm][kuryr] OpenStack on 
containers leaveraging kuryr

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

Re: [openstack-dev] Large Contributing OpenStack Operators working group?

[Steven Dake (stdake)]

Jay,

I don’t see a reference to the wiki page in your email and don’t immediately 
see the LCOO working group wiki.  From what you describe this working group is 
not working within the framework of the 4 opens which is one of OpenStack’s 
fundamental philosophies.

Thanks for bringing up your questions; I hope someone that represents this 
group can at least get this working group operating within the 4 opens 
framework if they are not already.

Regards
-steve


-Original Message-
From: Jay Pipes 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, February 2, 2017 at 1:14 PM
To: OpenStack Development Mailing List , 
"openstack-operat...@lists.openstack.org" 

Subject: [openstack-dev] Large Contributing OpenStack Operators working group?

Hi,

I was told about this group today. I have a few questions. Hopefully 
someone from this team can illuminate me with some answers.

1) What is the purpose of this group? The wiki states that the team 
"aims to define the use cases and identify and prioritise the 
requirements which are needed to deploy, manage, and run services on top 
of OpenStack. This work includes identifying functional gaps, creating 
blueprints, submitting and reviewing patches to the relevant OpenStack 
projects, contributing to working those items, tracking their completion."

What is the difference between the LCOO and the following existing 
working groups?

  * Large Deployment Team
  * Massively Distributed Team
  * Product Working Group
  * Telco/NFV Working Group

2) According to the wiki page, only companies that are "Multi-Cloud 
Operator[s] and/or Network Service Provider[s]" are welcome in this 
team. Why is the team called "Large Contributing OpenStack Operators" if 
it's only for Telcos? Further, if this is truly only for Telcos, why 
isn't the Telco/NFV working group appropriate?

3) Under the "Guiding principles" section of the above wiki, the top 
principle is "Align with the OpenStack Foundation". If this is the case, 
why did the group move its content to the closed Atlassian Confuence 
platform? Why does the group have a set of separate Slack channels 
instead of using the OpenStack mailing lists and IRC channels? Why is 
the OPNFV Jira used for tracking work items for the LCOO agenda?

See https://wiki.openstack.org/wiki/Gluon/Tasks-Ocata for examples.

4) I see a lot of agenda items around projects like Gluon, Craton, 
Watcher, and Blazar. I don't see any concrete ideas about talking with 
the developers of the key infrastructure services that OpenStack is 
built around. How does the LCOO plan on reaching out to the developers 
of the long-standing OpenStack projects like Nova, Neutron, Cinder, and 
Keystone to drive their shared agenda?

Thanks for reading and (hopefully) answering.

-jay

__
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-dev] [kolla] pip install kolla-ansible 4.0.0b3+ broken

[Steven Dake (stdake)]

Hey folks,

Pip install kolla-ansible is busted.  I’d take ownership of this bug myself, 
however, I am personally swamped.  This is a DOA deliverable issue and as such 
is higher priority than “critical”.  Can someone in the community take a look?

https://bugs.launchpad.net/kolla-ansible/+bug/1662195

TIA!
-steve


__
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-dev] [kolla] Phoenix area meet up with the topic of Kolla Feb 15th @ 21:00 UTC

[Steven Dake (stdake)]

Hey folks,

Toby Cardone has kindly organized a local (to me) community meetup hosted by 
the Red Hat Software User Group at Insight’s facilities in Tempe, AZ with the 
topic of Kolla on February 15th, 2017 at 21:00 UTC.  Several folks in the Kolla 
IRC channel have asked if remote participation is possible.  I asked Toby and 
he said that sounded great!

The meetup information in more detail is here:

If you are interested in participating the community seminar more information 
can be found here:
https://www.meetup.com/PhoenixRedHatSoftwareUserGroup/events/237219035/

You don’t need to register at the meetup site to attend remotely; only local 
attendance requires signup (to make sure the event’s facilities are not 
overbooked).  Much of this material may be old hat for the community in general 
although I do plan to provide a live demo of the current state of sausage 
making in kolla-kubernetes.

I am using webex for remote participation.  I know this is not ideal since it 
doesn’t run on Linux 64 bit.  One workaround is to use your phone, a 32bit 
android tablet, or a 32 bit linux vm (pretty sure this last one works but not 
100% positive) if you don’t have access to a mac or windows platform.  
Depending on attendance webex may be pokey – please take care to sign in up to 
15 minutes early in the event webex is overloaded.

The remote participation webex information follows:

Wednesday February 15th, 2017 @ 2PM MST (21:00 UTC)
Meeting: 
https://cisco.webex.com/ciscosales/j.php?MTID=mee2e81571288da5c183af4ae2fff0d8e
Meeting number (access code): 208 707 718
Password: OpenStackKolla
Passowrd on callin lines: 67367822
Global dialin #s: 
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=374661952=1

Regards,
-steve

__
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-ansible] [kolla] Am I doing this wrong?

[Steven Dake (stdake)]

Thanks peeps for responding to Kris.  Kris, I had offered a response – do you 
need further information answered?  It looks to me like all the questions have 
been answered by others in the community.  If not, feel free to respond and 
I’ll answer the remainders.

Sean when your around and I am please ping me – it looks like you have the same 
outlook problem as I do and have sort of figured out how to solve it.  I’d like 
to know how so I don’t have to top post or use gmail for the ml.

Regards
-steve


-Original Message-
From: "sean.k.moo...@intel.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, January 24, 2017 at 5:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?



> -Original Message-
> From: Paul Bourke [mailto:paul.bou...@oracle.com]
> Sent: Tuesday, January 24, 2017 11:49 AM
> To: OpenStack Development Mailing List (not for usage questions) 
 d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this 
wrong?
> 
> Ah, I think you may be misreading what Sean is saying there. What he 
means is
> kolla-ansible provides the bare minimum config templates to make the 
service
> work. To template every possible config option would be too much of a
> maintenance burden on the project.
> 
> Of course, users will want to customise these. But instead of modifying 
the
> templates directly, we recommend you use the "config override"
> mechanism [0]
> 
> This has a number of benefits, the main one being that you can pick up new
> releases of Kolla and not get stuck in merge hell, Ansible will pick up 
the Kolla base
> templates and merge them with user provided overrides.
[Mooney, Sean K] paul is correct here, I did not intend to suggest that 
kolla-ansible should not
Be used to generate and manage config files. I simply wanted to point out 
that where
Customization is required to a config, it is preferable to use the config 
override mechanism
When possible vs modifying the ansible templates directly.
> 
> Wrt to the fact gathering, I understand your concern, we essentially have 
the same
> problem in our team. It can be raised again for further discussion, I'm 
sure there's
> other ways it can be solved.
[Mooney, Sean K] I belive you are intended to be able to use the ansible 
--limit and --tags flags,
To restrict the plays executed and node processed by a deploy and upgrade 
command.
I have used the --tags flags successfully in the past, I have had less 
success with the --limit flag.
In theory with the right combination of --limit and --tag you should be 
able to constrain  the node
On which facts are gathered to just those that would be modified e.g. 2-3 
instead of hundreds. 
> 
> [0]
> http://docs.openstack.org/developer/kolla-ansible/advanced-
> configuration.html#openstack-service-configuration-in-kolla
> 
> -Paul
> 
> On 23/01/17 18:03, Kris G. Lindgren wrote:
> > Hi Paul,
> >
> >
> >
> > Thanks for responding.
> >
> >
> >
> >> The fact gathering on every server is a compromise taken by Kolla to
> >
> >> work around limitations in Ansible. It works well for the majority of
> >
> >> situations; for more detail and potential improvements on this please
> >
> >> have a read of this post:
> >
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-November/1078
> >> 33.html
> >
> >
> >
> > So my problem with this is the logging in to the compute nodes.  While
> > this may be fine for a smaller deployment.  Logging into thousands,
> > even hundreds, of nodes via ansible to gather facts, just to do a
> > deployment against 2 or 3 of them is not tenable.  Additionally, in
> > our higher audited environments (pki/pci) will cause our auditors 
heartburn.
> >
> >
> >
> >> I'm not quite following you here, the config templates from
> >
> >> kolla-ansible are one of it's stronger pieces imo, they're reasonably
> >
> >> well tested and maintained. What leads you to believe they shouldn't
> >> be
> >
> >> used?
> >
> >>
> >
> >> > * Certain parts of it are 'reference only' (the config tasks),
> >
> >>  > are not recommended
> >
> >>
> >
> >> This is untrue - kolla-ansible is designed to stand up a stable and
> >
> >> usable OpenStack 'out of the box'. There are definitely gaps in the
> >
> >> operator type tasks as you've highlighted, but I would not call it
> >
> >> 'reference only'.
> >
> >
> >
> > 

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

[Steven Dake (stdake)]

Gema,

Yes team meeting sounds good.

I am changing my vote from choice 2 to abstain until this is sorted out.

Regards
-steve


-Original Message-
From: Gema Gomez 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, January 24, 2017 at 7:42 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

Hi,

we had a brief conversation in the channel about this.

My team at Linaro is planning to start working with Kolla after the PTG
to produce fully deployable ARM64 containers. The preference for us is
to produce Debian based containers, as well as any others that are
required to meet the project requirements.

I'd like to discuss this a bit further, we may be able to help with the
lack of support, but we need to understand how much work would be required.

Can we discuss further at the team meeting tomorrow?

Thanks,
Gema


On 19/01/17 10:53, Christian Berendt wrote:
> As discussed in one of the last team meetings I want to propose the 
deprecation (this cycle) and removal (next cycle) of the Debian support in 
Kolla.
> 
> More than 1 week ago I sent a pre warning mail to the openstack-operators 
mailing list, without any reply [0].
> 
> Kolla core reviewers, please vote now. The vote will be open for 7 days 
(26.01.2017).
> 
> 1. Kolla needs support for Debian, it should not be deprecated
> 
> 2. Kolla should deprecate support for Debian
> 
> [0] 
http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html
> 

__
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] [kolla-ansible] [kolla] Am I doing this wrong?

[Steven Dake (stdake)]

Kris,

Thanks for adding the kolla tag.  As we reach milestone 3, every kolla dev is 
knee deep in development and probably not reading mails not directly tagged 
with [kolla].

IOutlook 2016 has a bug where I cannot respond inline.  I am replying here so 
my gmail account picks up the email so that I can respond inline.

It will take me several hours to process your email and I’m not certain I can 
answer all of the questions to your satisfaction as kolla is a pretty large 
project and it is difficult for any one person to know all of the details.  I 
will hopefully have a response sometime this evening for the things I can 
answer.  Hopefully others in the community can fill in the gaps.

Regards
-steve



From: "Kris G. Lindgren" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, January 20, 2017 at 6:03 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?

Adding [kolla] tag.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Friday, January 20, 2017 at 4:54 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: Re: [kolla-ansible] Am I doing this wrong?

Poke.  Bueller?


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Tuesday, January 10, 2017 at 5:34 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [kolla-ansible] Am I doing this wrong?

Hello Kolla/Kolla-ansible peoples.

I have been trying to take kolla/kolla-ansible and use it to start moving our 
existing openstack deployment into containers.  At the same time also trying to 
fix some of the problems that we created with our previous deployment work 
(everything was in puppet).  Where we had puppet doing *everything* which 
eventually created a system that effectively performed actions at a distance.  
As we were never really 100% what puppet was going to do when we ran it.  Even 
with NOOP mode enabled.  So taking an example of building and deploying glance 
via kolla-ansible. I am running into some problems/concerns and wanted to reach 
out to make sure that I am not missing something.

Things that I am noticing:
 * I need to define a number of servers in my inventory outside of the specific 
servers that I want to perform actions against.  I need to define groups 
baremetal, rabbitmq, memcached, and control (IN addition to the glance specific 
groups) most of these seem to be gathering information for config? (Baremetal 
was needed soley to try to run the bootstrap play).  Running a change 
specifically against "glance" causes fact gathering on a number of other 
servers not specifically where glance is running?  My concern here is that I 
want to be able to run kola-ansible against a specific service and know that 
only those servers are being logged into.

* I want to run a dry-run only, being able to see what will happen before it 
happens, not during; during makes it really hard to see what will happen until 
it happens. Also supporting  `ansible --diff` would really help in 
understanding what will be changed (before it happens).  Ideally, this wouldn’t 
be 100% needed.  But the ability to figure out what a run would *ACTUALLY* do 
on a box is what I was hoping to see.

* Database task are ran on every deploy and status of change DB permissions 
always reports as changed? Even when nothing happens, which makes you wonder 
"what changed"?  Seems like this is because the task either reports a 0 or a 1, 
where it seems like there is 3 states, did nothing, updated something, failed 
to do what was required.  Also, Can someone tell me why the DB stuff is done on 
a deployment task?  Seems like the db checks/migration work should only be done 
on a upgrade or a bootstrap?

* Database services (that at least we have) our not managed by our team, so 
don't want kolla-ansible touching those (since it won't be able to). No way to 
mark the DB as "externally managed"?  IE we dont have permissions to create 
databases or add users.  But we got all other permissions on the databases that 
are created, so normal db-manage tooling works.

* Maintenance level operations; doesn't seem to be any built-in to say 'take a 
server out  of a production state, deploy to it, test it, put it back into 
production'  Seems like if kola-ansible is doing haproxy for API's, it should 
be managing this?  Or an extension point to allow us to run our own 
maintenance/testing 

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

[Steven Dake (stdake)]

My vote is for option 2 to deprecate Debian as there has been very little 
activity and operators seem uninterested in Debian as a platform.

We could always add it back in at a later date if operators were to request it 
and the Debian team were interested in maintaining it.

Regards
-steve


-Original Message-
From: Christian Berendt 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, January 19, 2017 at 3:53 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vote][kolla] deprecation for Debian distro support

As discussed in one of the last team meetings I want to propose the 
deprecation (this cycle) and removal (next cycle) of the Debian support in 
Kolla.

More than 1 week ago I sent a pre warning mail to the openstack-operators 
mailing list, without any reply [0].

Kolla core reviewers, please vote now. The vote will be open for 7 days 
(26.01.2017).

1. Kolla needs support for Debian, it should not be deprecated

2. Kolla should deprecate support for Debian

[0] 
http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html

-- 
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-dev] [kolla] Contributors welcome to kolla-kubernetes 0.5.0

[Steven Dake (stdake)]

Hey folks,

The release team released kolla-kubernetes 0.4.0 Sunday January 15th.  Now we 
are in 0.5.0 development which lasts one month.

The general architecture of OpenStack based deployments with a Kubernetes 
underlay is taking form.  There are 5 blueprints in 0.5.0 which we expect 
should land prior to the PTG:
https://launchpad.net/kolla-kubernetes/+milestone/0.5.0

If you have personal interest in any of these blueprints, the fact that they 
are “assigned” doesn’t mean there isn’t a contribution to be made.  If you 
click through to an individual blueprint, you can see the “Work Items” field 
which contains each work item that needs addressing in each of these master 
blueprints.  For each master blueprint, there may be 10+ work items or more.

The goal of these “master” blueprints is to distribute the work among the 
development community.  There should be enough to work from in the whiteboard 
patches to produce an implementation.

Feel free to change “unassigned” to your Launchpad id for any of the blueprint 
work items.  The person assigned is responsible for tracking the state of the 
blueprint’s work items or generally leading the effort around those blueprints 
as has been done in other Kolla deliverables.

Regards
-steve
__
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] [release][ptl] not planning to serve as release PTL for Pike

[Steven Dake (stdake)]

Doug,
Thanks for your leadership and your consistent help with helping Kolla solve 
how to use the release team’s tooling.

I have to say that manually tagging as we did previously as PTLs (when I was a 
PTL) was pure madness.  I really like what the releases team has done for 
OpenStack!

Regards,
-steve


-Original Message-
From: Doug Hellmann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, January 13, 2017 at 1:00 PM
To: openstack-dev 
Subject: [openstack-dev] [release][ptl] not planning to serve as release PTL
for Pike

I announced this at the release team meeting on 6 Jan, but thought
I should also post to the list as well:  I do not plan to serve as
the Release Management team PTL for the Pike release cycle.

It has been my pleasure to serve as PTL, and we've almost finished
the automation work that I envisioned when I joined the team. Now
I would like to shift my focus to some other projects within the
community.  I will still be an active member of the Release Management
team, helping with new initiatives and reviews for releases.

Doug

__
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-dev] [kolla] Adding jeffrey4l to kolla-kubernetes-core because he is release liason

[Steven Dake (stdake)]

We are busily releasing 0.4.0 of the Kolla deliverable kolla-kubernetes and 
have determined we can’t release the kolla-kubernetes milestone without the 
release liaison for Kolla being on the core reviewer sub-team to make last 
minute fine tuning adjustments to the release and approve other people’s 
changes during crunch time.

The release liaison is one of the most trusted individuals in an OpenStack 
project, as they have ultimate authority over which tags get generated when for 
which deliverables.  If anyone has issue with this change, please raise it 
(since we didn’t do our standard procedural voting for a core reviewer).  If 
folks raise issues with it, inc0 can reverse the change, and we can have a 
standard vote instead which I’m sure would pass.

Regards
-steve

__
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

[Steven Dake (stdake)]

Thierry,

Cool thanks for the leeway here ☺

I agree wholeheartedly with your last sentiment.  If an existing Kolla sub-team 
or an existing project (e.g. the Puppet team) in OpenStack or a new project 
wants to use Kolla images and feels they would operate more effectively without 
the structure Kolla has in place, I personally as a core reviewer don’t want to 
limit that type of activity as long as it fits within the TC’s governance 
rules.  As a core reviewer, I do want to keep what deliverables we currently 
have in place as splitting out deliverables is super disruptive to the Kolla 
project.  Over 60% of the Ocata cycle has been spent just splitting 
kolla-ansible into its own deliverable – meaning we are way behind on 
maintenance and development of our existing deliverables.  Like all things in 
life, my opinion is subject to change in the future.

Regards
-steve


-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, January 12, 2017 at 6:25 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Michał Jastrzębski wrote:
> So from my point of view, while I understand why project separation
> makes sense in the long run, I will argue that at this moment it will
> be hurtful for the project. Our community is still fairly integrated,
> and I'd love to keep it this way a while longer. We haven't yet fully
> cleaned up mess that split of kolla-ansible caused (documentation and
> whatnot). Having small revolution like that again is something that
> would greatly hinder our ability to deliver valuable project, and I
> think for now that should be our priority.

FWIW my email was not meant as an immediate request to split Kolla
because its internal structure goes against the OpenStack project
structure. In particular as long as the Kolla subteams are fine
operating under a single umbrella and being seen as a single "team",
there is no need to change that, that would be a distraction.

I just wanted to explain that a lot of the organizational problems the
Kolla team is going through are caused by this "umbrella" model and that
we designed the current OpenStack project structure precisely to avoid
them. I also don't want to discourage any Kolla subteam (or future
project leveraging Kolla images) which feels like it would operate
better as a separate project team to file for official inclusion.

Cheers!

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


__
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

[Steven Dake (stdake)]

Sure – you asked me and I thought you wanted an answer from me (which fits 
under the do not use OpenStack properties (i.e. this mailing list) for 
promotion of candidates email that Mark sent out).

Others are able to answer in the broader Kolla community.

Regards
-steve

From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Date: Wednesday, January 11, 2017 at 1:01 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "Steven Dake (stdake)" 
<std...@cisco.com>, "OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables


I’m not entirely sure how the two relate, but anyone from Kolla can respond.

Brandon B. Jozsa


On January 11, 2017 at 2:49:07 PM, Steven Dake (stdake) 
(std...@cisco.com<mailto:std...@cisco.com>) wrote:
Brandon,

Your question is a mix of political and technical aspects that I am not 
permitted to answer until Monday because of my parsing of this email from Mark 
Collier:

http://lists.openstack.org/pipermail/foundation/2017-January/002446.html

I will answer you Monday after the individual board of directors elections 
conclude.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 12:36 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

To your point Steve, then I’d image that Kolla would have no objection to the 
introduction of other Openstack-namespace projects that provide alternative 
image formats, integration choices, or orchestration variances for those in the 
larger community who do not want to use Kolla images. All of the Kolla-x 
projects point to this one source of truth in the end. This results in large to 
the many projects falling under the Kolla umbrella: Kolla, Kolla-Mesos, 
Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d assume whatever else wants 
to consume Kolla, if things continue as they are.

My immediate ask is "what are the potential negative impacts to Kolla having so 
many projects under one mission”: fragmentation of goals, misunderstanding of 
mission, increased developer debt across each inter-twined project (cross-repo 
commits and reviews), complex gating requirements? #kolla has been a place of 
spirited debate with the recent addition of Kolla-Kubernetes, and I think some 
of this is the result of the problems I’m alluding to. It’s very difficult to 
preserve what Kolla is at it’s core, and in turn preserve the benefits of 
something like Kubernetes which has a Runtime Interface abstraction model. It’s 
a tough sell for the larger Openstack community, and this is a critical time 
for Openstack and CNCF interoperability; would you not agree?

I’m failing to see the benefits you mention outweighing what others might see 
as potential pitfalls. My viewpoint is not news to those in Kolla. I’ve 
expressed this in Kolla already, and this is why I’m disappointed when 
Kolla-Kuberntes drops Secs in favor of quicker ad-hoc IRC 
architecturally-focused discussions.

So my question now becomes; "How is Kolla addressing these issues, and what has 
Kolla been doing with the assistance of the Openstack Foundation to gain the 
confidence of those who are watching Kolla and looking for that next cool 
container project”?

Brandon B. Jozsa


On January 11, 2017 at 1:46:13 PM, Britt Houser (bhouser) 
(bhou...@cisco.com<mailto:bhou...@cisco.com>) wrote:
My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite 
yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 1

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

[Steven Dake (stdake)]

Brandon,

Your question is a mix of political and technical aspects that I am not 
permitted to answer until Monday because of my parsing of this email from Mark 
Collier:

http://lists.openstack.org/pipermail/foundation/2017-January/002446.html

I will answer you Monday after the individual board of directors elections 
conclude.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 12:36 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

To your point Steve, then I’d image that Kolla would have no objection to the 
introduction of other Openstack-namespace projects that provide alternative 
image formats, integration choices, or orchestration variances for those in the 
larger community who do not want to use Kolla images. All of the Kolla-x 
projects point to this one source of truth in the end. This results in large to 
the many projects falling under the Kolla umbrella: Kolla, Kolla-Mesos, 
Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d assume whatever else wants 
to consume Kolla, if things continue as they are.

My immediate ask is "what are the potential negative impacts to Kolla having so 
many projects under one mission”: fragmentation of goals, misunderstanding of 
mission, increased developer debt across each inter-twined project (cross-repo 
commits and reviews), complex gating requirements? #kolla has been a place of 
spirited debate with the recent addition of Kolla-Kubernetes, and I think some 
of this is the result of the problems I’m alluding to. It’s very difficult to 
preserve what Kolla is at it’s core, and in turn preserve the benefits of 
something like Kubernetes which has a Runtime Interface abstraction model. It’s 
a tough sell for the larger Openstack community, and this is a critical time 
for Openstack and CNCF interoperability; would you not agree?

I’m failing to see the benefits you mention outweighing what others might see 
as potential pitfalls. My viewpoint is not news to those in Kolla. I’ve 
expressed this in Kolla already, and this is why I’m disappointed when 
Kolla-Kuberntes drops Secs in favor of quicker ad-hoc IRC 
architecturally-focused discussions.

So my question now becomes; "How is Kolla addressing these issues, and what has 
Kolla been doing with the assistance of the Openstack Foundation to gain the 
confidence of those who are watching Kolla and looking for that next cool 
container project”?

Brandon B. Jozsa


On January 11, 2017 at 1:46:13 PM, Britt Houser (bhouser) 
(bhou...@cisco.com<mailto:bhou...@cisco.com>) wrote:
My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite 
yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 11 January 2017 at 09:59, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
>> Thierry,
>>
>> I am not a big fan of the separate gerrit teams we have instituted inside 
>> the Kolla project. I always believed we should have one core reviewer team 
>> responsible for all deliverables to avoid not just the appearance but the 
>> reality that each team would fragment the overall community of people 
>> working on Kolla containers and deployment tools. This is yet another reason 
>> I didn’t want to split the repositories into separate deliverables in the 
>> first place – since it further fragments the community working on Kolla 
>> deliverables.
>>
>> When we made our original mission statement, I originally wanted it scoped 
>> around j

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

[Steven Dake (stdake)]

Doug,

I apologize for not being able to reply inline.  Bug in outlook.  I am probably 
going to start posting/responding on the ml with my gmail account so I can 
properly communicate with ml.

To your two points.

I don’t want kolla to “own” all deployment with containers.  I want kolla and 
it’s deliverables to operate as one community.  TripleO is consuming kolla 
containers currently – and our core team is suppoprtive of that.  Just this 
morning I  approved a tripleo blueprint to enable TripleO to use kolla 
containers.  My actions maybe here speak louder than my words ☺

I agree we could work across project boundaries because we are one community 
(OpenStack).  I also believe it would be more difficult to do so because of 
channel siloing, meeting siloing, developer siloing, etc.

Kolla really works hard to operate within the boundaries of the 4 Opens without 
ANY exception.

Regards
-steve


-Original Message-
From: Doug Hellmann <d...@doughellmann.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 10:59 AM
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

    Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
> Thierry,
> 
> I am not a big fan of the separate gerrit teams we have instituted inside 
the Kolla project.  I always believed we should have one core reviewer team 
responsible for all deliverables to avoid not just the appearance but the 
reality that each team would fragment the overall community of people working 
on Kolla containers and deployment tools.  This is yet another reason I didn’t 
want to split the repositories into separate deliverables in the first place – 
since it further fragments the community working on Kolla deliverables.
> 
> When we made our original mission statement, I originally wanted it 
scoped around just Ansible and Docker.  Fortunately, the core review team at 
the time made it much more general and broad before we joined the big tent.  
Our mission statement permits multiple different orchestration tools.
> 
> Kolla is not “themed”, at least to me.  Instead it is one community with 
slightly different interests (some people work on Ansible, some on Kubernetes, 
some on containers, some on all 3, etc).  If we break that into separate 
projects with separate PTLs, those projects may end up competing with each 
other (which isn’t happening now inside Kolla).  I think competition is a good 
thing.  In this case, I am of the opinion it is high time we end the 
competition on deployment tools related to containers and get everyone working 
together rather than apart.  That is, unless those folks want to “work apart” 
which of course is their prerogative.  I wouldn’t suggest merging teams today 
that are separate that don’t have a desire to merge.  That said, Kolla is very 
warm and open to new contributors so hopefully no more new duplicate effort 
solutions are started.

It sure sounds to me like you want Kolla to "own" container deployment
tools. As Thierry said, we aren't intended to be organized that way any
more.

> Siloing the deliverables into separate teams I believe would result in 
the competition I just mentioned, and further discord between the deployment 
tool projects in the big tent.  We need consolidation around people working 
together, not division.  Division around Kolla weakens Kolla specifically and 
doesn’t help out OpenStack all that much either.

I would hope that the spirit of collaboration could extend across team
boundaries. #WeAreOpenStack

Doug

> 
> The idea of branding or themes is not really relevant to me.  Instead 
this is all about the people producing and consuming Kolla.  I’d like these 
folks to work together as much as feasible.  Breaking a sub-community apart (in 
this case Kolla) into up to 4 different communities with 4 different PTLs 
sounds wrong to me.
> 
> I hope my position is clear ☺  If not, feel free to ask any follow-up 
questions.
> 
> Regards
> -steve
> 
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Organization: OpenStack
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
> Date: Wednesday, January 11, 2017 at 4:21 AM
> To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
> 
> Michał Jastrzębski wrote:
> > I created CIVS poll with options we discussed. Every core member 
should
> > get link to poll voting

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

[Steven Dake (stdake)]

Thierry,

I am not a big fan of the separate gerrit teams we have instituted inside the 
Kolla project.  I always believed we should have one core reviewer team 
responsible for all deliverables to avoid not just the appearance but the 
reality that each team would fragment the overall community of people working 
on Kolla containers and deployment tools.  This is yet another reason I didn’t 
want to split the repositories into separate deliverables in the first place – 
since it further fragments the community working on Kolla deliverables.

When we made our original mission statement, I originally wanted it scoped 
around just Ansible and Docker.  Fortunately, the core review team at the time 
made it much more general and broad before we joined the big tent.  Our mission 
statement permits multiple different orchestration tools.

Kolla is not “themed”, at least to me.  Instead it is one community with 
slightly different interests (some people work on Ansible, some on Kubernetes, 
some on containers, some on all 3, etc).  If we break that into separate 
projects with separate PTLs, those projects may end up competing with each 
other (which isn’t happening now inside Kolla).  I think competition is a good 
thing.  In this case, I am of the opinion it is high time we end the 
competition on deployment tools related to containers and get everyone working 
together rather than apart.  That is, unless those folks want to “work apart” 
which of course is their prerogative.  I wouldn’t suggest merging teams today 
that are separate that don’t have a desire to merge.  That said, Kolla is very 
warm and open to new contributors so hopefully no more new duplicate effort 
solutions are started.

Siloing the deliverables into separate teams I believe would result in the 
competition I just mentioned, and further discord between the deployment tool 
projects in the big tent.  We need consolidation around people working 
together, not division.  Division around Kolla weakens Kolla specifically and 
doesn’t help out OpenStack all that much either.

The idea of branding or themes is not really relevant to me.  Instead this is 
all about the people producing and consuming Kolla.  I’d like these folks to 
work together as much as feasible.  Breaking a sub-community apart (in this 
case Kolla) into up to 4 different communities with 4 different PTLs sounds 
wrong to me.

I hope my position is clear ☺  If not, feel free to ask any follow-up questions.

Regards
-steve


-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 11, 2017 at 4:21 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Michał Jastrzębski wrote:
> I created CIVS poll with options we discussed. Every core member should
> get link to poll voting, if that's not the case, please let me know.

Just a quick sidenote to explain how the "big-tent" model of governance
plays in here...

In the previous project structure model, we had "programs". If you
wanted to do networking stuff, you had to join the Networking program
(neutron). If you worked on object storage, you had to join the Object
Storage program (swift). The main issue with this model is that it
prevented alternate approaches from emerging (as a program PTL could
just refuse its emergence to continue to "own" that space). It also
created weird situations where there would be multiple distinct groups
of people in a program, but a single PTL to elect to represent them all.
That created unnecessary political issues within programs and tension
around PTL election.

Part of the big-tent project structure reform was to abolish programs
and organize our work around "teams", rather than "themes". Project
teams should be strongly aligned with a single team of people that work
together. That allowed some amount of competition to emerge (we still
try to avoid "gratuitous duplication of effort"), but most importantly
made sure groups of people could "own" their work without having to
defer to an outside core team or PTL. So if you have a distinct team, it
should be its own separate project team with its own PTL. There is no
program or namespace anymore. As a bonus side-effect, it made sure teams
would not indefinitely grow, and we all know that it's difficult to grow
core teams (and trust) beyond a certain point.

This is why we have multiple packaging project teams, each specialized
in a given package orchestration mechanism, rather than have a single
"Packaging" program with a single PTL and Ansible / Puppet / Chef
fighting in elections to get their man at the helm. This is why the
Storlets team, while 

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

[Steven Dake (stdake)]

Michal,

Another option is 2 individuals from each core review team + PTL.  That is 
lighter weight then 3 and 4, yet more constrained then 1 and 2 and would be my 
preferred choice (or alternatively 3 or 4).  Adding a deliverable is serious 
business ☺

FWIW I don’t’ think we are at an impasse, it just requires a policy vote as we 
do today.

Regards
-steve

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 4, 2017 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

Hello,

New deliverable to Kolla was proposed, and we found ourselves in a bit
of an impasse regarding process of accepting new deliverables. Kolla
community grew a lot since we were singular project, and now we have 3
deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
one was proposed, kolla-salt, all of them having separate core teams
today. How to we proceed with this and following deliverables? How to
we accept them to kolla namespace? I can think of several ways.

1) Open door policy - whoever wants to create new deliverable, is just
free to do so.
2) Lightweight agreement - just 2*+2 from Kolla core team to some list
of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
vote it would be good for PTL to know what he/she is PTL of;)
3) Majority vote from Kolla core team - much like we do with policy
changes today
4) Majority vote from all Kolla deliverables core teams

My personal favorite is option 2+PTL vote. We want to encourage
experiments and new contributors to use our namespace, for both larger
community and ease of navigation for users.

One caveat to this would be to note that pre-1.0 projects are
considered dev/experimental.

Thoughts?

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

Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

[Steven Dake (stdake)]

I think optimally we should check if we are running in rax-iad, and if so, set 
libvirt virtualization to qemu.  I was pretty sure the gate script that sets up 
the system sets the libvirt type to qemu.  After inspection of the gate 
scripts, this is not the case.  Perhaps it was setup this way previously and 
someone changed it.

This explains why rax gates have been so flakey for a very long time when 
running the deploy jobs.

Regards,
-steve


From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, January 2, 2017 at 3:37 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during 
launching qemu progress

XEN doesn't work well with nested kvm. We need to change nova config to pure 
qemu without kvm. I thought we did that in gates?

On Jan 2, 2017 2:25 PM, "Clark Boylan" 
> wrote:
On Sun, Jan 1, 2017, at 09:13 PM, Jeffrey Zhang wrote:
> Checked more failed gate, here is the more info:
>
> 1. only rax-iad has such issue
> 2. the failed and successful gates have the same rpm installed.
>
> So the only difference between failed gate and successful gate is the xen
> hypervisor.

I don't have any answers but my first thought was maybe it is related to
https://bugs.launchpad.net/nova/+bug/1643911; however, that affects
libvirt 1.3.1 on Ubuntu Xenial and there is at least one instance of
that occurring on a non Xen hypervisor so maybe they are not related.

Also noticed that you appear to have two redundant sets of system logs
in the Kolla centos job(s). See
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_log/
and
http://logs.openstack.org/80/415880/1/check/gate-kolla-dsvm-deploy-centos-binary-centos-7-nv/d94c349/logs/system_logs/.

As for debugging this you may be able to install libvirt's debugging
symbols
(http://debuginfo.centos.org/7/x86_64/libvirt-debuginfo-2.0.0-10.el7.x86_64.rpm),
capture a core dump, load into gdb and go from there.

Clark

__
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] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

[Steven Dake (stdake)]

Jeffrey,

rax-iad uses xen as a base virtualization layer iiuc.  Perhaps kvm on xen is 
not a technical feature rax-iad supports or perhaps libvirt was modified and 
now fails with xen?  Whatever the case is, rax-iad has been a semi-constant 
source of hassle with Kolla’s gate jobs; I think partly because Kolla’s gate 
scripts need to special-case rax-iad in some way.

Just one of many possibilities.

Happy new year ☺

Regards
-steve


From: Jeffrey Zhang <zhang.lei@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, December 31, 2016 at 6:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during 
launching qemu progress

I checked more than ten error gates, all of them happened in rax-iad.

On Sat, Dec 31, 2016 at 12:06 PM, Steven Dake (stdake) 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:
Jeffrey,

Have you detected any pattern to any specific cloud provider in the logs?

Regards
-steve


From: Jeffrey Zhang <zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, December 30, 2016 at 12:41 AM
To: OpenStack Development Mailing List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during 
launching qemu progress

Found this nova bug[0] and another talk in openstack-dev[1].

The question is: why this happens now and then? sometimes the gate is OK. and 
others not.

[0] https://bugs.launchpad.net/nova/+bug/1649527
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109401.html

On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang 
<zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>> wrote:
Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version.

But in kolla's gate. the nova_libvirt container failed now and then.

What i found is:

1. Simple start nova_libvirt container is OK.
2. When launching a new instance, libvirt is killed without any logs in 
libvirtd.log file.
3. in system messages log, i found following line.

Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip 
7f9fee072823 sp 7f9fe52dd1c0 error 4 in 
libvirt.so.0.2000.0[7f9fedf1f000+353000]

No idea why and how this happen. Any idea on this?

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>

__
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<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

Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during launching qemu progress

[Steven Dake (stdake)]

Jeffrey,

Have you detected any pattern to any specific cloud provider in the logs?

Regards
-steve


From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 30, 2016 at 12:41 AM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [kolla][rdo] libvirt 2.0 process is failed during 
launching qemu progress

Found this nova bug[0] and another talk in openstack-dev[1].

The question is: why this happens now and then? sometimes the gate is OK. and 
others not.

[0] https://bugs.launchpad.net/nova/+bug/1649527
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109401.html

On Fri, Dec 30, 2016 at 3:33 PM, Jeffrey Zhang 
> wrote:
Recently, centos 7.3 is release. libvirt is upgrade to 2.0 version.

But in kolla's gate. the nova_libvirt container failed now and then.

What i found is:

1. Simple start nova_libvirt container is OK.
2. When launching a new instance, libvirt is killed without any logs in 
libvirtd.log file.
3. in system messages log, i found following line.

Dec 29 00:41:24 localhost kernel: libvirtd[24340]: segfault at 8 ip 
7f9fee072823 sp 7f9fe52dd1c0 error 4 in 
libvirt.so.0.2000.0[7f9fedf1f000+353000]

No idea why and how this happen. Any idea on this?

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me



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

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

[Steven Dake (stdake)]

My response wasn’t clear and I’ve also thought more about your proposal.  I’d 
be highly in favor of the approach you mentioned as long as 2 was modified in 
your proposal to include some larger number then 2 individuals.  One option 
that comes to mind is a majority of each core review sub-team for point 2 
taking into account some of our core reviewers have issues that temporarily 
prevent them from fulfilling their core reviewer duties (although they plan to 
re-engage).

I agree we don’t want to duplicate the TC – that would be super heavy – not 
that the TC is heavy – but rather that Kolla doesn’t need its own governance 
structure as the technical governance of OpenStack is directed by the technical 
committee.  I for one, don’t want to have a full-blown governance structure for 
Kolla, although I can’t speak for other core reviewers.

Regards
-steve


-Original Message-
From: "Steven Dake (stdake)" <std...@cisco.com>
Date: Friday, December 23, 2016 at 3:53 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

WFM – I’d be partly in favor of such an approach although I can’t speak for 
others.  I think we should require some larger set then 2 individuals from the 
kolla-policy-core; perhaps a majority of active reviewers for some definition 
of active reviewers.

Regards
-steve


-Original Message-
From: Michał Jastrzębski <inc...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, December 23, 2016 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?

So let me throw an idea there, one which we should vote on:

Prep:
1. We create kolla-policy-core-team which is sum of all core teams of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s

Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team

This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.

Thoughts?
    Michal

On 23 December 2016 at 13:11, Steven Dake (stdake) <std...@cisco.com> 
wrote:
> Michal,
>
> Really what I was getting at was placing in the governance repository 
as a kolla deliverable.  In days past we *always* voted on additions and 
removals of deliverables.  It doesn’t seem like a gray area to me – we have 
always followed a voting pattern for adding and removal of deliverables.  This 
repo could be added to the git openstack namespace but then not have it as a 
kolla deliverable without a vote I think; this is sort of what Fuel did with 
Fuel-ccp – that proposal is a gray area.  I found when Fuel did  that to be 
extremely odd personally ☺  I’m not sure if there is a trademark policy or 
something similar that affects the use of Kolla and OpenStack together.  I’ve 
included the [tc] in the topic so they can provide guidance on the route you 
suggested (incubation for new kolla deliverables that are not actually 
deliverables).
>
> I think we really don’t need the tc to intervene here though, we can 
just make new policies on our own via the typical policy voting process we have 
followed in the past.  Before we make any decisions about that though, I think 
we need a vote on the topic. ☺
>
&g