from:"Paul Bourke"

Re: [openstack-dev] [kolla] Proposing Chason Chan (chason) as kolla-ansible core

2018-09-27 Thread Paul Bourke


+1

On 25/09/18 16:47, Eduardo Gonzalez wrote:

Hi,

I would like to propose Chason Chan to the kolla-ansible core team.

Chason is been working on addition of Vitrage roles, rework VpnaaS 
service, maintaining

documentation as well as fixing many bugs.

Voting will be open for 14 days (until 9th of Oct).

Kolla-ansible cores, please leave a vote.
Consider this mail my +1 vote

Regards,
Eduardo


__
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

2018-08-08 Thread Paul Bourke

+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) >:


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





__
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] [sig][upgrades][ansible][charms][tripleo][kolla][airship] reboot or poweroff?

2018-07-24 Thread Paul Bourke


Hi James,

Sorry to hear about the lack of participation. I for one am guilty of 
not taking part, there just seems to be never enough time in the day to 
cram in all the moving parts that a project like OpenStack requires.


That being said, this effort is definitely one of the most important to 
the project imo, so I'm keen to step up.


Moving to a monthly meeting sounds a good idea, at least till things get 
back on foot. Could you share what the current times / location for the 
meeting is?


Cheers,
-Paul

On 23/07/18 17:01, James Page wrote:

Hi All

tl;dr we (the original founders) have not managed to invest the time to 
get the Upgrades SIG booted - time to hit reboot or time to poweroff?


Since Vancouver, two of the original SIG chairs have stepped down 
leaving me in the hot seat with minimal participation from either 
deployment projects or operators in the IRC meetings.  In addition I've 
only been able to make every 3rd IRC meeting, so they have generally not 
being happening.


I think the current timing is not good for a lot of folk so finding a 
better slot is probably a must-have if the SIG is going to continue - 
and maybe moving to a monthly or bi-weekly schedule rather than the 
weekly slot we have now.


In addition I need some willing folk to help with leadership in the 
SIG.  If you have an interest and would like to help please let me know!


I'd also like to better engage with all deployment projects - upgrades 
is something that deployment tools should be looking to encapsulate as 
features, so it would be good to get deployment projects engaged in the 
SIG with nominated representatives.


Based on the attendance in upgrades sessions in Vancouver and 
developer/operator appetite to discuss all things upgrade at said 
sessions I'm assuming that there is still interest in having a SIG for 
Upgrades but I may be wrong!


Thoughts?

James






__
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] Removing old / unused images

2018-06-27 Thread Paul Bourke

Ok, thanks for the replies. Seems at least the non k8s images are in use 
by tripleo and so will remain untouched. caoyuan has a similar patch 
open to just remove the k8s related images so please have a look and 
vote on that instead: https://review.openstack.org/#/c/576911/

I'm not sure we need a deprecation cycle on the k8s images given they 
were directly related to kolla-k8s, that said, we need to remember there 
are other consumers outside these projects so if people feel we should 
keep them for a cycle please let me know.

On 26/06/18 16:51, Andy Smith wrote:

Also commented as tripleo is using qdrouterd.

It's use in kolla-ansible
https://github.com/openstack/kolla-ansible/tree/master/ansible/roles/qdrouterd

and bp
https://blueprints.launchpad.net/kolla/+spec/dispatch-router-messaging-component

Thanks,
Andy

On Tue, Jun 26, 2018 at 10:52 AM Alex Schultz <mailto:aschu...@redhat.com>> wrote:

On Tue, Jun 26, 2018 at 8:05 AM, Paul Bourke mailto:paul.bou...@oracle.com>> wrote:
 > Hi all,
 >
 > At the weekly meeting a week or two ago, we mentioned removing
some old /
 > unused images from Kolla in the interest of keeping the gate run
times down,
 > as well as general code hygiene.
 >
 > The images I've determined that are either no longer relevant, or
were
 > simply never made use of in kolla-ansible are the following:
 >
 > * almanach
 > * certmonger
 > * dind
 > * qdrouterd
 > * rsyslog
 >
 > * helm-repository
 > * kube
 > * kubernetes-entrypoint
 > * kubetoolbox
 >
 > If you still care about any of these or I've made an oversight,
please have
 > a look at the patch [0]
 >

I have commented as tripleo is using some of these. I would say that
you shouldn't just remove these and there needs to be a proper
deprecation policy. Just because you aren't using them in
kolla-ansible doesn't mean someone isn't actually using them.

Thanks,
-Alex

 > Thanks!
 > -Paul
 >
 > [0] https://review.openstack.org/#/c/578111/
 >
 >
__
 > 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 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] Removing old / unused images

2018-06-26 Thread Paul Bourke


Hi all,

At the weekly meeting a week or two ago, we mentioned removing some old 
/ unused images from Kolla in the interest of keeping the gate run times 
down, as well as general code hygiene.


The images I've determined that are either no longer relevant, or were 
simply never made use of in kolla-ansible are the following:


* almanach
* certmonger
* dind
* qdrouterd
* rsyslog

* helm-repository
* kube
* kubernetes-entrypoint
* kubetoolbox

If you still care about any of these or I've made an oversight, please 
have a look at the patch [0]


Thanks!
-Paul

[0] https://review.openstack.org/#/c/578111/

__
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

2018-06-01 Thread Paul Bourke


+1

On 31/05/18 18:02, 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

[openstack-dev] Slides for Kolla onboarding & project update

2018-05-22 Thread Paul Bourke


Hi all,

Here are the slide decks for these sessions. The project update should 
be available shortly on YouTube also.


https://www.slideshare.net/PaulBourke1/kolla-onboarding-vancouver-2018

https://www.slideshare.net/PaulBourke1/kolla-project-update-vancouver-2018


Thanks,
-Paul

__
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] Building Kolla containers with 3rd party vendor drivers

2018-05-14 Thread Paul Bourke

> Operators that need one or more of these “additional drivers” will be 
provided
> with documentation on how the code in the “additional drivers” path 
can be
> used to build their own containers. This documentation will also 
detail how

> to combine more than one 3rd party drivers into their own container.

Yes this sounds fine. We already have a 'contrib' directory [0], so I 
think this would align with what you're suggesting.

-Paul

[0] https://github.com/openstack/kolla/tree/master/contrib

On 11/05/18 18:02, Sandhya Dasu (sadasu) wrote:

Hi Paul,
 I am happy to use the changes you proposed to
  https://github.com/openstack/kolla/blob/master/kolla/common/config.py

I was under the impression that this was disallowed for drivers that weren’t
considered “reference drivers”. If that is no longer the case, I am happy to go
this route and abandon the approach I took in my diffs in:
https://review.openstack.org/#/c/552119/.

I agree with the reasoning that Kolla cannot possibly maintain a large
number of neutron-server containers, one per plugin.

To support operators that want to build their own images, I was hoping that
we could come up with a mechanism by which the 3rd party driver owners
provide the code (template-override.j2 or Dockerfile.j2 as the case maybe)
to build their containers. This code can definitely live out-of-tree with the
drivers themselves.

Optionally, we could have them reside in-tree in Kolla in a separate directory,
say “additional drivers”. Kolla will not be responsible for building a container
per driver or for building a huge (neutron-server) container containing all
interested drivers.

Operators that need one or more of these “additional drivers” will be provided
with documentation on how the code in the “additional drivers” path can be
used to build their own containers. This documentation will also detail how
to combine more than one 3rd party drivers into their own container.

I would like the community’s input on what approach best aligns with Kolla’s
and the larger OpenStack community’s goals.

Thanks,
Sandhya

On 5/11/18, 5:35 AM, "Paul Bourke" <paul.bou...@oracle.com> wrote:

 Hi Sandhya,

 Thanks for starting this thread. I've moved it to the mailing list so

 the discussion can be available to anyone else who is interested, I hope
 you don't mind.

 If your requirement is to have third party plugins (such as Cisco) that

 are not available on tarballs.openstack.org, available in Kolla, then
 this is already possible.

 Using the Cisco case as an example, you would simply need to submit the

 following patch to
 https://github.com/openstack/kolla/blob/master/kolla/common/config.py

 """

  'neutron-server-plugin-networking-cisco': {
  'type': 'git',
  'location': ('https://github.com/openstack/networking-cisco')},
 """

 This will then include that plugin as part of the future neutron-server

 builds.

 If the requirement is to have Kolla publish a neutron-server container

 with *only* the Cisco plugin, then this is where it gets a little more
 tricky. Sure, we can go the route that's proposed in your patch, but we
 end up then maintaining a massive number of neutron-server containers,
 one per plugin. It also does not address then the issue of what people
 want to do when they want a combination or mix of plugins together.

 So right now I feel Kolla takes a middle ground, where we publish a

 neutron-server container with a variety of common plugins. If operators
 have specific requirements, they should create their own config file and
 build their own images, which we expect any serious production setup to
 be doing anyway.

 -Paul

 On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:

 > Yes, I think there is some misunderstanding on what I am trying to 
accomplish here.
 >
 > I am utilizing existing Kolla constructs to prove that they work for 3rd 
party out of tree vendor drivers too.
 > At this point, anything that a 3rd party vendor driver does (the way 
they build their containers, where they publish it and how they generate config) 
is completely out of scope of Kolla.
 >
 > I want to use the spec as a place to articulate and discuss best 
practices and figure out what part of supporting 3rd party vendor drivers can stay 
within the Kolla tree and what should be out.
 > I have witnessed many discussions on this topic but they only take away 
I get is “there are ways to do it but it can’t be part of Kolla”.
 >
 > Using the existing kolla constructs of template-override, plugin-archive 
and config-dir, let us say the 3rd party vendor builds a container.
 > OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla p

[openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

2018-05-11 Thread Paul Bourke

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so
the discussion can be available to anyone else who is interested, I hope
you don't mind.

If your requirement is to have third party plugins (such as Cisco) that
are not available on tarballs.openstack.org, available in Kolla, then
this is already possible.

Using the Cisco case as an example, you would simply need to submit the
following patch to
https://github.com/openstack/kolla/blob/master/kolla/common/config.py

"""
'neutron-server-plugin-networking-cisco': {
'type': 'git',
'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server
builds.

If the requirement is to have Kolla publish a neutron-server container
with *only* the Cisco plugin, then this is where it gets a little more
tricky. Sure, we can go the route that's proposed in your patch, but we
end up then maintaining a massive number of neutron-server containers,
one per plugin. It also does not address then the issue of what people
want to do when they want a combination or mix of plugins together.

So right now I feel Kolla takes a middle ground, where we publish a
neutron-server container with a variety of common plugins. If operators
have specific requirements, they should create their own config file and
build their own images, which we expect any serious production setup to
be doing anyway.

-Paul

On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:

Yes, I think there is some misunderstanding on what I am trying to accomplish
here.

I am utilizing existing Kolla constructs to prove that they work for 3rd party
out of tree vendor drivers too.
At this point, anything that a 3rd party vendor driver does (the way they build
their containers, where they publish it and how they generate config) is
completely out of scope of Kolla.

I want to use the spec as a place to articulate and discuss best practices and
figure out what part of supporting 3rd party vendor drivers can stay within the
Kolla tree and what should be out.
I have witnessed many discussions on this topic but they only take away I get
is “there are ways to do it but it can’t be part of Kolla”.

Using the existing kolla constructs of template-override, plugin-archive and
config-dir, let us say the 3rd party vendor builds a container.
OpenStack TC does not want these containers to be part of
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the
Kolla project.
If these 3rd party vendor drivers publish to Dockerhub they will have to
publish under a different project. So, an OpenStack installation that needs
these drivers will have to pull images from 2 or more Dokerhub projects?!

Or do you prefer if the OpenStack operator build their own images using the
out-of-tree Dockerfile for that vendor?

Again, should the config changes to support these drivers be part of the
kolla-ansible repo or should they be out-of-tree?

It is hard to have this type of discussion on IRC so I started this email
thread.

Thanks,
Sandhya

On 5/10/18, 5:59 AM, "Paul Bourke (pbourke) (Code Review)"
<rev...@openstack.org> wrote:

Paul Bourke (pbourke) has posted comments on this change. (
https://review.openstack.org/567278 )

Change subject: Building Kolla containers with 3rd party vendor drivers

Patch Set 2: Code-Review-1

Hi Sandhya, after reading the spec most of my thoughts echo Eduardo's. I'm wondering if there's some misunderstanding on how the current plugin functionality works? Feels free to ping me on irc I'd be happy to discuss further - maybe there's still some element of what's there that's not working for your use case.

To view, visit https://review.openstack.org/567278
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment

Gerrit-Change-Id: I681d6a7b38b6cafe7ebe88a1a1f2d53943e1aab2
Gerrit-PatchSet: 2
Gerrit-Project: openstack/kolla
Gerrit-Branch: master
Gerrit-Owner: Sandhya Dasu <sad...@cisco.com>
Gerrit-Reviewer: Duong Ha-Quang <duon...@vn.fujitsu.com>
Gerrit-Reviewer: Eduardo Gonzalez <dabar...@gmail.com>
Gerrit-Reviewer: Paul Bourke (pbourke) <paul.bou...@oracle.com>
Gerrit-Reviewer: Zuul
Gerrit-HasComments: No

__
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

2018-04-27 Thread Paul Bourke


+1, always great working with Mark :)

On 26/04/18 16:31, Jeffrey Zhang wrote:

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



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-04-18 Thread Paul Bourke


+1

On 18/04/18 02:51, Jeffrey Zhang wrote:
Since many of the contributors in the kolla-kubernetes project are moved 
to other things. And there is no active contributor for months.  On the 
other hand, there is another comparable project, openstack-helm, in the 
community.  For less confusion and disruptive community resource, I 
propose to retire the kolla-kubernetes project.


More discussion about this you can check the mail[0] and patch[1]

please vote +1 to retire the repo, or -1 not to retire the repo. The 
vote will be open until everyone has voted, or for 1 week until April 
25th, 2018.


[0] 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html

[1] https://review.openstack.org/552531

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
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] [tripleo] On moving start scripts out of Kolla images

2018-04-05 Thread Paul Bourke

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.

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, requires the base kolla image in all
cases). This is only for the config. For the service start up command,
this need to also be provided in config.json. This command is then
parsed out and written to a location in the image, which is consumed by
a series of start/extend start shell scripts. Kolla is *unique* in this
regard, no other project in the container world is interfacing with
images in this way. Being a snowflake in this regard is not a good
thing. I'm still waiting to hear from a real world operator who would
prefer to spend time learning the above to doing:

docker run -v /etc/keystone:/etc/keystone keystone:latest
--entrypoint /usr/bin/keystone [args]

This is the Docker API, it's easy to understand and pretty much the
standard at this point.

The other argument is that this removes the possibility for immutable
infrastructure. The concern is, with the new approach, a rookie operator
will modify one of the start scripts - resulting in uncertainty that
what was first deployed matches what is currently running. But with the
way Kolla is now, an operator can still do this! They can restart
containers with a custom entrypoint or additional bind mounts, they can
exec in and change config files, etc. etc. Kolla containers have never
been immutable and we're bending over backwards to artificially try and
make this the case. We cant protect a bad or inexperienced operator from
shooting themselves in the foot, there are better ways of doing so.
If/when Docker or the upstream container world solves this problem, it
would then make sense for Kolla to follow suit.

On the face of it, what the spec proposes is a simple change, it should
not radically pull the carpet out under people, or even change the way
kolla-ansible works in the near term. If consumers such as tripleo or
other parties feel it would in fact do so please do let me know and we
can discuss and mitigate these problems.

Cheers,
-Paul

[0] https://review.openstack.org/#/c/550958/
[1] https://github.com/openstack/loci
[2]
https://github.com/openstack/kolla/blob/master/docker/base/set_configs.py
[3]
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keystone/templates/keystone.json.j2
[4]
http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-04-04-16.00.log.txt

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

2018-03-28 Thread Paul Bourke


+1

Thanks Jeffrey for taking the time to investigate.

On 28/03/18 16:47, Jeffrey Zhang wrote:

There are two projects to solve the issue that run OpenStack on
Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
leverage helm tool for orchestration. There is some different perspective
at the beginning, which results in the two teams could not work together.

But recently, the difference becomes too small. and there is also no active
contributor in the kolla-kubernetes project.

So I propose to retire kolla-kubernetes project. If you are still
interested in running OpenStack on kubernetes, please refer to
openstack-helm project.

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

2018-03-12 Thread Paul Bourke


+1

On 12/03/18 02:06, 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 


__
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] PTG Summary

2018-03-08 Thread Paul Bourke


Hi all,

Here's my summary of the various topics we discussed during the PTG. 
There were one or two I had to step out for but hopefully this serves as 
an overall recap. Please refer to the main etherpad[0] for more details 
and links to the session specific pads.


build.py script refactor

* I think was little debate that we need this. However, discussion moved 
fairly quickly towards if there's changes we can make to our images that 
will not require maintaining such a large build script in the first place.
* loci images are making good progress and are already in use by 
openstack-helm
  * By moving the start scripts from the kolla images into 
kolla-ansible we can decouple ourselves from these images and open the 
possibility of comsuming images from other sources such as loci.


Actions:
* Do a poc of externalising start scripts (started under 
https://review.openstack.org/#/c/550500/)


plugin split from main images
=
* Plugins continue to be a contentious issue in Kolla
* The current approach of installing all available plugins 'out of the 
box' is not working for certain users.
* Sam Betts had a good example of why this is not working for them, I 
don't feel I can summarise it properly. Will reach out to him to clarify.
* We didn't reach a conclusion on this, it seems there are pros and cons 
to each approach. Needs further discussion and possibly some pocs.


ansible "--check" and "--diff" mode
===
* Operators would like to see some dry run like features in kolla-ansible.
* Would like to see the return of something like genconfig, where 
configs can be generated ahead of time and diffed/reviewed before deploy.
* Also some general discussion in this session on management and scaling 
difficulties with kolla.

* Inventory management needs to be more flexible.
* Operations are too slow once you hit about 200 nodes, operators are 
finding they have to use manual trickery to divide up their inventories.

* A lot of operations take place when very little has changed config wise.

Actions:
* No specific actions came out of this at this time. I think we'd need 
more time on this topic to determine specific work items that can make 
improvements here.


Database backup & recovery
==
* Interesting topic, all in agreement kolla should provide some 
functionality in this area.
* Discussion around which areas of responsibility fall on kolla vs. the 
operator. E.g. 'kolla should allow for regular database backups, how 
those are restored is beyond project scope'

* yankcrime has done some ground work on this as well as a poc.
* Good documentation is important here.

Actions:
* Review yankcrime's poc and provide feedback
* Form a spec detailing what mechanism we want to use to trigger 
backups, etc.


ceph-ansible

* All seem in agreement that the issues and work seen in migrating to 
ceph-ansible currently outweigh the benefits.
* Decided to stick with improving kolla ceph for now, with bluestore 
support being a priority.


Actions:
* Write a blueprint to add support for bluestore 
(https://blueprints.launchpad.net/kolla/+spec/kolla-ceph-bluestore)
* Update docs to better inform operators on why they may or may not want 
to use kolla ceph vs the alternatives.


Prometheus support for monitoring
=
* There have been some previous attempts to add a monitoring stack in 
Kolla, though none have come to fruition.
* Oracle are looking at prometheus and what it will take to integrate 
that to Kolla to fill this gap.


Actions:
* Write spec to detail how this will work.
* Do the work.

self health check support
=
* This had some crossover with the monitoring discussion.
* Kolla has some checks in the form of our 'sanity checks', but these 
are underutilised and not implemented for every service. Tempest or 
rally would be a better fit here.


Actions:
* Remove the sanity check code from kolla-ansible - it's not fit for 
purpose and our assumption is noone is using it.
* Make contact with the self healing SIG, and see if we can help here. 
They may have recommendations for us.

* Make a spec for this.

destroy service & node
==
* Several aspects to this:
  * We would like to be able to remove an individual service as part of 
kolla-ansible destroy

* It is not clear what best practice is to remove a control node in Kolla
* Likewise for compute
* This could be automated but documentation would go a long way here also.

Actions:
* Clearly document how to remove a control/compute node from a kolla 
deployment.


integrate with docker-compose
=
* This is something Jeffrey is working on so we didn't have much to 
contribute in the way of discussion.


Actions:
* Review and provide feedback on https://review.openstack.org/538581

Implement rolling upgrade for all core projects

Re: [openstack-dev] [kolla][ptg] Team dinner

2018-02-27 Thread Paul Bourke

Ok, Thursday seems good for the majority. Venue is 'Against the Grain' 
[0]. You can get the number 16 bus from near the Croke Park hotel, or we 
can just arrange to share a couple of taxis. See you all at the sessions 
tomorrow :)


-Paul

[0] https://goo.gl/maps/pddiUwnr67B2

On 26/02/18 19:39, Paul Bourke wrote:

Hey Kolla,

Hope you're all enjoying Dublin so far :) Some have expressed interest 
in getting together for a team meal, how does Thursday sound? Please 
reply to this with +1/-1 and I can see about booking something.


Cheers,
-Paul

__
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][ptg] Team dinner

2018-02-26 Thread Paul Bourke


Hey Kolla,

Hope you're all enjoying Dublin so far :) Some have expressed interest 
in getting together for a team meal, how does Thursday sound? Please 
reply to this with +1/-1 and I can see about booking something.


Cheers,
-Paul

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

2018-02-05 Thread Paul Bourke


On 05/02/18 10:25, Christian Berendt wrote:

Hello Paul.


On 5. Feb 2018, at 11:12, Paul Bourke <paul.bou...@oracle.com> wrote:

This does not mean I don't have a vision for Kolla - no project is perfect



Regardless of that, I would be interested in your visions. What specifically do 
you want to tackle in the next cycle in kolla? What should be the focus?

Christian.



Hi Christian,

Sure thing :) To sum it up I would like to see us focus on Kolla in 
production environments. This is the mission of the project, and we 
still have ways to go. Specifically:


* Improving our tooling. Currently kolla-ansible (as in the shell 
script) is very simplistic and requires operators to go under to the 
hood for basic things such as checking the health of their cloud, 
diffing configs, viewing logs, etc. [0]


* Related to the above, we need improved monitoring in Kolla.

* Finish the zero downtime upgrade work.

* Resolving issues around configuration [1]. We need to decide how much 
we want to provide and make it as straight forward as possible for 
operators to override.


* Documentation should continue to be a priority.

* Finally, I would like to start the discussion of moving each element 
of Kolla out into separate projects. In particular I think this needs to 
happen with kolla-kubernetes but potentially the images also.


Each of these are areas that I've specifically heard from real world 
operators, and also I think are key to the future and overall health of 
the project. If you'd like to discuss any in more detail please give me 
a shout at any time.


-Paul

[0] https://blueprints.launchpad.net/kolla/+spec/kolla-multicloud-cli
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126663.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-dev] [kolla] Rocky PTL candidacy

2018-02-05 Thread Paul Bourke


Hello all,

I've been involved with Kolla since it's early stages around Liberty, 
where we saw it evolve through multiple iterations of image formats, 
orchestration methods and patterns into the project we know and love.


From my perspective the community is one of the best things about 
Kolla. You are the ones that keep config files up to date as OpenStack 
evolves, continue to implement new roles and images, keep the gates up 
and running, the list goes on. With this mind, I won't list a bunch of 
features that I'd like to accomplish for Rocky. Rather, I would like to 
spend time listening to what you as users would like to see in the 
project, and doing whatever I possibly can to help you achieve that. 
This does not mean I don't have a vision for Kolla - no project is 
perfect, and there are plenty of areas I think could use some 
refinement. My hope is through discussion and collaboration we can 
continue to iterate to ensure this project is as useful as possible to 
our users.


I hope you will consider me to serve you as your PTL for the coming cycle.

Thank you!

-Paul

__
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

2018-01-30 Thread Paul Bourke


On 30/01/18 12:54, Simon Leinen wrote:

The perceived downside of (2) - or a perceived advantage of (1) - is
that in an ideal world, (1) isolates us from the arcane configuration
file details that the crazy devs of individual services come up with.
In practice, it turns out that (a) those files aren't rocket science (b)
as an operator you need to understand them anyway,


Thanks very much for taking the time to provide input Simon, it's very 
valuable. I think you sum it up well, definitely approach (1) is easier 
to newcomers who want to get up and going quickly without having to read 
too much into the files they're customising. In reality anyone going 
beyond a demo environment will need to do so.


__
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

2018-01-30 Thread Paul Bourke

So I think everyone is in agreement that it should be option 2. I'm 
leaning towards this also but I'm wondering how much of this makes 
things easier for us as developers rather than operators.


How committed this are we in practice? For example, if we take 
nova.conf[0], if we follow option 2, theoretically all alternate 
hypervisor options (vmware/xen/nova-fake) etc. should come out and be 
left to override files. As should options templating options such as 
metadata_workers, listen ports, etc. globals.yml could probably be half 
the size it currently is. But if we go this route how many operators 
will stick with kolla? Maybe it won't be a big deal, the issue currently 
is the line is blurred on what gets templated and what doesn't.


On 30/01/18 01:04, Michał Jastrzębski wrote:

Hey,

So I'm also for option 2. There was big discussion in Atlanta about
"how hard it is to keep configs up to date and remove deprecated
options". merge_config makes it easier for us to handle this. With
amount of services we support I don't think we have enough time to
keep tabs on every config change across OpenStack.

On 29 January 2018 at 08:03, Steven Dake (stdake) <std...@cisco.com> wrote:

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 <zhang.lei@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
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 <paul.bou...@oracle.com> 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 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



__
Ope

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

2018-01-29 Thread Paul Bourke


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

[openstack-dev] [zuul] Cannot view log outputs in browser

2018-01-23 Thread Paul Bourke

Apologies if this has been asked before. It seems as of late (I think 
since the roll out of zuul v3, I can't seem to view job outputs directly 
in my browser. E.g. when I click link[0], I have to download 
'job-output.txt.gz', unzip it, rename the extension to '.html', and 
finally open it in a browser. I've tried this with both Chrome 
63.0.3239.132 and Firefox 57.0.4, OS Ubuntu 16.04.


Is anyone else seeing this issue?

Thanks,
-Paul

[0] 
http://logs.openstack.org/71/535671/11/check/kolla-ansible-oraclelinux-source-ceph/e63c60c/job-output.txt.gz 



__
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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

2017-12-12 Thread Paul Bourke

From my understanding it would be a cleanup operation - which to be
honest, would be very much welcomed. I recently did a little work with
Castellan to integrate it with Murano and found the auth code to be very
messy, and flat out broken in some cases. If it's possible to let the
barbican client take care of this that sounds good to me.

> Which mode is used the most in the services that consume castellan
> today?

Afaik Barbican is the only backend that currently exists in Castellan
[0]. Looking again it seems some support has been added for vault which
is great, but I reckon Barbican would still be the primary use.

I haven't been hugely active in Castellan but if the team would like
some more input on this or reviews please do ping me, I'd be glad to help.

-Paul

[0] https://github.com/openstack/castellan/tree/master/castellan/key_manager

On 06/12/17 22:12, Doug Hellmann wrote:

Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:

It's been a bit since the summit but I believe this was also discussed at
the Denver PTG as well: https://etherpad.openstack.org/p/oslo-ptg-queens

The keystoneauth stuff seems to be more from Sydney, but if I remember
correctly, Castellan authenticates through keystoneauth and passes the
session to barbicanclient. This is the only use of keystoneauth within
Castellan, so one idea that was mentioned was to see if Castellan could
simply pass the credentials to barbicanclient, which would auth through
keystoneauth instead, removing the dependency from Castellan.

It looks like Castellan tries to authenticate using the token from
the context in two separate cases [1]. That would cause the service
using castellan to connect to barbican as the user making the API
request. Removing the use of keystoneauth would mean that feature
would no longer work, and all requests to barbican would be made
as a hard-coded user. That seems like a pretty fundamental difference
in behavior.

Which mode is used the most in the services that consume castellan
today?

I'm still not understanding the real motivation for removing the
dependency. Is it just someone's notion of cleaning things up? Or is
there a runtime issue of some sort?

Doug

[1]
http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140

On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann
wrote:

Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:

So from my understanding now, we are wanting to remove the HARD

dependency on Keystoneauth, not to remove it completely since that would
break the barbican client. Currently seeing if we just remove the
dependency from requirements.txt, if that stops Keystoneauth from being
used until you try to use the barbican.

There would need to be more changes than that, because we still need the
package to be installed for testing the Barbican driver.

Maybe if someone could explain what the issue is, I can offer more
detailed advice. What is wrong with having the keystoneauth dependency?
Is it breaking something? Is it interfering with some other library?

Doug

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

2017-11-28 Thread Paul Bourke

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-11-02 Thread Paul Bourke


+1

On 02/11/17 15:58, 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] [all] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

2017-09-20 Thread Paul Bourke


I had the following bookmark:

status:open is:mergeable (project:openstack/kolla OR 
project:openstack/kolla-ansible) NOT label:Code-Review>=-2,self NOT 
owner:pauldbourke NOT age:1month branch:master


Which basically means, find changes that are:

* open
* in kolla or kolla-ansible
* not reviewed by me
* not owned by me
* not older than a month
* on the master branch

This seems to no longer work unless I remove the 
'label:Code-Review>=-2,self'.


Anyone else having similar issues?

On 19/09/17 00:58, Clark Boylan wrote:

On Mon, Sep 18, 2017, at 06:43 AM, Andreas Jaeger wrote:

Just a friendly reminder that the upgrade will happen TODAY, Monday
18th, starting at 15:00 UTC. The infra team expects that it takes 8
hours, so until 2359 UTC.


This work was functionally completed at 23:43 UTC. We are now running
Gerrit 2.13.9. There are some cleanup steps that need to be performed in
Infra land, mostly to get puppet running properly again.

You will also notice that newer Gerrit behaves in some new and exciting
ways. Most of these should be improvements like not needing to reapprove
changes that already have a +1 Workflow but also have a +1 Verified;
recheck should now work for these cases. If you find a new behavior that
looks like a bug please let us know, but we should also work to file
them upstream so that newer Gerrit can address them.

Feel free to ask us questions if anything else comes up.

Thank you to everyone that helped with the upgrade. Seems like these get
more and more difficult with each Gerrit release so all the help is
greatly appreciated.

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

[openstack-dev] [murano] ptg meetup

2017-09-13 Thread Paul Bourke


Hi,

Would those of us at the PTG like to agree on a time to meet for an 
informal Murano chat? Does Friday suit?


Regards,
-Paul

__
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] ceph_osd error when startup ceph_osd container.

2017-07-11 Thread Paul Bourke


Hi,

This usually means your ceph mons have failed to cluster correctly. The 
osd bootstrap calls 'ceph quorum_status' to ensure a successful quorum 
before proceeding. If the mons are blocked or otherwise unavailable this 
command can time out which is likely what you're seeing. Make sure the 
ceph_mon containers have started correctly, you have the correct amount 
of them, etc.


Regards,
-Paul

On 11/07/17 02:47, zhou...@zte.com.cn wrote:

Hi kolla-ansible team:

 I have met a weird problem when start up the ceph_osd container。

CONTAINER IDIMAGE   
   COMMAND CREATED STATUS   
  PORTS   NAMES


64b4617ff50210.20.11.2:4000/kolla/centos-binary-ceph-osd:4.0.2   
  "kolla_start"   13 hours agoExited (1) 13 hours ago   
 bootstrap_osd_0



docker logs 64b4617ff502

2017-04-28 16:32:51.854980 7f6e3795b700  0 monclient(hunting): 
authenticate timed out after 300


2017-04-28 16:32:51.855032 7f6e3795b700  0 librados: client.admin 
authentication error (110) Connection timed out


Error connecting to cluster: TimedOut


ceph version 10.2.7 (50e863e0f4bc8f4b9e31156de690d765af245185)


have you ever met this problem?And I am appreciate it if you give me 
some help,thank you very much.



B.R.

zhouya


周亚


IT开发工程师 IT Development Engineer
虚拟化南京三部/无线研究院/无线产品经营部 NIV Nanjing Dept. III/Wireless 
Product R＆D Institute/Wireless Product Operation Division




南京市雨花台区花神大道6号中兴通讯一区二期5楼A区
A District, 5/F, R Building, ZTE Corporation Plaza,#6 Huashen Ave.
Yuhuatai District, Nanjing, P..R.China, 210012
T: +86 13951010061 M: +86 13772010248
E: zhou...@zte.com.cn
www.zte.com.cn 



__
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] why common_options type is dictionary ?

2017-07-11 Thread Paul Bourke

Because its a series of key value pairs: 
https://github.com/openstack/kolla-ansible/blob/master/ansible/group_vars/all.yml#L96-L105


Is there another type you feel would fit better?

On 11/07/17 05:22, Margin Hu wrote:

Hi Guys:

I want to set docker_common_options parameter but find its type is 
dictionary.  why?


ansible/roles/zun/tasks/pull.yml:5:common_options: "{{ 
docker_common_options }}"
tests/test_kolla_docker.py:44: common_options=dict(required=False, 
type='dict', default=dict()),





__
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-ansible] Proposing Surya (spsurya) for core

2017-06-14 Thread Paul Bourke


+1, thanks Surya for all your work

On 14/06/17 16:46, Michał Jastrzębski wrote:

Hello,

With great pleasure I'm kicking off another core voting to
kolla-ansible and kolla teams:) this one is about spsurya. Voting will
be open for 2 weeks (till 28th Jun).

Consider this mail my +1 vote, you know the drill:)

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

[openstack-dev] [murano] [barbican] Re: Need your opinion on another issue...

2017-06-13 Thread Paul Bourke


Hi Stan,

Thanks for your input on this.

I'm finding the problem with doing the encryption/decryption on the 
engine side only is that at this point it is too late - the object model 
has already been written into the database at the API layer. I can't 
think how we can change this without moving the data persist logic into 
the engine which would be quite a large change.


If we encrypt just user specified properties on session create, this may 
still work as you outline, but this leads to the problem of how to 
signal to the API which property values are to be encrypted, as metadata 
and contracts are again only parsed once the object model reaches the 
engine.


The only other things I can think to improve this would be to either use 
some form of caching such as memcached, or drop barbican and do some 
form of local crypto that avoids the round trip time to barbican. 
Neither seem ideal.


If you have any other ideas on this or if some of the assumptions I've 
made above wrt the engine are incorrect I'd appreciate your thoughts. 
The current approach where we encrypt the entire object model is 
available as a work in progress at https://review.openstack.org/#/c/471772/.


Thanks again,
-Paul

On 08/06/17 04:09, Stan Lagun wrote:

Hi Ellen,

If you want my opinion I wouldn't recommend encrypt all the object model 
as it can create a lot of issues like this. What I suggest instead is to 
have special contract
(say $.secureString()) which does the decryption/encryption right from 
the engine while all calls to API would result in object model with some 
encrypted fields. This way
it would be possible to have this contract only for password and similar 
properties. I'd also introduce encryptString()/decryptString() yaql 
functions so that it would be possible
to do it manually (for example, to store sensitive values in attributes, 
which do not have contracts). But this can be done later. With contracts 
encryption would be completely
transparent to the rest of the code. Also, AFAIK MySQL enterprise has 
encryption capabilities so that you can make DB with object model be 
encrypted as well.


Regards,
Stan


On June 7, 2017 at 4:33:54 PM, Ellen Batbouta (ellen.batbo...@oracle.com 
) wrote:




Hi Stan,

Thanks for your last mail. Today, I am trying it out. It looks 
promising but haven't

gotten too far due to many interruptions.

Onto another issue that Paul and I would like your opinion on. Paul is 
a co-worker of mine

and he is working on the murano blueprint,

https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties 



and has posted a spec and code review. The reason we need to encrypt 
the object model (or at least some
of the attributes) is because our database application contains 
passwords and we cannot have these
passwords stored in the database in clear text. We must absolutely fix 
this and for the Pike release.


A short summary (from Paul's code review) is:

This commit introduces optional integration for Murano with Barbican 
(or any other key manager supported via Castellan). When enabled, all 
object model will first be encrypted into Barbican, and a 'secret key' 
will be written to the Murano database in it's place. The code is 
compatible with mixed (encrypted and unencrypted) databases, however, 
environments/sessions created when encrypt_data is on cannot be read 
if encrypt_data is subsequently turned off. The complete configuration 
required in the api murano.conf to enable this change is as follows:


[murano]

encrypt_data = True

[barbican]
auth_endpoint = :

However, he is running into a performance problem. When listing the 
environments, the performance is
slow. The Murano code looks up the object model multiple times, which 
results in multiple calls to barbican.


Is it possible to reduce the number of look ups for the object model? 
We will be investigating further.

Just wondering if you have an opinion on this.

Thank you.

Ellen.


__
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] [murano][barbican] Encrypting sensitive properties

2017-06-01 Thread Paul Bourke

Thanks for that Kirill. Optional sounds good. Right now I'm leaning
towards encrypting the full object model in the database rather than
selective attributes, I can't think of a reason not to do this and it
makes things more transparent and straight forward for the user. I've
added a spec for this at https://review.openstack.org/#/c/469467/ if you
have a chance to review.

Regards,
-Paul

On 31/05/17 17:59, Kirill Zaitsev wrote:
As long as this integration is optional (i.e. no barbican — no
encryption) It feels ok to me. We have a very similar integration with
congress, yet you can deploy murano with or without it.

As for the way to convey this, I believe metadata attributes were
designed to answer use-cases like this one. see
https://docs.openstack.org/developer/murano/appdev-guide/murano_pl/metadata.html for
more info.

Regards, Kirill

Le 25 мая 2017 г. à 18:49, Paul Bourke <paul.bou...@oracle.com
<mailto:paul.bou...@oracle.com>> a écrit :

Hi all,

I've been looking at a blueprint[0] logged for Murano which involves
encrypting parts of the object model stored in the database that may
contain passwords or sensitive information.

I wanted to see if people had any thoughts or preferences on how this
should be done. On the face of it, it seems Barbican is a good choice
for solving this, and have read a lengthy discussion around this on
the mailing list from earlier this year[1]. Overall the benefits of
Barbican seem to be that we can handle the encryption and management
of secrets in a common and standard way, and avoid having to implement
and maintain this ourselves. The main drawback for Barbican seems to
be that we impose another service dependency on the operator, though
this complaint seems to be in some way appeased by Castellan, which
offers alternative backends to just Barbican (though unsure right now
what those are?). The alternative to integrating Barbican/Castellan is
to use a more lightweight "roll your own" encryption such as what
Glance is using[2].

After we decide on how we want to implement the encryption there is
also the question of how best to expose this feature to users. My
current thought is that we can use Murano attributes, so application
authors can do something like this:

- name: appPassword
type: password
encrypt: true

This would of course be transparent to the end user of the
application. Any thoughts on both issues are very welcome, I hope to
have a prototype in the next few days which may help solidify this also.

Regards,
-Paul.

[0]
https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
[2]
https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [murano][barbican] Encrypting sensitive properties

2017-05-25 Thread Paul Bourke


Hi all,

I've been looking at a blueprint[0] logged for Murano which involves 
encrypting parts of the object model stored in the database that may 
contain passwords or sensitive information.


I wanted to see if people had any thoughts or preferences on how this 
should be done. On the face of it, it seems Barbican is a good choice 
for solving this, and have read a lengthy discussion around this on the 
mailing list from earlier this year[1]. Overall the benefits of Barbican 
seem to be that we can handle the encryption and management of secrets 
in a common and standard way, and avoid having to implement and maintain 
this ourselves. The main drawback for Barbican seems to be that we 
impose another service dependency on the operator, though this complaint 
seems to be in some way appeased by Castellan, which offers alternative 
backends to just Barbican (though unsure right now what those are?). The 
alternative to integrating Barbican/Castellan is to use a more 
lightweight "roll your own" encryption such as what Glance is using[2].


After we decide on how we want to implement the encryption there is also 
the question of how best to expose this feature to users. My current 
thought is that we can use Murano attributes, so application authors can 
do something like this:


- name: appPassword
  type: password
  encrypt: true

This would of course be transparent to the end user of the application. 
Any thoughts on both issues are very welcome, I hope to have a prototype 
in the next few days which may help solidify this also.


Regards,
-Paul.

[0] 
https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
[2] 
https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py


__
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] [murano] Meeting time

2017-05-24 Thread Paul Bourke

Hi Felipe,

From our end I think one hour earlier would be great.

> I can create a patch in infra and add you and others to it to
> allow for people to effectively vote for what times you prefer.

Sure thing that sounds good!

-Paul

On 24/05/17 03:56, Felipe Monteiro wrote:

Hi Paul,

I'm open to changing the meeting time, although I'd like some input from
Murano cores, too. What times work for you and your colleagues? I can
create a patch in infra and add you and others to it to allow for people
to effectively vote for what times you prefer.

Felipe

On Tue, May 23, 2017 at 12:08 PM, Paul Bourke <paul.bou...@oracle.com
<mailto:paul.bou...@oracle.com>> wrote:

Hi Felipe / Murano community,

I was wondering how would people feel about revising the time for
the Murano weekly meeting?

Personally the current time is difficult for me to attend as it
falls at the end of a work day, I also have some colleagues that
would like to attend but can't at the current time.

Given recent low attendance, would another time suit people better?

Thanks,
-Paul

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

[openstack-dev] [murano] Meeting time

2017-05-23 Thread Paul Bourke


Hi Felipe / Murano community,

I was wondering how would people feel about revising the time for the 
Murano weekly meeting?


Personally the current time is difficult for me to attend as it falls at 
the end of a work day, I also have some colleagues that would like to 
attend but can't at the current time.


Given recent low attendance, would another time suit people better?

Thanks,
-Paul

__
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

2017-05-02 Thread Paul Bourke


+1 of course from myself. Good job Bertrand.

On 02/05/17 16:30, Michał Jastrzębski wrote:

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] [kolla] Tags, revisions, dockerhub

2017-04-19 Thread Paul Bourke

I'm wondering if moving to using docker labels is a better way of 
solving the various issue being raised here.


We can maintain a tag for each of master/ocata/newton/etc, and on each 
image have a LABEL with info such as 'pbr of service/pbr of kolla/link 
to CI of build/etc'. I believe this solves all points Kevin mentioned 
except rollback, which afaik, OpenStack doesn't support anyway. It also 
solves people's concerns with what is actually in the images, and is a 
standard Docker mechanism.


Also as Michal mentioned, if users are concerned about keeping images, 
they can tag and stash them away themselves. It is overkill to maintain 
hundreds of (imo meaningless) tags in a registry, the majority of which 
people don't care about - they only want the latest of the branch 
they're deploying.


Every detail of a running Kolla system can be easily deduced by scanning 
across nodes and printing the labels of running containers, 
functionality which can be shipped by Kolla. There are also methods for 
fetching labels of remote images[0][1] for users wishing to inspect what 
they are upgrading to.


[0] https://github.com/projectatomic/skopeo
[1] https://github.com/docker/distribution/issues/1252

-Paul

On 18/04/17 22:10, Michał Jastrzębski wrote:

On 18 April 2017 at 13:54, Doug Hellmann  wrote:

Excerpts from Michał Jastrzębski's message of 2017-04-18 13:37:30 -0700:

On 18 April 2017 at 12:41, Doug Hellmann  wrote:

Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200:

On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann 
wrote:


Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:

My dear Kollegues,

Today we had discussion about how to properly name/tag images being
pushed to dockerhub. That moved towards general discussion on revision
mgmt.

Problem we're trying to solve is this:
If you build/push images today, your tag is 4.0
if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
we tag new release.

But image built today is not equal to image built tomorrow, so we
would like something like 4.0.0-1, 4.0.0-2.
While we can reasonably detect history of revisions in dockerhub,
local env will be extremely hard to do.

I'd like to ask you for opinions on desired behavior and how we want
to deal with revision management in general.

Cheers,
Michal



What's in the images, kolla? Other OpenStack components?



Yes, each image will typically contain all software required for one
OpenStack service, including dependencies from OpenStack projects or the
base OS. Installed via some combination of git, pip, rpm, deb.


Where does the
4.0.0 come from?



Its the python version string from the kolla project itself, so ultimately
I think pbr. I'm suggesting that we switch to using the
version.release_string[1] which will tag with the longer version we use for
other dev packages.

[1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py


Why are you tagging the artifacts containing other projects with the
version number of kolla, instead of their own version numbers and some
sort of incremented build number?


This is what we do in Kolla and I'd say logistics and simplicity of
implementation. Tags are more than just information for us. We have to


But for a user consuming the image, they have no idea what version of
nova is in it because the version on the image is tied to a different
application entirely.


That's easy enough to check tho (just docker exec into container and
do pip freeze). On the other hand you'll have information that "this
set of various versions was tested together" which is arguably more
important.


deploy these images and we have to know a tag. Combine that with clear
separation of build phase from deployment phase (really build phase is
entirely optional thanks to dockerhub), you'll end up with either
automagical script that will have to somehow detect correct version
mix of containers that works with each other, or hand crafted list
that will have 100+ versions hardcoded.

Incremental build is hard because builds are atomic and you never
really know how many times images were rebuilt (also local rebuilt vs
dockerhub-pushed rebuild will cause collisions in tags).


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 Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [murano] [heat] [cinder] MuranoPL types question

2017-03-31 Thread Paul Bourke

Thanks for the tips Stan.

> it is stored exactly as it comes from Heat. In theory conversion to
> string could happen on Heat side, but most likely it just the output 
> of reporter made it look like this

Did some digging and it actually seems to be a string on heat's end. 
python-cinderclient seems to present volume attachment info as a list:

"""
from cinderclient.v2 import Client
...
for i in cinder.volumes.list():
  print(type(i.attachments))

"""

whereas printing the value of outputs from python-heatclient gives:

"""
from heatclient.client import Client
...
s = heat.stacks.get('murano--sjsbdj0xwhrkz2')
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(s.outputs)

[   {   u'description': u'No description given',
u'output_key': 
u'vol-08aea08f-f553-4f71-b839-bf4637516eaf-attachments',
u'output_value': u"[{u'server_id': 
u'0f5731c1-da17-4209-a2ef-270c7056f9a3', u'attachment_id': u'88
1a5cea-be9e-4335-ad37-a24d09b36911', u'attached_at': 
u'2017-03-31T14:05:26.00', u'host_name': None, u'
volume_id': u'6c97f825-32e9-4369-8580-a4a576e67612', u'device': 
u'/dev/vda', u'id': u'6c97f825-32e9-4369-8

580-a4a576e67612'}]"},

u'output_key': u'addresses--ae9a638e712d450a87492ed792025a97',
u'output_value': [   {   u'OS-EXT-IPS-MAC:mac_addr': 
u'fa:16:3e:f6:26:ab',

 u'OS-EXT-IPS:type': u'fixed',
 u'addr': u'10.0.61.12',
 u'port': 
u'7967a4de-ccc1-49ec-a35c-f4d515e6cc96',

 u'version': 4}]},

"""

(note the value for 'addresses--ae9a638e712d450a87492ed792025a97' is in 
the correct format)

Changing the schema type of this in heat from STRING to LIST fails to 
validate[0], so somewhere between cinder and heat this is not getting 
deserialised properly.

Anyhow, I think the issue has moved beyond the scope of MuranoPL, so I'm 
just sending this more as a follow up for anyone who happens to be reading.

Thanks again for pointing me in the right direction.

-Paul

[0] 
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/cinder/volume.py#L222-L225

On 30/03/17 19:55, Stan Lagun wrote:

Hi Paul,

Here both key and value appear to be a string (note, I can't confirm this as 
the typeinfo function doesn't appear to be available in Instance.yaml for some 
reason... perhaps I'm using it wrong)

They are not strings. Reporter converts everything that is passed to it
into string by doing unicode(obj). What you see is the Python string
representation of lists and dicts, where every unicode string is
prefixed with "u".
Typinfo function works on objects (instances of MuranoPL classes), not
on primitive types like strings, dicts and lists.

1) Why is the content of this 'get_attr' coming from heat being stored in the 
stack outputs as a string,

it is stored exactly as it comes from Heat. In theory conversion to
string could happen on Heat side, but most likely it just the output of
reporter made it look like this

2) Is there a way I can cast this to a list of dicts or similar

structure so it can be iterated as expected?
It's hard to answer without seeing your code and how you got the results
that you provided.

 when I access this from a sample app, I end up with a list of strings,

shown by $reporter as: ...

Curly braces in the output indicate that this is not a list of strings
but rather the single dict converted to a string by reporter. So what
you see is the value of
that 'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments' output,
which sounds like what you're wanted it to be. In MuranoPL you can have
very detailed contracts: not just [] (any list) but something like
Contract:
  - key1: string().notNull()
key2: int().notNull()

which is a list of dicts with contract on each dict entry. If you don't
get contract violation exception, you can be sure that the list contains
list of dicts with appropriate keys/values rather than list of strings
or anything else

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<mailto:sla...@mirantis.com>

On Thu, Mar 30, 2017 at 10:17 AM, Paul Bourke <paul.bou...@oracle.com
<mailto:paul.bou...@oracle.com>> wrote:

Hi Stan,

I had a quick(hopefully) question about MuranoPL that I hope you
might be able to help with, Felipe had mentioned you are very
knowledgeable in this area. If you don't have time please disregard!

I'm working on a patch for the Murano core library to make volume
attachment info available, which is available at
https://review.openstack.org/451909
<https://review.openstack.org/451909>. It's mostly working, but I'm
having some issues getting the types correct in MuranoPL to make
this info consumable by end users.

The attachment info from a sample run in the stack $outputs looks
like th

[openstack-dev] [murano] MuranoPL types question

2017-03-30 Thread Paul Bourke


Hi Stan,

I had a quick(hopefully) question about MuranoPL that I hope you might 
be able to help with, Felipe had mentioned you are very knowledgeable in 
this area. If you don't have time please disregard!


I'm working on a patch for the Murano core library to make volume 
attachment info available, which is available at 
https://review.openstack.org/451909. It's mostly working, but I'm having 
some issues getting the types correct in MuranoPL to make this info 
consumable by end users.


The attachment info from a sample run in the stack $outputs looks like 
this (taken from the dashboard using $reporter)


u'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments': 
u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682', 
u'attachment_id': u'7456a4b0-3abd-48a0-a0cb-f3fa0f2706bb', 
u'attached_at': u'2017-03-30T16:51:57.00', u'host_name': None, 
u'volume_id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b', u'device': 
u'/dev/vda', u'id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b'}]"


Here both key and value appear to be a string (note, I can't confirm 
this as the typeinfo function doesn't appear to be available in 
Instance.yaml for some reason... perhaps I'm using it wrong)


My goal is to then set this into a property of CinderVolume.yaml, with a 
Contract of '[]'. However, when I access this from a sample app, I end 
up with a list of strings, shown by $reporter as:


(u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682', 
u'attachment_id': u'f5bd50ab-4040-4e2b-8b50-790781d9bc37', 
u'attached_at': u'2017-03-30T16:51:59.00', u'host_name': None, 
u'volume_id': u'ed7eb535-9e81-4c97-b063-86936d4ee306', u'device': 
u'/dev/vdb', u'id': u'ed7eb535-9e81-4c97-b063-86936d4ee306'}]",)


So my question is:

1) Why is the content of this 'get_attr' coming from heat being stored 
in the stack outputs as a string, and


2) Is there a way I can cast this to a list of dicts or similar 
structure so it can be iterated as expected?


Any tips much appreciated.

Thanks,
-Paul

__
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] [ironic] Introducing Kayobe - Scientific OpenStack deployment using kolla

2017-03-30 Thread Paul Bourke


Looks really cool Mark, congrats on the release!

-Paul

On 30/03/17 09:46, Mark Goddard wrote:

Hi,

I'd like to announce Kayobe[1], a project that we at StackHPC have been
working on recently as we help to build out a performance prototyping
platform for the SKA telescope[2].

Kayobe is an open source tool for automating deployment of Scientific
OpenStack onto a set of bare metal servers. Kayobe is composed of
Ansible playbooks, a python module, and makes heavy use of the OpenStack
kolla project. Kayobe aims to complement the kolla-ansible project,
providing an opinionated yet highly configurable OpenStack deployment
and automation of many operational procedures. Further information is
available in the project's documentation[3].

In our recent blog post[4] we discuss some of the Zero Touch
Provisioning (ZTP) capabilities of the project that allowed us to
quickly commission the hardware for the SKA performance prototype
platform. To achieve this, Kayobe leverages ironic inspector's
introspection rules and node discovery, and Ansible's networking
modules. We think these techniques may be applicable to other deployment
tools such as TripleO and would be interested to share experiences and
code with those communities.

We'd love to hear feedback from the OpenStack community on the direction
this project is taking, and of course encourage interested parties to
get involved!

Thanks,
Mark (mgoddard)

[1] https://github.com/stackhpc/kayobe/

[2] https://skatelescope.org/
[3] https://github.com/stackhpc/kayobe/tree/master/doc

[4] https://www.stackhpc.com/ironic-idrac-ztp.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] Proposing duonghq for core

2017-03-08 Thread Paul Bourke


+1

On 08/03/17 08:29, Jeffrey Zhang wrote:

+1 from me

On Wed, Mar 8, 2017 at 2:41 PM, Michał Jastrzębski > wrote:

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





--
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][keystone] better way to rotate and distribution keystone fernet keys in container env

2017-03-06 Thread Paul Bourke


Two initial ideas:

We could create a specific ansible task to rotate the keys, and document 
that operator should set up a cron job on the deployment node to run 
this periodically.


We could also look at making use of VRRP (keepalived). Potentially the 
cron job could run on every controller, but only take action if it 
identifies it's the one with the VIP.


The second seems preferable to me as it requires no additional effort on 
the part of the operator. Maybe there's problems with this though that 
I'm not thinking of.


-Paul

On 06/03/17 05:52, Jeffrey Zhang wrote:

fix subject typo

On Mon, Mar 6, 2017 at 12:28 PM, Jeffrey Zhang > wrote:

Kolla have support keystone fernet keys. But there are still some
topics worth to talk.

The key issue is key distribution. Kolla's solution is like

* there is a task run frequently by cronjob to check whether
  the key should be rotate. This is controlled by
  `fernet_token_expiry` variable
* When key rotate is required, the task in cron job will generate a
  new key by using `keystone-manage fernet-rotate` and distribute all
  keys in /etc/keystone/fernet-keys folder to other by using
  `rsync --delete`

one issue is: there is no global lock in rotate and distribute steps.
above command is ran on all controllers. it may cause issues if
all controllers run this at the same time.

Since we are using Ansible as deployment tools. there is not daemon
agent at all to keep rotate and distribution atomic. Is there any
easier way to implement a global lock?

possible solution:
1. configure cron job with different time on each controller
2. implement a global lock? ( no idea how )

[0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html


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



__
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] Structuring the documentation on all repositories

2017-02-20 Thread Paul Bourke


Hi Christian,

Thanks for the summary, useful for those of us not at the PTG.

I'm a little confused on the final outcome, it sounds like most of what 
you've written is currently the case.


Besides a more user friendly deploy guide appearing under 
https://docs.openstack.org/project-deploy-guide/ocata/, what is changing?


Thanks,
-Paul

On 20/02/17 16:34, Christian Berendt wrote:

This is a summary about structuring the documentation on all repositories as 
discussed at the PTG (https://etherpad.openstack.org/p/kolla-pike-ptg-docs).

The doc directory:

kolla/doc — kolla developer documentation (about our docker images) and generic 
documentation
kolla-ansible/doc — kolla-ansible developer documentation
kolla-k8s/doc — kolla-k8s developer documentation

Contents will be published to https://docs.openstack.org/developer/kolla…/

The doc directory in the kolla repositories will be splitted into 2 parts and 
will keep the generic kolla documentation (landing page, mission, philosophy, 
explanation of deliverables, overview of deployment guides (previous QSG), bug 
triage, how to contribute, ...) and the development documentation related to 
kolla images.

The central entry point (landing page) for the kolla project will be 
https://docs.openstack.org/developer/kolla.

The deploy-guide directory:

kolla-ansible/deploy-guide — Kolla deployment guide for Ansible, how to deploy 
with kolla-ansible (previous name: quick start guide)
kolla-k8s/deploy-guide — Kolla deployment guide for K8S, how to deploy with 
kolla-k8s (previous name: quick start guide)

We will add 2 links to https://docs.openstack.org/project-deploy-guide/ocata/:

* Kolla deployment guide for Ansible
* Kolla deployment guide for K8S

Sample split for kolla-ansible prepared at 
https://review.openstack.org/#/c/427965/.

The guides itself will be published at 
https://docs.openstack.org/project-deploy-guide/ocata/kolla-ansible and 
https://docs.openstack.org/project-deploy-guide/ocata/kolla-k8s.

Christian.



__
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] Docs status?

2017-01-26 Thread Paul Bourke


All,

After some further discussion in the last meeting I have submitted a 
patch here: https://review.openstack.org/#/c/425749/


If you look at the number of conflicting patches I think it highlights 
the problem I'm trying to solve here, where ansible related patches are 
still been submitted against the kolla repository.


Please have a look if you have time.

Thanks,
-Paul

On 24/01/17 12:06, Paul Bourke wrote:

Hi Kolla,

Does anyone know the current status of docs refactor? I believe there
was someone looking into it (apologies can't remember their name).

If not, I'd like to propose a vote for some immediate changes that can
improve things.

Regards,
-Paul

__
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-ansible] How to restart working on a patch started before repo split?

2017-01-25 Thread Paul Bourke


Hi Hiroki,

To my knowledge it's not possible to change the target repository for an 
open patch. What we've done so far is to abandon the in progress one, 
cherry-pick to the correct repository and start a new review (adding the 
original author as a co-author of course).


Hope that helps,
-Paul

On 25/01/17 09:02, Hiroki Ito wrote:

Hi Kolla,

I would like to restart working on the following BP[0] and patch[1]. To
do so, I have to amend the patch and send to kolla-ansible since the
repository have been split into kolla and kolla-ansible, right?

[0] https://blueprints.launchpad.net/kolla-ansible/+spec/graceful-shutdown
[1] https://review.openstack.org/#/c/391420/

Thanks,




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-01-25 Thread Paul Bourke

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

Unfortunately it's not that simple, --limit by default will restrict 
fact gathering to that node only, resulting in missing facts for 
templates that require info about other nodes. Hence we have plays in to 
explicity gather facts when limit is used. See 
https://github.com/openstack/kolla-ansible/blob/master/ansible/site.yml#L15-L32 
for info on this also. Perhaps we're overcomplicating it, might be worth 
reaching out to people from Ansible for more info.

On 25/01/17 00:01, Mooney, Sean K wrote:

-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) 
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'.

http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack
-kolla.2017-01-09.log.html#t2017-01-09T21:33:15

This is where we were told the config stuff was "reference only"?

___

Kris Lindgren

Senior Linux Systems Engineer

GoDaddy

__

 OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/

[openstack-dev] [kolla] Docs status?

2017-01-24 Thread Paul Bourke


Hi Kolla,

Does anyone know the current status of docs refactor? I believe there 
was someone looking into it (apologies can't remember their name).


If not, I'd like to propose a vote for some immediate changes that can 
improve things.


Regards,
-Paul

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

2017-01-24 Thread Paul Bourke

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.

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.

[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/107833.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'.

http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2017-01-09.log.html#t2017-01-09T21:33:15

This is where we were told the config stuff was “reference only”?

___

Kris Lindgren

Senior Linux Systems Engineer

GoDaddy

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

2017-01-23 Thread Paul Bourke


Hi Kris,

Thanks for the feedback, I think everyone involved in kolla-ansible 
should take the time to read through it, as it definitely highlights 
some areas that we need to improve.


There's a lot of questions here, so I haven't gone into too much detail 
on any specific one; my hope is that I can clear up the majority of it 
and then we can follow up on some of the topics that require more 
discussion.


Hope it helps,
-Paul

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

You only need to define the top level groups, i.e. control, network, 
storage, monitoring, etc. If you don't want or have dedicated nodes for 
each of these groups it's fine to put the same node into multiple 
groups. So for example, if you're not interested in monitoring right 
now, you can just put your control node(s) under this and forget about 
it. The groups marked with [*:children] (e.g. bootstrap) are "groups of 
groups" and you shouldn't need to modify these at all.


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

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/107833.html


> * 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).

Agree a dry run would be useful, I believe it came up during the 
Barcelona design summit but has not yet been looked at. The ansible 
--diff sounds like something we could easily do, if you could log a 
blueprint at blueprints.launchpad.net/kolla-ansible I think that would help.


> * 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"?

This shouldn't be the case, I just double checked taking Glance as an 
example, it reports "ok" (no change) for all runs after the initial 
deploy. Perhaps you've come across a bug, if you think this is the case 
please log one.


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

Deploy includes bootstrap, but bootstrap is only done if the database is 
not found (or on upgrade). Again it sounds like you're coming across 
some unusual behavior here, suggest checking in with us on 
#openstack-kolla or filing a bug.


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

This is definitely something we need - I'm pretty sure I saw something 
around this in the review queue very recently. I can't find it off hand 
so hopefully someone can chip in here on the status of this work.


> * 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 
scripts?


Again, discussed, needs to happen, but not there as of yet.

> * Config must come from kolla-ansible and generated templates.  I
> know we have a patch up for externally managed service
> configuration.  But if we aren't suppose to use kolla-ansible for
> generating configs (see below), why cant we override this piece?

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

Re: [openstack-dev] [kolla] Bugs cleanup dashboard

2016-12-15 Thread Paul Bourke


This actually seems really useful, thanks Christian.

On 15/12/16 11:35, Christian Berendt wrote:

Hello everybody.

Based on the dashboard which is used for the Nova project I have created one 
for Kolla. The dashboard gets updated hourly.

http://kolla.betacloud.io/bugs-dashboard.html

Christian.



__
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] balancing core team karma and collecting statements from kolla team.

2016-12-08 Thread Paul Bourke

Right now I try to attack the bug list whenever I get time, admittedly 
it's not a regular activity though. I actually wasn't aware kolla and 
kolla-ansible had separate bug trackers, so far I've just been following 
the kolla one so this is good to know.


One issue I have is the fact that a large proportion of emails I get 
from launchpad are from people logging bugs just to submit a change 
(e.g. a change that needs backport or whatever). Hence the issues being 
filed by actual users having a problem can get drowned out by the noise 
from day to day development. It's not uncommon to come in to 200+ 
launchpad emails per day, there's simply not time to go through all these.


If anyone has tips on how to better filter these or ways backports could 
be tracked without having to create a bug just for record that would be 
great.


-Paul

On 08/12/16 14:26, Jeffrey Zhang wrote:

First of all, kolla team != kolla core reviewer members. everyone is
welcome to
reply this email.

Kolla ( including kolla, kolla-ansible and kolla-kubernetes projects )
is using
launchpad for bug track and blueprint management as other OpenStack
projects.
As kolla become more mature, we have more developers and operators.  So more
bugs are filed. we have 200+ bugs[0] and 100+ bp[1] in kolla project. it is
impossible to manage the states of the bugs and bp by few people.

Here is the list of activities in kolla launchpad[2]. Only a few persons are
busy on this. So hope more developers could work on this, including bug
triage
and confirmation. This is talked in the last meeting. We want to collect
some
information from kolla team.

1. Do u know how to manage bugs and bp on launchpad?
2. If 1) is yes, could u take the responsibility?
3. if 2) is yes, could u give your statement below about which project
will you
?

Here is the statement collected in the meeting,

sdake: I am not interested in bug triage for any deliverable but
kolla-kubernetes but know how to do bug triage
jeffrey4l: I will take the triage work for kolla and kolla-ansible
portdirect: I'm not that familiar with launchpad - srwilkers has given
me a few
pointers but I'm aware this a areanarea I need to get up to speed on
berendt: I know how to do it, but do not do it at the moment, I try to spend
some time on it
wirehead: I know how to do triage, it wasn't really a critical effort for
kolla-kubernetes, but I should start having time to at least pitch in
there.
duonghq: I can help in triaging, especially in kolla

If you are not in kolla-drivers team, you can ask for one of core team
to add
you.

[0] https://bugs.launchpad.net/kolla
[1] https://blueprints.launchpad.net/kolla
[2] https://launchpad.net/kolla/+topcontributors


--
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] propose to remove COPY_ONCE feature

2016-12-01 Thread Paul Bourke

While I would be interested to know how many people actually do use 
COPY_ONCE, I think if I was in charge of a production deployment I would 
use COPY_ONCE.


On 01/12/16 02:27, Jeffrey Zhang wrote:

Kolla has a config_strategy option during deployment. it supports
COPY_ONCE and
COPY_ALWAYS.  which means whether copy the configuration files defined in
config.json again during starting containers.

COPY_ALWAYS: copy all configuration files always during every start (
default
 value now )
COPY_ONCE: copy only once for the first start, then it
   won't copy even the configuration is changed

COPY_ALWAYS is more common for most users. change configuration, then
restart
containers and it works. but COPY_ONCE is not. after changing the
configuration,
should remove the container and start it again.

for COPY_ONCE, the pro is keeping immutability of the container.  the con is
making thing difficult. no matter for kolla code or end-user.

I am curiosity does end-user really care about the immutability cause by
configuration file? how many user really need such a feature?

So I propose to remove COPY_ONCE.

any idea is welcome ;)

--
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 to add zhubingbing to core team

2016-11-29 Thread Paul Bourke


+1

On 29/11/16 16:21, Michał Jastrzębski wrote:

Hello team!

I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
core teams. He did great job reviewing code during last couple of
months.

Consider this proposal +1 from me, voting will be open for 1 week
(until Dec 6) or if we get unanimous agreement (or veto) before.

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

[openstack-dev] [kolla] Notes on Ansible fact gathering

2016-11-23 Thread Paul Bourke

There is some concerns internally around Ansible fact gathering, and how
it relates to adding / removing individual nodes in Kolla. As I've spent
a fair bit of time in this area I decided to send some info around both
for anyone confused about this in the future and also to tease out any
ways we might be able to do this better.

Here is some info on how Ansible fact gathering works, and how it
relates to decisions around adding / removing single nodes.

Many roles need to know info about other nodes in the cluster. This is
true regardless of whether they are being deployed individually or as
part of a larger deploy. As Ansible is a push based tool, the only way
they can get this information is to ssh to those nodes and gather that
info in the form of 'facts'.

Ideally, Ansible would only touch (i.e. run fact gathering) on nodes
referenced inside it's play[2]. However, it is not smart enough to do
this, and so each node a play cares about must be listed explicitly up
front in the playbook. In the past this has being a maintenance burden,
as any time a new role was added that for example, needed to know about
the IP addresses of all rabbitmq servers, care had to be taken to also
list that group of nodes under that new play. If this wasn't done
correctly, it lead to the commonly reported "'dict object' has no
attribute u'ansible_eth0'".

After discussion and research it was determined by Kolla[0][1] that the
most reliable and pragmatic way to solve this was to gather facts about
all nodes up front, once. In the case of a full deploy, this will
essentially happen anyway. For the single node case however, it's not
ideal as it may visit more nodes than needed. It's still my belief that
this is the least error prone solution 'out of the box'. In the cases
where users have 500 control nodes and want to add five more
sequentially (the value of doing more than one sequentially is still not
clear to me), we could look into turning on fact caching. Given the fact
gathering in my experience is reasonably fast however, combined with
Ansible ssh pipelining, I'm not sure how much this would even gain.

-Paul

[0] https://review.openstack.org/#/c/376524/
[1] https://review.openstack.org/#/c/398313/
[2]
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova/templates/nova.conf.j2#L64

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

2016-11-21 Thread Paul Bourke

Propose all docs stay under the kolla namespace 
(http://docs.openstack.org/developer/kolla).


Steve mentioned that we should try to keep all components (e.g. mailing 
list tags) under the same umbrella which I agree with.


On 21/11/16 08:05, Jeffrey Zhang wrote:

After the split, we have two projects and two develop docs[0][1].
These two sites have lots of duplicated lines.

So will we split the doc site?
if so, we need to remove the duplicated doc in the repos.
if not, we need to remove one site's doc.

[0] http://docs.openstack.org/developer/kolla
[1] http://docs.openstack.org/developer/kolla-ansible/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-11-18 Thread Paul Bourke

If I'm understanding the requirement correctly, we want to know which 
version of an OpenStack component is installed in an image? If so why 
not just run something like:


# docker run kolla/oraclelinux-source-keystone:3.0.0 pip show keystone
Name: keystone
Version: 10.0.0.0rc2.dev290
[...]

Or equivalent for yum/apt. I'm not sure there's a need to implement 
anything beyond what is offered by package management tools.


On 18/11/16 11:51, Steven Dake (stdake) wrote:

Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider
audience.  I don’t have a clear solution to obtaining version manifests
for container content or the upstream container version.  Perhaps
someone in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be
run with docker exec to obtain a proper version manifest of both 1 and 2
(formatted in YAML or plaintext).  This could be placed in the base
container image to enable a general diagnostic and certificate of origin
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn "
>
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake >
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a
running container or image.
you know , the version info is wrapped by the container, it is not easy
to get them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by calling docker exec...
but how to get the one, Is there any way, Thanks.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
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][git]How to backport commit after repo split

2016-11-17 Thread Paul Bourke

Seen as both repos stem from the same codebase, we should be able to 
just cherry-pick changes as usual. If a fix comprises of a change to 
both kolla and kolla-ansible, it will just mean two cherry-picks. Will 
need to wait till the relevant pieces are removed from both repos to 
confirm this but I think it will work.


Here's an example using a recent change that just merged into kolla-ansible:

git clone https://github.com/openstack/kolla
cd kolla
git remote add kolla-ansible https://github.com/openstack/kolla-ansible
git fetch kolla-ansible
git checkout stable/newton
git cherry-pick -x 43517f48f5ab2b9d8fb22dc2a619b8d9f4f494d0

-Paul

On 17/11/16 14:02, Jeffrey Zhang wrote:

We have split kolla repo into two repos. the dockerfile related code
remains in kolla repo which builds images. and the ansible playbook
related code is moved into kolla-ansible which deploy the images.

But it brings a new challenge. How to backport the kolla-ansible
change to kolla in stable branch? i.e. cross-repository backport.

Does any guy have a solution for this case?

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

[openstack-dev] [git-upstream] How to view only commits applied since last import

2016-11-17 Thread Paul Bourke


Hi Darragh / git-upstream community,

I've been looking at a way to easily view a log of what commits made 
since the last upstream import when managing a branch with git-upstream. 
Right now this can be hard to do - something like 'git log 
upstream/master..HEAD' shows a lot of duplicate commits reasons I don't 
understand well enough to explain.


Darragh had suggested using the --dense option will help here, so 'git 
log --dense upstream/master..HEAD -- .' seems to generally give the 
right result. I've put up a patch to add this as a git-upstream command 
in the form of "carrying" at https://review.openstack.org/#/c/381669/. 
However, it seems there are in fact cases where the above command will 
show incorrect commits, and I'm struggling a bit to fully grok this.


My current understanding is we have a branch, that consists of a mixture 
of upstream commits from previous imports, and custom commits. We want 
to show a list of commits added since the last import. However, if those 
commits also contain commits from another non upstream branch, we want 
to exclude those? This makes sense with the example of say a packaging 
branch, but what if commits came from say a feature branch? Does it also 
make sense to ignore those?


Secondly, can you recap exactly how we find the most recent import 
commit? How does excluding the parent of this commit combined with 
--dense give the correct result? From your comment in Gerrit you 
identify it as the commit with the subject "[I] Merging E1 into E", but 
I can't see exactly how you spot this. Locally in the same scenario, 
taking the parent of the commit marked that subject and plugging it into 
the command is not showing the same graph as you pasted.


Thanks in advance for anything that might help cut through some of the 
confusion.


Cheers,
-Paul

__
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][kolla-kubernetes] Kolla core election policy change - vote

2016-11-17 Thread Paul Bourke


+1

On 17/11/16 07:18, Martin André wrote:

On Wed, Nov 16, 2016 at 7:23 PM, Michał Jastrzębski  wrote:

Hello,

In light of recent events (kolla-kubernetes becoming thriving project,
kolla-ansible being split) I feel we need to change of core reviewer
election process.

Currently Kolla was single core team. That is no longer the case, as
right now we have 3 distinct core teams (kolla, kolla-ansible and
kolla-kubernetes), although for now with big overlap in terms of
people in them.

For future-proofing, as we already have difference between teams, I
propose following change to core election process:


Core reviewer voting rights are reserved by core team in question.
Which means if someone propose core reviewer to kolla-kubernetes, only
kolla-kubernetes cores has a voting right (not kolla or kolla-ansible
cores).


Makes sense. +1

Martin


Voting will be open until 30 Nov '16 end of day. Reviewers from all
core teams in kolla has voting rights on this policy change.

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



__
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 is available

2016-11-15 Thread Paul Bourke

Seems good so far, thanks Michal / Steve. Cores don't forget to add 
openstack/kolla-ansible to your watched projects in Gerrit :)


I assume we just -2 any Ansible related patches currently open against 
the openstack/kolla project with instructions on how to resubmit.


Also has it been discussed yet if we have a recommended mechanism for 
integration of the two projects, e.g. git submodules, pip or something else?


-Paul

On 15/11/16 17:53, Michał Jastrzębski wrote:

Hello,

I wanted to thank Steve for doing the work, but kolla-ansible is now
open for business:)

Couple of clarifications how it's going to work:

1. Currently Kolla-ansible is copy from kolla repo. We will need to
propose patches to remove docker from it. Also remove ansible bits
from kolla.
2. Any outstanding ansible change should be closed and re-posted to
kolla-ansible repo.
3. Build gates should be dropped from kolla-ansible, deploy gates
should be removed from kolla
4. Core team for kolla-ansible is copy of kolla core team, but teams
are separate and at some point might diverge from each other.
5. Kolla-ansible has it's own launchpad and we should migrate all
relevant bugs and blueprints out there.
6. Kolla-ansibe will use same version number as Kolla (so first tag
will be 4.0.0b1)

Questions?

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] Propose removal of TrivialFix requirement

2016-11-15 Thread Paul Bourke

Thanks for the reminder Andreas, patchset here: 
https://review.openstack.org/397672


On 15/11/16 10:29, Andreas Jaeger wrote:

On 2016-11-15 11:10, Paul Bourke wrote:

Given the window for this vote is now closed and I saw no minus ones
I'll assume this has passed. TrivialFix is now optional.


Is TrivialFix mentioned in the docs and do those need updating for the
changed policy?

Andreas



__
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] Propose removal of TrivialFix requirement

2016-11-15 Thread Paul Bourke

Given the window for this vote is now closed and I saw no minus ones 
I'll assume this has passed. TrivialFix is now optional.


Thanks,
-Paul

On 04/11/16 22:51, Steven Dake (stdake) wrote:

Paul,



I’ll take your request as a request for a vote of the core reviewers.



My vote is +1 in favor of removing the requirement for TrivialFix.



As per our standard policy, the voting window is open for 7 days
beginning November 3^rd , and finishing (in 7 days) on November 11^th .



Regards

-steve





*From: *Paul Bourke <paul.bou...@oracle.com>
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org>
*Date: *Thursday, November 3, 2016 at 6:21 AM
*To: *"OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
*Subject: *[openstack-dev] [kolla] Propose removal of TrivialFix
requirement



Kolleagues,



How do people feel above removing the requirement of having TrivialFix

in commit messages where a bug/bp is not required?



I'm seeing a lot of valid and important commits being held up
because of

this, in my opinion, unnecessary requirement. It also causes friction

for new contributers to the project.



Are there any major benefits we're getting from the use of this tag
that

I'm missing?



Cheers,

-Paul



__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
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] Re: Your draft logo & sneak peek

2016-11-11 Thread Paul Bourke

Reminder Kolla, today is the deadline for feedback on this! Personally I 
think it could use a few tweaks so please don't forget to take a look.


Link: http://tinyurl.com/OSmascot

On 21/10/16 21:58, Steven Dake (stdake) wrote:

Forgot kolla tag in subject.

From: Steven Dake >
Date: Friday, October 21, 2016 at 7:50 PM
To: "OpenStack Development Mailing List (not for usage questions)"
>
Cc: "Jastrzebski, Michal" >
Subject: FW: Your draft logo & sneak peek

Folks,

Inline is the draft logo of the Kolla mascot and logo.  We will be
getting various types of swag at the first PTG related to our mascot.
 The deadline for feedback is November 11th, 2016.  See the email inside
from Heidi for more information on our project mascots.

Super exciting!

Regards
-steve


From: Heidi Joy Tretheway >
Date: Friday, October 21, 2016 at 7:16 PM
To: Steven Dake >
Subject: Your draft logo & sneak peek

Hi Steven,

We're excited to show you the draft version of your project logo,
attached. We want to give you and your team a chance to see the mascot
illustrations before we make them official, so we decided to make
Barcelona the draft target, with final logos ready by the Project Team
Gathering in Atlanta in February.

Our illustrators worked as fast as possible to draft nearly 60 logos,
and we're thrilled to see how they work as a family. Here's a 50-second
"sneak peek" at how they came together: https://youtu.be/JmMTCWyY8Y4

We welcome you to *share this logo with your team and discuss it in
Barcelona*. We're very happy to take feedback on it if we've missed the
mark. The style of the logos is consistent across projects, and we did
our best to incorporate any special requests, such as an element of an
animal that is especially important, or a reference to an old logo.



We ask that you don't start using this logo now since it's a draft.
Here's *what you can expect for the final product*:

  * A horizontal version of the logo, including your mascot, project
name and the words "An OpenStack Community project"
  * A square(ish) version of the logo, including all of the above
  * A mascot-only version of the logo
  * Stickers for all project teams distributed at the PTG
  * One piece of swag that incorporates all project mascots, such as a
deck of playing cards, distributed at the PTG
  * All digital files will be available through the website


We know this is a busy time for you, so to take some of the burden of
coordinating feedback off you, we made a feedback
form*:* http://tinyurl.com/OSmascot  You are also welcome to reach out
to Heidi Joy directly with questions or concerns. Please
provide *feedback by Friday, Nov. 11*, so that we can request revisions
from the illustrators if needed. Or, if this logo looks great, just
reply to this email and you don't need to take any further action.

Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

P.S. Here's an email that you can copy/paste to send to your team
(remember to attach your logo from my email):

Hi team,
I just received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready
for us before the Project Team Gathering in February. Before they make
our logo final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is
due Friday, Nov. 11. To get a sense of how ours stacks up to others,
check out this sneak preview of several dozen draft logos from our
community: https://youtu.be/JmMTCWyY8Y4


photo   
*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769  | Skype: heidi.tretheway

  






__
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] How tied is kolla to matching 1:1 releases of openstack?

2016-11-10 Thread Paul Bourke


Hi Joshua,

Thanks for sharing your workflow, interesting to see.

To answer your question, there is a 1:1 relationship between Kolla and 
OpenStack releases. As Kevin outlined, you may get lucky, currently in 
Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most 
part it works fine. But it's not recommended from an upstream point of view.


Maybe we need more discussion on that as it's something I see popping up 
frequently. We also have a warning in the docs around this, see 
http://docs.openstack.org/developer/kolla/quickstart.html#building-container-images


-Paul

On 09/11/16 17:28, Joshua Harlow wrote:

Hi kolla folks,

As I am (and others at godaddy) are working through integrating kolla
image building into our jenkins pipeline(s),

Currently the pipeline is the following (taking an example of glance),

# Checkout stage
1. Checkout kolla at X tag/branch
2. Checkout glance at Y tag/branch
3. Checkout internal-deploy repo (which has patches for various
projects) at Z tag/branch
4. Checkout requirements repo at Y tag/branch (same Y as #2)

# Test stage
5. Create a virtualenv for glance using constraints from #4
6. Run testr and capture the results of tests and make sure those work
(or fail here)
7. Patch glance using patches from #3
8. Retest glance using same routine as #6 and make sure those work (or
fail here)

# Kolla stage
9. Setup kolla-build.conf with sections for glance (setup to take the
glance tested as a local
directory) and sections for openstack-base (which == the
requirements repo from #4) and
create a template-overrides.j2 with various specific kolla overrides
10. Build images (or fail here)
11. Upload images to artifactory (WIP here)

 Stage next 

So the general question I have is that kolla has tags/branches that
match glance and other openstack releases but I'm not really sure how
tightly bound kolla is to those same tags/branches,

For example right now I am taking kolla at stable/newton but glance and
requirements at stable/liberty,

This seems to work (ya!) but I don't quite know if this is really
recommended, is kolla really tied to the same branches of the other
openstack projects,

With the projects moving to more independent releases is there any
suggested policy, will kolla work with what project releases?

Some range of releases that will work, won't work...?

Ie, kolla stable/newton for example will work with A, B, C, ... branches
of [neutron, glance...]?

Should kolla have a known working list, stating the above in some
location inside of the kolla repo (so people know)?

Thoughts? Comments?

-Josh





__
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] Propose removal of TrivialFix requirement

2016-11-04 Thread Paul Bourke

Hi Jeremy,

> All I ask is that if the Kolla team wants to differentiate itself
> from the review requirements of most OpenStack projects, please make

We have no desire to do this, that's not what is being discussed here. 
On the contrary we're looking to reduce the barrier to entry for 
committers. Also the team is aware that cross project efforts should not 
be nit picked.

-Paul

On 04/11/16 15:25, Jeremy Stanley wrote:

On 2016-11-04 18:18:49 +0530 (+0530), Swapnil Kulkarni wrote:

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.

[...]

All I ask is that if the Kolla team wants to differentiate itself
from the review requirements of most OpenStack projects, please make
sure you have active and attentive liaisons who can update
mass-proposed changes for base infrastructure or other similar
horizonal and cross-project efforts to meet your special reviewing
standards. I cannot personally keep on top of the nuances of every
review team and individually adjust such mass changes myself, so
rely on you to "fix" my patches for me in such situations.

__
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] Propose removal of TrivialFix requirement

2016-11-03 Thread Paul Bourke


Kolleagues,

How do people feel above removing the requirement of having TrivialFix 
in commit messages where a bug/bp is not required?


I'm seeing a lot of valid and important commits being held up because of 
this, in my opinion, unnecessary requirement. It also causes friction 
for new contributers to the project.


Are there any major benefits we're getting from the use of this tag that 
I'm missing?


Cheers,
-Paul

__
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] Deprecation Policies (related to Heka)

2016-09-29 Thread Paul Bourke


Tagging kolla

On 29/09/16 16:22, Michał Jastrzębski wrote:

Agree with Christian, this is our internal wiring. As long as we
provide automated upgrade procedure which will seamlessly migrate from
heka to alternative we want, we should be good without deprecation per
se.

Cheers,
Michal

On 29 September 2016 at 04:36, Christian Berendt
 wrote:

On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:

If you have a different parsing of the deprecation policy, feel free to chime 
in.


Heka is only used as an internal component of Kolla and is not provided as a 
service for the operators. It should be sufficient to replace Heka by something 
else without deprecating it.

Christian.

__
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] [vote][kolla] deprecation for debian distro support

2016-09-20 Thread Paul Bourke

If it's the case Benedict or noone else is interested in continuing 
Debian, I can reverse my vote. Though it seems I'll be outvoted anyway ;)


On 20/09/16 10:21, Swapnil Kulkarni wrote:

On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke <paul.bou...@oracle.com> wrote:

-1 for deprecating Debian.

As I mentioned in https://review.openstack.org/#/c/369183/, Debian support
was added incrementally by Benedikt Trefzer as recently as June. So it's
reasonable to believe there is at least one active user of Debian.

I would like to try get some input from him on whether he's still using it
and would be interested in helping maintain by adding gates etc.

On 19/09/16 18:44, Jeffrey Zhang wrote:


Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For Debian, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use Debian as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate Debian support now.

Please vote:

1. Kolla needs support Debian( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate Debian support

Voting is open for 7 days until September 27st, 2016.



__
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



+1 for #2

I agree with reasoning from Paul, though Debian support was being
added incrementally by Benedikt Trefzer but it has been stopped in
middle and all patches in the queue were abandoned [1]

[1] https://review.openstack.org/#/q/topic:bp/build-debian,n,z

__
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] [vote][kolla] deprecation for debian distro support

2016-09-20 Thread Paul Bourke


-1 for deprecating Debian.

As I mentioned in https://review.openstack.org/#/c/369183/, Debian 
support was added incrementally by Benedikt Trefzer as recently as June. 
So it's reasonable to believe there is at least one active user of Debian.


I would like to try get some input from him on whether he's still using 
it and would be interested in helping maintain by adding gates etc.


On 19/09/16 18:44, Jeffrey Zhang wrote:

Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For Debian, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use Debian as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate Debian support now.

Please vote:

1. Kolla needs support Debian( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate Debian support

Voting is open for 7 days until September 27st, 2016.



__
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] [vote][kolla] deprecation for fedora distro support

2016-09-20 Thread Paul Bourke


+1

On 19/09/16 18:40, Jeffrey Zhang wrote:

Kolla core reviewer team,

Kolla supports multiple Linux distros now, including

* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux

But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.

For fedora, Kolla hasn't any test for it and nobody reports any bug
about it( i.e. nobody use fedora as base distro image). We (kolla
team) also do not have enough resources to support so many Linux
distros. I prefer to deprecate fedora support now.  This is talked in
past but inconclusive[0].

Please vote:

1. Kolla needs support fedora( if so, we need some guys to set up the
gate and fix all the issues ASAP in O cycle)
2. Kolla should deprecate fedora support

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.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

Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

2016-09-15 Thread Paul Bourke

c)   Split the repository shortly after tagging 3.0.0 – creating a 
kolla-ansible deliverable for Ocata.


On 15/09/16 07:12, Steven Dake (stdake) wrote:

Core Reviewers:



The facts:

We have roughly 250 bugs in rc2.  Of those, I suspect over half can just
be closed out as dupes, fixed, wontfix, or the like.

The core reviewer team has had various discussions around splitting the
repository at various times but has not come to a concrete conclusion
via a vote.

Once RC1 is tagged, the stable/newton branch will be created automatically.

All rc2 bug fixes will require bug IDs and backports to stable/newton to
enable the ability to manage the release of rc2 and 3.0.0.

There is an expectation for core reviewers to do the work of backporting
to stable/newton – only our backports team typically does this work –
however during release we really need everyone’s participation.



My understanding of general consensus beliefs:

We believe splitting out the Ansible implementation into a separate
repository will produce a better outcome for both Kolla-Ansible and
Kolla-Kubernetes

We have been unable to achieve consensus on the right timing for a repo
split in the past but generally believe the timing is right at some
point between rc1 and Summit or shortly thereafter, if we are to do the
repo split during Newton or very early Ocata.)



This vote is a multiple choice (one choice please) vote.  Feel free to
discuss before making a decision.



Please vote:

a)   Do not split the repository between rc1 and Summit or shortly
thereafter at all, keeping the Ansible implementation intact in Ocata

b)   Split the repository shortly after tagging RC1 – creating of a
kolla-ansible deliverable for Ocata.

c)   Split the repository shortly after tagging 3.0.0 – creating a
kolla-ansible deliverable for Ocata.



Voting is open for 7 days until September 21^st , 2016. Please do not
abstain on this critical vote.  Remember, no veto vote is available in
roll-call votes.  If a majority can’t be reached on any one choice, but
there is a majority around B & C, (which are the same idea, but
different timing) a second vote will be triggered around when to split
the repository.  The implication there is if you vote for b or c, your
voting for a repository split.  If you vote for A you are voting for no
repository split.  I hate to overload voting in this way.  It is only an
optimization to speed things up as execution may need to happen now, or
can be pushed out a month, or may not be needed at this time.



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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

2016-09-08 Thread Paul Bourke


+1

On 08/09/16 03:59, Steven Dake (stdake) wrote:

Kolla core reviewer team,



It is my pleasure to nominate Christian Berendt for the Kolla core team.



Christian’s output over the last cycle has been fantastic – cracking the
top 10 reviewer list for the full cycle.  His 30 day stats [1] place him
in solid 7^th position, and considering the size of the core review team
we have, this is a great accomplishment.  Christian also has solid 60
day review stats [2] place him in solid 7^th position.  But more
importantly his reviews are of high quality.  He has great IRC
participation as well as having implemented all kinds of bug fixes all
over the code base.  He clearly understands Kolla by the quality of his
reviews.



Consider this nomination a +1 vote from me.



A +1 vote indicates you are in favor of Christian as a candidate, a 0
vote indicates an abstain, and a -1 is a veto.  Voting is open for 7
days until September 15^th , or a unanimous response is reached or a
veto vote occurs.  If a unanimous response is reached or a veto occurs,
voting will close early.



Regards,

-steve



[1] http://stackalytics.com/report/contribution/kolla/30

[2] http://stackalytics.com/report/contribution/kolla/60





__
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] Problem regarding named volume data location

2016-09-02 Thread Paul Bourke


Hi Kolla,

We have been experiencing a long running issue with Kolla that I have 
brought up briefly a few times, but not made too much noise about.


I'm taking the time to write about it in the hopes that a) as a 
community we may be able to solve it, and b) if other operators start 
complaining down the line we'll have discussed it.


The issue is that right now all data is stored using named volumes under 
/var/lib/docker. We have encountered users who are not happy with this. 
As well as issues of scale, even with a large /var/ partition this is 
liable to fill up fast, as (in a default setup) it has to store both 
docker images, glance images, nova instance data, and other potentially 
large files such as logs. It's not typical for operators to be expected 
to store all of this on one partition, and doesn't offer the choice 
expected from a standard (non containerised) deploy.


In our Kilo based solution we were solving this using host bind mounts, 
e.g. -v /var/lib/nova:/var/lib/nova, where the directory on the left 
hand side can be mounted wherever you like. Two major issues with this 
approach are:


1) Kolla tasks have to be refactored in many places to replace 
"nova_data:/var/lib/kolla" with "/var/lib/nova:/var/lib/nova" (easily 
solvable)


2) This appears to be incompatible with the 'drop root' work done, as 
even though /var/lib/nova is created and chowned during the build 
process, it's permissions are replaced with those of root when bind 
mounted from the host.


Other avenues I've explored are seeing the docker volume driver can be 
configured to place data elsewhere (appears not), and symlinking the 
location of the volume to another filesystem as suggested by Michał. 
Symlinking unfortunately also appears to not play well with the Docker 
volume mechanisms.


Do people see this is a potential limitation of Kolla (or maybe 
Docker?), or are we (and our users) being unreasonable in expecting to 
be able to place data on more than one filesystem?


Thanks,
-Paul

__
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] Requirement for bug when reno is present

2016-09-01 Thread Paul Bourke

sdake kindly took the time to explain the release process. Logs are 
here: 
http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2016-09-01.log.html#t2016-09-01T09:06:49


On 30/08/16 20:31, Christian Berendt wrote:

On 30 Aug 2016, at 12:42, Paul Bourke <paul.bou...@oracle.com> wrote:

Do people feel we still want to require a bug-id in the commit message for 
features, when reno notes are present? My understanding is that till now we've 
required people to add bugs for non trivial features in order to track them as 
part of releases. Does/should reno supersede this?


I think it makes sense to keep the bug/blueprint id because some of our 
features are distributed in several reviews and only one of the reviews 
includes the release note. When removing the bug/blueprint ids from the commit 
message when a reno note will be added with one of the reviews it will be 
difficult to track the relations.

Christian.



__
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] Requirement for bug when reno is present

2016-08-30 Thread Paul Bourke


Kolla,

Do people feel we still want to require a bug-id in the commit message 
for features, when reno notes are present? My understanding is that till 
now we've required people to add bugs for non trivial features in order 
to track them as part of releases. Does/should reno supersede this?


-Paul

__
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] Regarding footer blocks

2016-08-29 Thread Paul Bourke


Kolla,

There seems to be a lot of confusion and thrashing on the customisation 
patches regarding the footer blocks.


To help this I have documented the scheme at 
https://review.openstack.org/#/c/361253/2/doc/CONTRIBUTING.rst.


Please review this and respond with questions if it doesn't make sense. 
Currently there are patches open with +2's that are incorrect.


Thanks!
-Paul

__
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 Dave Walker (Daviey on irc)

2016-08-24 Thread Paul Bourke


+1

On 23/08/16 21:45, Steven Dake (stdake) wrote:

Kolla core reviewers,

I am nominating Dave Walker for the Kolla core reviewer team.  His 30
day review stats [1] place him in the middle of the pack for reviewers
and his 60 day stats[2] are about equivalent.  Dave participates heavily
in IRC and has done some good technical work including the Watcher
playbook and container.  He also worked on Sensu, but since we are
unclear if we are choosing Sensu or Tig, that work is on hold.  He will
also be helping us sort out how to execute with PBR going into the
future on our stable and master branches.  Dave has proven to me his
reviews are well thought out and he understands the Kolla Architecture.
 Dave is part time like many Kolla core reviewers and is independent of
any particular affiliation.

Consider this nomination as a +1 from me.

As a reminder, a +1 vote indicates you approve of the candidate, an
abstain vote indicates you don't care or don't know for certain, and a
–1 vote indicates a veto.  If a veto occurs or a unanimous response is
reached prior to our 7 day voting window which concludes on August 30th,
voting will be closed early.

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60


__
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 configuration files owner and permission

2016-08-23 Thread Paul Bourke

In my experience operators prefer a dedicated user (kolla:kolla), though 
I can't see any major problem with your root:kolla approach.


On 23/08/16 14:40, Steven Dake (stdake) wrote:






On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com"  wrote:


Hi S.Dake,


Hello Kollish,

I am working on bp ansible-specific-task-become so I need community opinion 
about Kolla configuration files owner and permissions.

For files in "/var/lib/kolla", it's quite clear that the owner should be 'root' 
as currently.

For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
/etc/kolla is owned by root and all files in it is 660 (writable by a group).


Just to add a bit of clarity, the rationale for this idea is that a group of 
operators could add themselves to the kolla group on all of the nodes and use 
their specific ssh keys to operate OpenStack.  > This is why the group concept 
in unix was invented 50 odd years ago ;)


I just notice that if the directory has 660, so non-root user cannot access 
file in this folder. It seems conflict with group purpose.
Should it be 770 for folders?


Yes 770 for folders 660 for files seeded by the user ids and their ssh keys in 
the host playbook that is in the review queue.  Changes to the host playbook in 
the review queue should come later for this group based model.

The real question is what do operators prefer?  Single user (non-root), 
Multi-user (non-root), or Single user (root).

Regards
-steve



Regards
-steve



Best regards,

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



__
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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

2016-08-19 Thread Paul Bourke

On 19/08/16 00:15, Michał Jastrzębski wrote:

On 18 August 2016 at 18:09, Steven Dake (stdake) wrote:

Kolla Core Review Team:

I am nominating Eduardo for the core reviewer team. His reviews are
fantastic, as I'm sure most of you have seen after looking over the review
queue. His 30 day stats place him at #3 by review count [1] and 60 day
stats [2] at #4 by review count. He is also first to review a significant
amount of the time – which is impressive for someone new to Kolla. He
participates in IRC and he has done some nice code contribution as well [3]
including the big chunk of work on enabling Senlin in Kolla, the dockerfile
customizations work, as well as a few documentation fixes. Eduardo is not
affiliated with any particular company. As a result he is not full time on
Kolla like many of our other core reviewers. The fact that he is part time
and still doing fantastically well at reviewing is a great sign of things to
come :)

Consider this nomination as my +1 vote.

Voting is open for 7 days until August 24th. Joining the core review team
requires a majority of the core review team to approve within a 1 week
period with no veto (-1) votes. If a veto or unanimous decision is reached
prior to August 24th, voting will close early.

Regards
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60
[3]
https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22

Re: [openstack-dev] [kolla][osic] OSIC cluster status

2016-08-16 Thread Paul Bourke


Ok so I got up to speed -

We were having trouble getting instances to get an IP on the VLAN 
provider network via DHCP. DHCP responses were being sent by the neutron 
dhcp agent but seemed to be getting dropped at br-ex.


Turned out the kernel running in the ISO we are using is not new enough 
and the buggy NIC driver (i40e) was present. After upgrading the kernel 
instances are receiving IPs and are ssh-able. (NOTE: the driver issue 
was highlighted in the OSIC docs, we got sidetracked on this though due 
to other issues encountered during bare metal provisioning (hopefully 
most of this is detailed in the review doc, if not we need to get this 
up to date).


Next steps: continue with the rally scenarios. There is a tmux session 
running with a work in progress script to run each scenario we're 
interested in and generate reports. This will allow us to easily 
generate consistent sets of data after each deploy scenario.


-Paul

On 16/08/16 12:57, Paul Bourke wrote:

Kollagues,

Can we get an update from the APAC / US reps?

The last I heard we were having trouble getting guests spawned on an
external network so they could be accessible by Rally. There's been
various people looking at this the past few days but overall unclear
where we are and time is short. If someone could summarise(looking at
Jeffrey / inc0 ;)) what's been happening that will allow us to make a
decision on how to progress.

Cheers,
-Paul

On 05/08/16 17:48, Paul Bourke wrote:

Hi Kolla,

Thought it will be helpful to send a status mail once we hit checkpoints
in the osic cluster work, so people can keep up to speed without having
to trawl IRC.

Reference: https://etherpad.openstack.org/p/kolla-N-midcycle-osic

Work began on the cluster Wed Aug 3rd, item 1) from the etherpad is now
complete. The 131 bare metal nodes have been provisioned with Ubuntu
14.04, networking is configured, and all Kolla prechecks are passing.

The default set of images (--profile default) have been built and pushed
to a registry running on the deployment node, the build taking a very
speedy 5m37.040s.

Cheers,
-Paul

__

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] [kolla][osic] OSIC cluster status

2016-08-16 Thread Paul Bourke


Kollagues,

Can we get an update from the APAC / US reps?

The last I heard we were having trouble getting guests spawned on an 
external network so they could be accessible by Rally. There's been 
various people looking at this the past few days but overall unclear 
where we are and time is short. If someone could summarise(looking at 
Jeffrey / inc0 ;)) what's been happening that will allow us to make a 
decision on how to progress.


Cheers,
-Paul

On 05/08/16 17:48, Paul Bourke wrote:

Hi Kolla,

Thought it will be helpful to send a status mail once we hit checkpoints
in the osic cluster work, so people can keep up to speed without having
to trawl IRC.

Reference: https://etherpad.openstack.org/p/kolla-N-midcycle-osic

Work began on the cluster Wed Aug 3rd, item 1) from the etherpad is now
complete. The 131 bare metal nodes have been provisioned with Ubuntu
14.04, networking is configured, and all Kolla prechecks are passing.

The default set of images (--profile default) have been built and pushed
to a registry running on the deployment node, the build taking a very
speedy 5m37.040s.

Cheers,
-Paul

__
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][osic] OSIC cluster status

2016-08-09 Thread Paul Bourke


Update Aug 9th:

We are on scenario two: 3 control, 20 storage, 100 compute with Ceph. 
Notes are now being collected in 
https://review.openstack.org/#/c/352101/ along with tempest/rally results.


-Paul

On 05/08/16 17:48, Paul Bourke wrote:

Hi Kolla,

Thought it will be helpful to send a status mail once we hit checkpoints
in the osic cluster work, so people can keep up to speed without having
to trawl IRC.

Reference: https://etherpad.openstack.org/p/kolla-N-midcycle-osic

Work began on the cluster Wed Aug 3rd, item 1) from the etherpad is now
complete. The 131 bare metal nodes have been provisioned with Ubuntu
14.04, networking is configured, and all Kolla prechecks are passing.

The default set of images (--profile default) have been built and pushed
to a registry running on the deployment node, the build taking a very
speedy 5m37.040s.

Cheers,
-Paul

__
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] Needing volunteers for Geography Coordinators for making use of OSIC cluster

2016-08-08 Thread Paul Bourke

I can do this for EMEA

-Paul

On 05/08/16 17:11, Steven Dake (stdake) wrote:

Typo is subject tag – please see inside :)

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
Date: Friday, August 5, 2016 at 6:52 AM
To: "OpenStack Development Mailing List (not for usage questions)"
>
Subject: [openstack-dev] [kollla] Needing volunteers for Geography
Coordinators for making use of OSIC cluster

Hey folks,

The kind folks at OSIC have granted the Kolla team access to 132
nodes of super high powered gear for scale testing Kolla.  The
objectives are 3 fold:

 1. Determine if Kolla can scale to 132 nodes for a variety of test
cases – if not fix bugs around those problems
 2. If scalable to 132 nodes, record benchmark data around our
various test scenarios as outlined in the etherpad
 3. Produce documentation in our repository at conclusion of OSIC
scale testing indicating the results we found

The geography coordinators are responsible for coordinating various
testing going on within their respective geography to coordinate the
activities taking place on the loaned OSIC gear so we can
"follow-the-sun" and make the most use of the gear while we have it.
  The geo coordinators are also responsible for ensuring all bugs
related to problems found during osic scale testing are tagged with
"osic" in launchpad.

We need a geo coordinator for APAC, EMEA, and US.  First individual
to respond on list gets the job (per geo – need 3 volunteers)

We have the gear for 4 weeks.  We are making use of the first 3
weeks to do scale testing of existing Kolla and the last week to
test / validate / debug Sean's bifrost automated bare metal
deployment work at scale.

The current state is the hardware is undergoing manual bare metal
deployment at present – closing in on this task being completed
hopefully by end of day (Friday Aug 5th, 2016).

For more information, please reference the Etherpad here:
https://etherpad.openstack.org/p/kolla-N-midcycle-osic

TIA to volunteers.

Cheers,
-steak

__
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][osic] OSIC cluster status

2016-08-05 Thread Paul Bourke


Hi Kolla,

Thought it will be helpful to send a status mail once we hit checkpoints 
in the osic cluster work, so people can keep up to speed without having 
to trawl IRC.


Reference: https://etherpad.openstack.org/p/kolla-N-midcycle-osic

Work began on the cluster Wed Aug 3rd, item 1) from the etherpad is now 
complete. The 131 bare metal nodes have been provisioned with Ubuntu 
14.04, networking is configured, and all Kolla prechecks are passing.


The default set of images (--profile default) have been built and pushed 
to a registry running on the deployment node, the build taking a very 
speedy 5m37.040s.


Cheers,
-Paul

__
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][osic] Accessing the osic VPN

2016-08-04 Thread Paul Bourke

For those starting work on the OSIC cluster, I was having some trouble 
installing the F5 VPN browser plugin, not to mention it's no good if 
wanting to access the cluster remotely.


In the spirit of Kolla here's a Dockerfile I knocked up to run the VPN 
client in a container: https://github.com/brk3/docker-f5fpc


Hope it helps,
-Paul

__
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] Why base image always be built each time build a specific image.

2016-08-02 Thread Paul Bourke


Zhijiang,

You will see lines relating to the base image each time you build, 
however, they should be cached so will add almost no additional time to 
the build.


-Paul

On 21/07/16 09:48, hu.zhiji...@zte.com.cn wrote:

Hi,

When I use the following command to build keystone image, I saw
base/openstack-base image was built for the first time as the dependances,
which is OK.

kolla-build --registry 127.0.0.1:4000 --push keystone

But right after that, when I was building another image (for example
rabbitmq), I saw base image was built again. Why that happend and is that
necessary? Is there any way to keep the already built images to save
building time?


Thanks,
Zhijiang


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.

__
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] Applying for stable-follows tag

2016-07-18 Thread Paul Bourke

Hi Steve,

+1 to applying. I'll volunteer for the backport team also.

-Paul

On 18/07/16 13:07, Steven Dake (stdake) wrote:

Hey Koalians,

I'd like us to consider applying for the stable follows policy tag.
Full details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is
possible that we may not be able to apply for this tag until Liberty
falls into EOL. Still I personally believe intent matters most, and our
intent has always been for these to be stable low-rate-of-change
no-feature-backport branches. There are some exceptions I think we
would fit under for the Liberty case, so I think it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for
Kolla reviews specifically. These folks would be the only folks that
could ACK patches in the stable branch maintenance queue. Anyone could
continue to submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core
reviewers) or until there is a unanimous vote. If there is not, then we
won't apply. The deadline for this vote is July 25th.

Thanks!
-steve

Re: [openstack-dev] [kolla][nova][infra] Voting gates

2016-07-14 Thread Paul Bourke

>> What version of libvirt/qemu do you have in the image/job you're 
running?


$ dpkg -l | grep -e libvirt -e qemu
ii  libvirt-dev:amd64 1.3.1-1ubuntu10.1~cloud0 
amd64development files for the libvirt library
ii  libvirt0:amd641.3.1-1ubuntu10.1~cloud0 
amd64library for interfacing with different virtualization systems
ii  python-libvirt1.3.1-1ubuntu1~cloud0 
amd64libvirt Python bindings
ii  qemu-block-extra:amd641:2.5+dfsg-5ubuntu10.2~cloud0 
amd64extra block backend modules for qemu-system and qemu-utils
ii  qemu-utils1:2.5+dfsg-5ubuntu10.2~cloud0 
amd64QEMU utilities


Thanks,
-Paul

On 14/07/16 17:34, Paul Bourke wrote:

Hi Matt,

Here is the failure from nova_compute on trying to start an instance:

2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
-] Error starting thread.
2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service Traceback (most recent call last):
2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py",
line 708, in run_service
2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service service.start()
2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py",
line 117, in start
2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.manager.init_host()
2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py",
line 1122, in init_host
2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self.driver.init_host(host=self.host)
2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 467, in init_host
2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service self._parse_migration_flags()
2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 689, in _parse_migration_flags
2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service live_migration_flags, live_config_name)
2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service   File
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 644, in _handle_live_migration_auto_converge
2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service migration_flags &=
~libvirt.VIR_MIGRATE_AUTO_CONVERGE
2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
oslo_service.service AttributeError: 'module' object has no attribute
'VIR_MIGRATE_AUTO_CONVERGE'

The full log can be viewed at
http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704


-Paul

On 14/07/16 17:13, Matt Riedemann wrote:

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278



If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
get these values from libvirt:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633



Could be something patched out of the versions you're using from the
distro maybe?

The actual failure paste/trace would help.



__
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)
Uns

Re: [openstack-dev] [kolla][nova][infra] Voting gates

2016-07-14 Thread Paul Bourke


Hi Matt,

Here is the failure from nova_compute on trying to start an instance:

2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - - 
-] Error starting thread.
2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service Traceback (most recent call last):
2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py", 
line 708, in run_service
2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service service.start()
2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py", 
line 117, in start
2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self.manager.init_host()
2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py", 
line 1122, in init_host
2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self.driver.init_host(host=self.host)
2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 467, in init_host
2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service self._parse_migration_flags()
2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 689, in _parse_migration_flags
2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service live_migration_flags, live_config_name)
2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service   File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", 
line 644, in _handle_live_migration_auto_converge
2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service migration_flags &= 
~libvirt.VIR_MIGRATE_AUTO_CONVERGE
2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR 
oslo_service.service AttributeError: 'module' object has no attribute 
'VIR_MIGRATE_AUTO_CONVERGE'


The full log can be viewed at 
http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704


-Paul

On 14/07/16 17:13, Matt Riedemann wrote:

On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:


We are not making the deploy gates voting at this time, although the
plan is to do so once we stablize the last of the gate issues.  I think
we are just down to one issue now, and that is that ubuntu source fails
with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
bug.  If the nova community has any bones to throw us on how to fix
this, it would be appreciated.  I'd cut and paste the log, but for some
reason C isn't working in my email client at present.



What version of libvirt/qemu do you have in the image/job you're running?

See:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278


If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
get these values from libvirt:

https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633


Could be something patched out of the versions you're using from the
distro maybe?

The actual failure paste/trace would help.



__
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] New specs process - a dicussion

2016-07-12 Thread Paul Bourke


Sounds reasonable +1

On 12/07/16 15:32, Michał Jastrzębski wrote:

Hey guys,

Since our project matured, we decided that we should have a discussion
regarding our spec process.

https://etherpad.openstack.org/p/kolla-N-midcycle-specs

Currently we do specs for most critical things, and they require majority vote.

We want to introduce another way, to enable non-nuclear specs.
To summarize our discussion so far:

1. Specs will require only 2 * +2 by default
2. Specs sit at minimum 2 weeks in gerrit before first +2 arrives, so
other people will have time to look at it
3. Any core can require a rollcall vote - then it becomes rollcall vote
4. If nobody calls for rollcall vote, after 2 weeks spec can be merged
with normal 2 * +2

Thoughts?
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] Stability and reliability of gate jobs

2016-06-15 Thread Paul Bourke

Hi David,

I agree with this completely. Gates continue to be a problem for Kolla,
reasons why have been discussed in the past but at least for me it's not
clear what the key issues are.

I've added this item to agenda for todays IRC meeting (16:00 UTC -
https://wiki.openstack.org/wiki/Meetings/Kolla). It may help if before
hand we can brainstorm a list of the most common problems here beforehand.

To kick things off, rabbitmq seems to cause a disproportionate amount of
issues, and the problems are difficult to diagnose, particularly when
the only way to debug is to summit "DO NOT MERGE" patch sets over and
over. Here's an example of a failed centos binary gate from a simple
patch set I was reviewing this morning:
http://logs.openstack.org/06/329506/1/check/gate-kolla-dsvm-deploy-centos-binary/3486d03/console.html#_2016-06-14_15_36_19_425413

Cheers,
-Paul

On 15/06/16 04:26, David Moreau Simard wrote:

Hi Kolla o/

I'm writing to you because I'm concerned.

In case you didn't already know, the RDO community collaborates with
upstream deployment and installation projects to test it's packaging.

This relationship is beneficial in a lot of ways for both parties, in summary:
- RDO has improved test coverage (because it's otherwise hard to test
different ways of installing, configuring and deploying OpenStack by
ourselves)
- The RDO community works with upstream projects (deployment or core
projects) to fix issues that we find
- In return, the collaborating deployment project can feel more
confident that the RDO packages it consumes have already been tested
using it's platform and should work

To make a long story short, we do this with a project called WeIRDO
[1] which essentially runs gate jobs outside of the gate.

I tried to get Kolla in our testing pipeline during the Mitaka cycle.
I really did.
I contributed the necessary features I needed in Kolla in order to
make this work, like the configurable Yum repositories for example.

However, in the end, I had to put off the initiative because the gate
jobs were very flappy and unreliable.
We cannot afford to have a job that is *expected* to flap in our
testing pipeline, it leads to a lot of wasted time, effort and
resources.

I think there's been a lot of improvements since my last attempt but
to get a sample of data, I looked at ~30 recently merged reviews.
Of 260 total build/deploy jobs, 55 (or over 20%) failed -- and I
didn't account for rechecks, just the last known status of the check
jobs.
I put up the results of those jobs here [2].

In the case that interests me most, CentOS binary jobs, it's 5
failures out of 50 jobs, so 10%. Not as bad but still a concern for
me.

Other deployment projects like Puppet-OpenStack, OpenStack Ansible,
Packstack and TripleO have quite a bit of *voting* integration testing
jobs.
Why are Kolla's jobs non-voting and so unreliable ?

Thanks,

[1]: https://github.com/rdo-infra/weirdo
[2]:
https://docs.google.com/spreadsheets/d/1NYyMIDaUnlOD2wWuioAEOhjeVmZe7Q8_zdFfuLjquG4/edit#gid=0

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

Re: [openstack-dev] [kolla] Request for changing the meeting time to 1600 UTC for all meetings

2016-06-08 Thread Paul Bourke


+1

On 08/06/16 13:54, Swapnil Kulkarni (coolsvap) wrote:

Dear Kollagues,

Some time ago we discussed the requirement of alternating meeting
times for Kolla weekly meeting due to major contributors from
kolla-mesos were not able to attend weekly meeting at UTC 1600 and we
implemented alternate US/APAC meeting times.

With kolla-mesos not active anymore and looking at the current active
contributors, I wish to reinstate the UTC 1600 time for all Kolla
Weekly meetings.

Please let me know your views.



__
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] OSIC cluster accepteed

2016-06-07 Thread Paul Bourke


Michal,

I'd be interested in helping with this. Keep us updated!

-Paul

On 03/06/16 17:58, Michał Jastrzębski wrote:

Hello Kollagues,

Some of you might know that I submitted request for 130 nodes out of
osic cluster for testing Kolla. We just got accepted. Time window will
be 3 weeks between 7/22 and 8/14, so we need to make most of it. I'd
like some volunteers to help me with tests, setup and such. We need to
prepare test scenerios, streamline bare metal deployment and prepare
architectures we want to run through. I would also make use of our
global distribution to keep nodes being utilized 24h.

Nodes we're talking about are pretty powerful 256gigs of ram each, 12
ssd disks in each and 10Gig networking all the way. We will get IPMI
access to it so bare metal provisioning will have to be there too
(good time to test out bifrost right?:))

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] Fwd: Re: Kilo version of Kolla

2016-06-03 Thread Paul Bourke

fyi

 Forwarded Message 
Subject: Re: Kilo version of Kolla
Date: Fri, 3 Jun 2016 16:01:59 +
From: Steven Dake (stdake) <std...@cisco.com>
To: Paul Bourke <paul.bou...@oracle.com>, POLAKU, CHANDRA <cp6...@att.com>
CC: VENKATSUBRAMANIAM, SHRINATH <sv3...@att.com>, 
prabhu...@cognizant.com <prabhu...@cognizant.com>

Thanks Paul for sharing!

Would you mind ccing the mailing list with this response (I'd do it, but
I'm not sure if this link is special internal or not).

On 6/3/16, 2:14 AM, "Paul Bourke" <paul.bou...@oracle.com> wrote:

Hi,

I think Steve summed things up pretty well including the challenges
involved in making Kolla deploy Kilo.

Our latest stable release based on Kilo is available at
http://www.oracle.com/technetwork/server-storage/openstack/linux/downloads
/index.html
and source code is available at
https://oss.oracle.com/git/?p=openstack-kolla.git;a=summary which you're
welcome to check out.

Beyond Kilo support many of our tweaks are related to Oracle provided
configurations such as support for Oracle VM server and using
mysqlcluster rather than galera which may or may not be of interest to
you.

Regards,
-Paul

On 03/06/16 02:14, Steven Dake (stdake) wrote:

Chandra,

The first version of Kolla the community released that actually worked
was 1.0.0 (Liberty).  Prior to that all the work was R prototyping.
  That said, I'd recommend using 1.1.0 if you plan to use Liberty.  Note
1.1.0 can be used to deploy Kilo, but it requires custom work which I
estimate at about 3 weeks for an engineer with 5-8 years of experience
and a thorough understanding of OpenStack configuration.

The hard part is changing the configuration options to work with Kilo as
well as sorting out where to get the repositories (or tarballs) from.
  Most everything should work as is, but there will be some changes.
  Oracle has a Kilo based OpenStack product of Kolla available that has
these customizations.  They didn't share mainly because we didn't call
Kilo our 1.0.0 release and there is no branch for their code to land in.
  Paul (cc) may be willing to share his Kilo customization, or it may be
secret sauce as their product is OpenCore.

Regards
-steve

From: "POLAKU, CHANDRA" <cp6...@att.com <mailto:cp6...@att.com>>
Date: Wednesday, June 1, 2016 at 7:52 AM
To: Steven Dake <std...@cisco.com <mailto:std...@cisco.com>>
Cc: "VENKATSUBRAMANIAM, SHRINATH" <sv3...@att.com
<mailto:sv3...@att.com>>, "prabhu...@cognizant.com
<mailto:prabhu...@cognizant.com>" <prabhu...@cognizant.com
<mailto:prabhu...@cognizant.com>>
Subject: Kilo version of Kolla

Hello Steve,

We want to install kilo version of Kolla in an open stack
environment. I came across this link,

https://github.com/openstack/kolla/blob/master/docs/developer-env.md.
However
it seems to be moved or deleted. Wondering if you can help me in
this regard. Any help will be greatly appreciated.

Thanks & Regards,

Chandra Polaku

Data Fabric Developer

*K**force Inc***

990 Hammond Dr NE #930

Atlanta, GA 30328

P: 404.441.3667

cp6...@att.com <mailto:cp6...@att.com>

TEXTING and DRIVING... It Can Wait.

*Take the pledge* <http://www.itcanwait.com/> today and pass it on.

__
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 Mauricio Lima for core reviewer

2016-05-18 Thread Paul Bourke


+1 thanks for all the work Mauricio

On 17/05/16 20:00, Steven Dake (stdake) wrote:

Hello core reviewers,

I am proposing Mauricio (mlima on irc) for the core review team.  He has
done a fantastic job reviewing appearing in the middle of the pack for
90 days [1] and appearing as #2 in 45 days [2].  His IRC participation
is also fantastic and does a good job on technical work including
implementing Manila from zero experience :) as well as code cleanup all
over the code base and documentation.  Consider my proposal a +1 vote.

I will leave voting open for 1 week until May 24th.  Please vote +1
(approve), or –2 (veto), or abstain.  I will close voting early if there
is a veto vote, or a unanimous vote is reached.

Thanks,
-steve

[1] http://stackalytics.com/report/contribution/kolla/90
[2] http://stackalytics.com/report/contribution/kolla/45


__
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] CentOS binary and source gate failed due to the rabbitmq

2016-05-10 Thread Paul Bourke

I have a debug job open atm to try and investigate this: 
https://review.openstack.org/#/c/300988/


If anyone is handy with strace here is a run with the output:

http://logs.openstack.org/88/300988/6/check/gate-kolla-dsvm-deploy-centos-binary/726c3b1/console.html

On 09/05/16 18:23, Hui Kang wrote:

The ubuntu gate deploy failed too; that is awkward.

http://logs.openstack.org/05/314205/1/check/gate-kolla-dsvm-deploy-ubuntu-source/766ee43/console.html#_2016-05-09_16_58_39_411

- Hui

On Mon, May 9, 2016 at 1:48 AM, Jeffrey Zhang  wrote:

I deploy the Kolla by using centos+source on centos host always.
Never see such kinda of issue. So i can not re-produce this
locally, now.

On Mon, May 9, 2016 at 8:31 AM, Hui Kang  wrote:


Hi, Jeffrey,
I tried deploying centos binary and source on my ubuntu host, which
completed successfully. Looking at the VMs on the failed gate, they
are centos VMs.

I think we need to debug this problem locally by deploying centos
kolla on centos hosts. Is my understanding correct? Thanks.

- Hui

On Sat, May 7, 2016 at 9:54 AM, Jeffrey Zhang 
wrote:

Recently, the centos binary and source gate failed due to the rabbitmq
container
existed. After making some debug. I do not found the root cause.

does anyone has any idea for this?

see this PS gate result[0]
centos binary gate failed[1]
CentOS source gate failed[2]

[0] https://review.openstack.org/313838
[1]

http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-binary/ea293fe/
[2]

http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-source/d4cb127/

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





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



__
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] better solution for the non-ini format configure file

2016-05-05 Thread Paul Bourke

TL;DR keep globals.yml to a minimum, customise configs via
host_vars/group_vars

It seems right now the "best" approach may be to tokenise variables as
required. This is the approach we currently use in Oracle. There are two
other approaches I can think of available to us:

1) The overwrite mechanism as Jeffrey mentioned
2) Make the merge_configs script modular so it can handle more formats
than just ini

The problem with 1) is that it is heavy weight for the Operator who
wants to just customise one or two variables such as WEBROOT. Now they
have to copy and maintain the entire config file.

The problem with 2) is that I feel it's a burden on us to write and
maintain code that can merge many different file formats. It could be
done, though may potentially be outside the scope of the project.

The tokenisation approach is unfortunately against what is described in
"Kolla’s Deployment Philosophy"[0] though the reality may be that this
approach is the most Operator friendly. In regards to concern of
globals.yml growing unmanageable, I feel globals.yml is overused and
should only store the bare minimum. Service specific variables should be
kept within their own role files (e.g. ansible/roles/horizon/defaults),
and then documented which are available for tweaking via top level
host_vars/group_vars. This is standard practice in other Ansible roles
I've come across.

-Paul

[0] http://docs.openstack.org/developer/kolla/deployment-philosophy.html

On 04/05/16 16:28, Mauricio Lima wrote:

I agree with your approach Jeffrey, although this is not ideal, this is
an approach already used in kolla.

2016-05-04 12:01 GMT-03:00 Jeffrey Zhang >:

Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to
the globals.yml file.
Because there is no chance to change the horizon/apache configure
file now.

The root cause is that: Kolla do not support non-ini format
configure file. for the
ini-format file, we use a merge_config module[1] to merge all the
found file. But it
will be not work for configure file for apache, rabbitmq and so on.

I would like to the current merge_config implementation. It is
directly and easy to use.
Not like the puppet, we have to remember the variable name defined
in the module. we have
no chance to add some user-defined variable.

Export the variable to global is very bad and ugly. It will became a
disaster when more
and more variables is exported.

So we should catch up a better solution to handle the configure file.

One solution I have is use overwrite mechanism. for example when
there is a file in
/etc/kolla/config/apache.conf, it will overwrite the templates in
the roles. But this
is still not ideal.

Any body has better solution?

[0] https://review.openstack.org/306928
[1]

http://git.openstack.org/cgit/openstack/kolla/tree/ansible/action_plugins/merge_configs.py

--
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][kubernetes] One repo vs two

2016-05-03 Thread Paul Bourke

Having read through the full thread I'm still in support of separate 
repos. I think the explanations Jeff Peeler and Adam Young have put 
forward summarise my thoughts very well.


One of the main arguments I seem to be hearing for a single repo is Git 
tooling which I don't think is a good one; we should do what's best for 
users and devs, not for tools.


Also as the guys pointed out, multiple repos are the most common pattern 
across OpenStack. I think it will help keep a better separation of 
concerns. Otherwise in my experience you start to get cross 
contamination of the projects, to the point where it becomes extremely 
difficult to pull them apart.


The images, ansible, and k8n need to be separate. The alternative is not 
scalable.


Thanks,
-Paul

On 03/05/16 00:39, Angus Salkeld wrote:

On Mon, May 2, 2016 at 7:07 AM Steven Dake (stdake) > wrote:

Ryan had rightly pointed out that when we made the original proposal
9am morning we had asked folks if they wanted to participate in a
separate repository.

I don't think a separate repository is the correct approach based
upon one off private conversations with folks at summit.  Many
people from that list approached me and indicated they would like to
see the work integrated in one repository as outlined in my vote
proposal email.  The reasons I heard were:

  * Better integration of the community
  * Better integration of the code base
  * Doesn't present an us vs them mentality that one could argue
happened during kolla-mesos
  * A second repository makes k8s a second class citizen deployment
architecture without a voice in the full deployment methodology
  * Two gating methods versus one
  * No going back to a unified repository while preserving git history

I favor of the separate repositories I heard

  * It presents a unified workspace for kubernetes alone
  * Packaging without ansible is simpler as the ansible directory
need not be deleted

There were other complaints but not many pros.  Unfortunately I
failed to communicate these complaints to the core team prior to the
vote, so now is the time for fixing that.

I'll leave it open to the new folks that want to do the work if they
want to work on an offshoot repository and open us up to the
possible problems above.


+1 to the separate repo

I think the separate repo worked very well for us and would encourage
you to replicate that again. Having one repo doing one thing makes the
goal of the repo obvious and makes the api between the images and
deployment clearer (also the stablity of that
api and things like permissions *cough* drop-root).

-Angus


If you are on this list:

  * Ryan Hallisey
  * Britt Houser

  * mark casey

  * Steven Dake (delta-alpha-kilo-echo)

  * Michael Schmidt

  * Marian Schwarz

  * Andrew Battye

  * Kevin Fox (kfox)

  * Sidharth Surana (ssurana)

  *   Michal Rostecki (mrostecki)

  *Swapnil Kulkarni (coolsvap)

  *MD NADEEM (mail2nadeem92)

  *Vikram Hosakote (vhosakot)

  *Jeff Peeler (jpeeler)

  *Martin Andre (mandre)

  *Ian Main (Slower)

  * Hui Kang (huikang)

  * Serguei Bezverkhi (sbezverk)

  * Alex Polvi (polvi)

  * Rob Mason

  * Alicja Kwasniewska

  * sean mooney (sean-k-mooney)

  * Keith Byrne (kbyrne)

  * Zdenek Janda (xdeu)

  * Brandon Jozsa (v1k0d3n)

  * Rajath Agasthya (rajathagasthya)
  * Jinay Vora
  * Hui Kang
  * Davanum Srinivas



Please speak up if you are in favor of a separate repository or a
unified repository.

The core reviewers will still take responsibility for determining if
we proceed on the action of implementing kubernetes in general.

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



__
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] Nit-picking documentation changes

2016-04-12 Thread Paul Bourke

I've said in the past I'm not a fan of nitpicking docs. That said, I 
feel it's important for spelling and grammar to be correct. The 
quickstart guide is the first point of contact for many people to the 
project, and rightly or wrongly it will give an overall impression of 
the quality of the project.


When I review doc changes I try not to nitpick on the process being 
described - e.g. if an otherwise fine patch is already 5 iterations in 
and the example given to configure a service could be done in 3 lines 
less bash, I'll usually comment but still +2. If on the otherhand it is 
rife with typos (which by the way is easily solved with a spellchecker), 
and reads really badly I will flag it.


-Paul

On 11/04/16 19:27, Steven Dake (stdake) wrote:

My proposal was for docs-only patches not code contributions with docs.
Obviously we want a high bar for code contributions.  This is part of the
reason we have the DocImpact flag (for folks that don't feel comfortable
writing documentation because perhaps of ESL, or other reasons).

We already have a way to decouple code from docs with DocImpact.

Regards
-steve

On 4/11/16, 6:17 AM, "Michał Jastrzębski"  wrote:


So one way to approach it is to decouple docs from code, make it 2
reviews. We can -1 code without docs and ask to create separate
patchset depending on one in question with docs. Then we can nitpick
all we want:) new contributor will get his/hers code merged, at least
one patchset, so it will work better on morale, and we'll be able to
keep high bar for QSG and other docs. There is possibility that author
will leave docs patch after code merge, but well, we can take over
docs review.

What do you think guys? I'd really like to keep high quality standard
all the way and don't scare off new commiters at the same time.

Cheers,
Michal

On 11 April 2016 at 03:50, Steven Dake (stdake)  wrote:



On 4/11/16, 1:38 AM, "Gerard Braad"  wrote:


Hi,

On Mon, Apr 11, 2016 at 4:20 PM, Steven Dake (stdake) 
wrote:

On 4/11/16, 12:54 AM, "Gerard Braad"  wrote:
as

at the moment getting an environment up-and-running according to the
quickstart guide is a hit and miss

I don't think deployment is not hit or miss as long as the QSG are
followed to a T :)


Maybe saying "at the moment" was incorrect. As the deployment
according to the QSG has been a few weeks ago. Sorry about this... as
you guys have put a lot of effort into it recently.



I agree we need more clarity in what belongs in the QSG.

This can be a separate discussion (Not intending to hijack this thread).


I am not a core reviewer, but I keep it as-is. I do not see a need for


Even though your not a core reviewer, your comments are valued.  The
reason I addressed core reviewers specifically as they have +2
permissions
and I would like more leniency on new documentation in other files
outside
those listed above (philosophy document, QSG) with a pubic statement of
such.


a lower-bar. Although, documentation is the entry-point into a
community (as user and potential contributor) and therefore it should
be of a high quality. Maybe I would be to provide more suggestions
instead of just indication of 'change this for that'.


The issue I see with our QSG is it has the highest bar for review
passage
of any file in the repository.  Any QSG change typically requires 10 or
more patch sets to make it through the core reviewer gauntlet.  This
discourages people from writing new documentation.  I don't want this to
carry over into other parts of the documentation that are as of yet
unwritten.  I'd like new documentation to be ok with misspellings,
grammar
errors, formatting problems, ESL authors, and that sort of thing.

The QSG should tolerate none of these types of errors at this point - it
must be absolutely perfect (at least in English:) as to not cause
confusion to new operators.

Regards
-steve



regards,


Gerard


__
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



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

1 2 >

1 - 100 of 131 matches

Mail list logo