Re: [openstack-dev] [openstack-ansible] dropping xenial jobs

[Jesse Pretorius]

On 10/10/18, 5:54 AM, "Mohammed Naser"  wrote:

>So I’ve been thinking of dropping the Xenial jobs to reduce our overall 
> impact in terms of gate usage in master because we don’t support it.

I think we can start dropping it given our intended supported platform for 
Stein is Bionic, not Xenial. We'll have to carry Xenial & Bionic for Rocky as 
voting jobs. Anything ported back and found not to work for both can be fixed 
through either another patch to master which is back ported, or a 
re-implementation, as necessary.




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

[Jesse Pretorius]

> From: Andy McCrae 

> Now that Rocky is all but ready it seems like a good time! Since changing 
> roles I've not been able to keep up enough focus on reviews and other 
> obligations - so I think it's time to step aside as a core reviewer.

> I want to say thanks to everybody in the community, I'm really proud to see 
> the work we've done and how the OSA team has grown. I've learned a tonne from 
> all of you - it's definitely been a great experience.

Right from the start of the project, back in Icehouse, your can-do attitude was 
inspiring. This carried through to your leadership of the project as PTL later. 
You are already missed. Thank you for everything you put into it and we wish 
you the best for your next endeavours.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][kolla-ansible][DevStack][Tempest][openstack-ansible] Collaborate towards creating a unified ansible tempest role in openstack-ansible project

[Jesse Pretorius]

>On 8/27/18, 7:33 AM, "Chandan kumar"  wrote:

>I have summarized the problem statement and requirements on this etherpad 
> [3].
>Feel free to add your requirements and questions for the same on the
>etherpad so that we can shape the unified ansible role in a better
>way.

>Links:
>1. 
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133119.html
>2. https://github.com/openstack/openstack-ansible-os_tempest
>3. https://etherpad.openstack.org/p/ansible-tempest-role

Thanks for compiling this Chandan. I've added the really base requirements from 
an OSA standpoint that come to mind and a question that's been hanging in the 
recesses of my mind for a while.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do

[Jesse Pretorius]

> On 8/10/18, 3:20 AM, "Paul Belanger"  wrote:
>
>This is basically what I do with roles i write, allow the user to decide 
> to step
>over specific tasks. For example, I have created nodepool_task_manager 
> variable
>with the following:
>
>
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16
>
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml
>
>Been using it for a few years now, works much better then tags for me.  The
>phases are pre, install, configure, service right now.

Hi folks,

I'm really happy that this conversation is happening. Thanks to Alex for 
raising it!

The task routing pattern is a reasonably good one, and is something which OSA 
is very likely to move towards in the future. Something else which I've always 
liked about the pattern used by the role's Paul has put together is that they 
clearly state the input expectation - for example, the role does not manage apt 
repositories, or implement any apt refreshes. This is the kind of thing that I 
think is going to be important - the role should be clear about what it does, 
clear about the inputs it expects, and the outputs of it. This will mean that 
the internals of the role can change, but those inputs are like an API - if you 
give the role that, it must always output the same result.

I can see it possibly being useful to include things like how to test the 
service in the service role, how to evaluate the health, how to enact an 
upgrade, how to enact a fast-forward upgrade, etc. But a good start initially 
would be to define some standards which inform the development of the roles.

Within OSA, for better or worse, we have a mix of role types - some are 
'utility', built for include_role usage. An example is 
http://git.openstack.org/cgit/openstack/ansible-role-systemd_service - give it 
the right vars, and it lays down the type of system service unit that you asked 
for in a standard way. We also make use of the 
http://git.openstack.org/cgit/openstack/ansible-config_template action plugin 
*everywhere* because it allows us not to be bothers with variables for every 
tunable under the sun - we only need variables for specific things that glue 
services together, or implement 'sensible defaults'.

We then have what I might call 'integration' roles - these are roles like 
http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova which does 
all things nova, and uses include_role to bring in various utility roles. We 
try to follow the idea that a single role operates on a single host, and try to 
avoid orchestration across multiple hosts inside a role, but it's not always 
that simple for it to be cut and dried and I'm starting to think we might want 
to change that, for upgrades especially. Laying down something like keystone or 
nova, with all the options like federation or the nova drivers, is a complex 
thing to do. Putting it all in one role makes the role hard to understand, but 
at least it's obvious where you go to find it.

I guess what I'm trying to get across is that trying to build commonly used 
roles is not going to be a simple process. All projects have very different 
styles, and very different ways of putting a service like nova down. However, 
we should start somewhere - break it down into a set of utility roles we'd like 
to see available, figure out the standards that matter for input/output and 
Ansible version support, figure out the release and branching strategy for 
them, get them done and move to using them and retire any previously 
implemented roles which duplicate their purpose, then target the next set.

I think it would be beneficial to get in a room at the PTG and figure out where 
we start, and agree on some standards. I'd like to see a strong facilitator for 
the session who can ensure that we keep things on topic and productive.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Jesse Pretorius]

>On 7/30/18, 9:19 AM, "jean-phili...@evrard.me"  wrote:
>
>I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
> OpenStack-Ansible.
>The BBC team [1] has been very active recently across the board, but 
> worked heavily in our ops repo, making sure the experience is complete for 
> operators.

I most certainly welcome this. Jonathan (and his team) are insightful and 
provide very valuable operator input and they're always ready to help when they 
can. +2 from me





Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][openstack-ansible]

[Jesse Pretorius]

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

Date: Wednesday, May 9, 2018 at 2:18 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [docs][openstack-ansible]


  *   It is with a super heavy heart I have to say that I need to step down as 
core from the OpenStack-Ansible and Documentation teams – and take a step back 
from the community.

It was fantastic, and even entertaining, working with you! Your value to 
OpenStack-Ansible’s documentation improvement was unparalleled – I thank you 
for your support during that time and after when you did a great job shaking 
things up as the docs PTL. ☺ I wish you the best for your next journey and hope 
it’s filled with more laughter and good times.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

[Jesse Pretorius]

Hi Mike – please see my responses in-line.

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

Date: Thursday, May 3, 2018 at 9:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [openstack-ansible] Implement rotations for 
meetings handling


  *   So my question is... what is the health status of OSA? Is there still a 
core of committed contributors? I only check in on OSA code reviews rarely now, 
but activity seems a lot less than it was.

I’m not sure how to answer this, really. OSA is used by a variety of 
organizations, and contributed to by a number of organizations. The health of 
the project depends on the contributions of those who consume it. A quick 
review of Stackalytics shows that OSA has multiple contributing stakeholders, 
which means that the risk of project failure is managed. See 
http://stackalytics.com/?metric=commits=openstack-ansible / 
http://stackalytics.com/?metric=person-day=openstack-ansible for Rocky 
stats, and you can look back in history using the ‘Release’ drop-down box on 
the left.


  *   Before you answer, imagine that I now work for a moderately large, 
potential consumer of OSA.

OK, you’d be in good company if you check the contributing companies in 
Stackalytics.


  *   Is OSA the future, or have other deployment projects made it less 
relevant?

OSA is one of many deployment projects. Each has their own style. Pick the one 
that suits your needs best.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Proposing Mohammed Naser as core reviewer

[Jesse Pretorius]

On 4/24/18, 4:08 PM, "Jean-Philippe Evrard"  wrote:

>I’d like to propose Mohammed Naser [1] as a core reviewer for 
> OpenStack-Ansible.

A happy +2 from me. (



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

[Jesse Pretorius]

Ah Major, we shall definitely miss your readiness to help, positive attitude 
and deep care for setenforce 1. Oh, and then there're the gifs... so many 
gifs...

While I am inclined to [1], I shall instead wish you well while you [2]. (

[1] https://media.giphy.com/media/1BXa2alBjrCXC/giphy.gif
[2] https://media.giphy.com/media/G6if3AWViiNdC/giphy.gif


On 3/26/18, 2:07 PM, "Major Hayden"  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

As promised, I am stepping down from being an OpenStack-Ansible core 
reviewer since I am unable to meet the obligations of the role with my new job. 
:(

Thanks to everyone who has mentored me along the way and put up with my 
gate job breakages. I have learned an incredible amount about OpenStack, 
Ansible, complex software deployments, and open source communities. I 
appreciate everyone's support as I worked through the creation of the 
ansible-hardening role as well as adding CentOS support for OpenStack-Ansible.

- --
Major Hayden
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAlq4774ACgkQc3BR4MEB
H7E+gA/9HJEDibsQhdy191NbxbhF75wUup3gRDHhGPI6eFqHo/Iz8Q5Kv9Z9CXbo
rkBGMebbGzoKwiLnKbFWr448azMJkj5/bTRLHb1eDQg2S2xaywP2L4e0CU+Gouto
DucmGT6uLg+LKdQByYTB8VAHelub4DoxV2LhwsH+uYgWp6rZ2tB2nEIDTYQihhGx
/WukfG+3zA99RZQjWRHmfnb6djB8sONzGIM8qY4qDUw9Xjp5xguHOU4+lzn4Fq6B
cEpsJnztuEYnEpeTjynu4Dc8g+PX8y8fcObhcj+1D0NkZ1qW7sdX6CA64wuYOqec
S552ej/fR5FPRKLHF3y8rbtNIlK5qfpNPE4UFKuVLjGSTSBz4Kp9cGn2jNCzyw5c
aDQs/wQHIiUECzY+oqU1RHZJf9/Yq1VVw3vio+Dye1IMgkoaNpmX9lTcNw9wb1i7
lac+fm0e438D+c+YZAttmHBCCaVWgKdGxH7BY84FoQaXRcaJ9y3ZoDEx6Rr8poBQ
pK4YjUzVP9La2f/7S1QemX2ficisCbX+MVmAX9G4Yr9U2n98aXVWFMaF4As1H+OS
zm9r9saoAZr6Z8BxjROjoClrg97RN1zkPseUDwMQwlJwF3V33ye3ib1dYWRr7BSm
zAht+Jih/JE6Xtp+5UEF+6TBCYFVtXO8OHzCcac14w9dy1ur900=
=fx64
-END PGP SIGNATURE-

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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/12/17, 8:55 AM, "Thomas Goirand"  wrote:

> Now, there's something which I still am not completely sure. Are you
> willing to push for *samples*, or real configuration files which we can
> actually use? Depending on your answer, the destination location will be
> different, and probably the only thing we need is some logic to disable
> the installation of config files (and then we just do it at the
> packaging level as we've been used to do so far).

Yes, from a project standpoint they will be samples. It is up to the consumer 
of those to determine whether they are usable for production or not. In our 
case we will still be modifying them – we just want them in the package so that 
we do not have to fetch them from git.

> Also, in the packaging process, there's a few tweaks that are necessary
> for the distro integration. A quick example: in the nova package, I've
> set sensible default for [DEFAULT]/pybasedir, [DEFAULT]/bindir,
> [DEFAULT]/state_path. Even if you were shipping a nova.conf in the
> correct location, the Debian package would have to fix these directives.
> I've seen that Ubuntu does something similar also.

‘Sensible defaults’ are subjective to the use-case. As mentioned above, we will 
be modifying the files and I expect that all distributions/deployments have 
adjustments to better suit their use-cases. In this particular case you’re 
mentioning .conf files which are supposed to be generated, not included.

> I still didn't have any reply on my PBR change proposal. Your thoughts?

Your proposal is likely going to end up requiring multiple env vars because 
data_files could be marked for any location – unless you’re wanting some sort 
of env var for each top level file destination? In that case it’s going to get 
messy fast. It sounds like it’d be better to try and implement another file 
type in distutils/setuptools which is recognized as different. Perhaps 
something like ‘config_files’ which could then have its own CLI option to place 
them differently to ‘data_files’.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/10/17, 9:26 PM, "Doug Hellmann"  wrote:

> I still think we should just be looking at these files as sample
> data and not active configuration files when we put them into the sdist
> or wheel.

There is agreement from all distributions bar one on this approach so far, so 
I’d like to dig into this approach more to see if we can find a solution that 
works for everyone.

Thomas, do I understand the problem correctly that if we considered these 
sample files then the complexity for Debian appears to be that it would not 
want the sample config files in, for example, /usr/share/nova but instead in 
/usr/share/nova-common ? Is the use of the –common directory something that’s 
Debian specific, or do any other distributions do it?




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/10/17, 12:08 PM, "Jesse Pretorius" <jesse.pretor...@rackspace.co.uk> 
wrote:

>$ python setup.py install --skip-build --root /tmp/keystone --install-data 
> /

Apologies – I copied the wrong command, it should have been:

$ python setup.py install --root /tmp/keystone --install-data /



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/9/17, 4:08 PM, "Thomas Goirand"  wrote:

>So yeah, you can push files in /usr/share/nova, but then we'll have to
>actually *delete* them in the packaging, because it doesn't fit our use
>case. So in fact, best would be if this could be overridden, for example
>using an environment variable. Something like:

>export OSLO_CONFIG_FILE_DEST=/usr/share/nova-common

>This way, I wouldn't have to manually move/copy/delete/regenerate config
>files by hand in debian/rules.

Using an env var to override behavior does seem like something that could be 
useful. For example if I could use an env var to say that data_files destined 
for etc/nova should go to /etc/nova instead of /usr/etc/nova then that’d be 
good. However it appears that’s possible without an env var as noted in 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123346.html

In the Debian case it seems that the need would be to do some sort of search 
and replace, because the suffix changes. How would you implement an env var in 
such a way that you can map a path in setup.cfg to a replacement path set in an 
env var?

Regardless, given that this is not functionality currently available for 
setuptools, distutils or pbr it would seem that this functionality (or another 
applicable workaround) would have to be carried by Debian packaging until such 
time that such a facility exists in the python tooling.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 9/29/17, 7:18 AM, "Thomas Bechtold"  wrote:

>This will still install the files into usr/etc :

>$ python setup.py install --skip-build --root /tmp/sahara-install > 
> /dev/null
>$ ls /tmp/sahara-install/usr/
>bin  etc  lib

>It's not nice but packagers can workaround that.

I gave this a try this morning:

$ python setup.py install --skip-build --root /tmp/keystone --install-data /
$ find /tmp/keystone -maxdepth 6 -type d
/tmp/keystone
/tmp/keystone/usr
/tmp/keystone/usr/local
/tmp/keystone/usr/local/bin
/tmp/keystone/usr/local/lib
/tmp/keystone/usr/local/lib/python2.7
/tmp/keystone/usr/local/lib/python2.7/dist-packages
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone-12.0.0.0rc2.dev101.egg-info
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone
/tmp/keystone/etc
/tmp/keystone/etc/keystone

Is this perhaps useful?



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

> From: James Page 

> 1) +1 for a consistent approach across projects - /usr/share/ sounds 
> like a sensible location - avoiding any complexity with managing changes made 
> by users in /etc/ for deploy from source use-cases, and allowing 
> packagers to know where to expect reference/sample config files to appear 
> during the package build-out/install process.

We have agreement from packagers for Ubuntu [1] and RDO [2] to include the 
files in the relative path /share. This seems to be the least offensive. 
OpenStack-Ansible supports the inclusion of the files, regardless of path [3].

There was acceptance of the /etc relative path from a SuSE packager [4]. Thomas 
Bechtold – could you comment on whether the relative path of /share is also 
good for SuSE packaging?

There has been an objection from the OpenStack package maintainer for Debian, 
but that objection has been to the use of the relative path of /etc. Thomas 
Goirand, could you please indicate whether you support the use of the relative 
path of /share given the currently available functionality in setuptools and 
pbr?

> 2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a 
> few places where oslo-config-generator or oslo-policy-generator is used to 
> generate sample configuration files as part of the package build; I might 
> have missed it in my read through of this thread but it would be awesome if 
> those could be integrated as part of this process as well as the originating 
> project would then be able to provide some level for assurance to the content 
> of generated files in downstream distributions.

As mentioned in [4] these should be auto-generated. Some projects do this and 
submit samples into the repo from time to time, others have just left a stub 
with an explanation of how to generate it.

> I'd also be +1 on a packaging SIG; I don't think it will ever be a high 
> overhead SIG but it sounds like there are common challenges for deployment 
> projects and distributors which would benefit from shared focus.

I’m not in a position to set this up or run it, but would be happy to 
participate if someone is able to take ownership of it.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123235.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123294.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123035.html
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122843.html
[5] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122825.html



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/3/17, 3:01 PM, "Doug Hellmann"  wrote:

>> Given that this topic has gone through several cycles of discussion and has 
>> never gone anywhere, does it perhaps merit definition as a project interface 
>> so that we can define the problem this is trying to solve and set a standard 
>> formally once and for all?

>Maybe a couple of the various packaging projects can agree and just
>set a de facto rule (and document it). That worked out OK for us
>with the doc reorganization when we updated the docs.o.o site
>templates.

I’m happy to facilitate that. Is there some sort of place where such standards 
are recorded? Ie Where do I submit a review to and is there an example to 
reference for the sort of information that should be in it?



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 10/2/17, 1:45 PM, "Doug Hellmann"  wrote:

>etc implies they should be edited, though, and we're trying to move away
>from that at least for the paste.ini files in most projects. So we may
>need to decide on a case-by-case basis, unless we declare all of these
>files as "sample" files that should be copied into the right place
>before being edited.

For ‘sample’ files, where would be an appropriate placement? The relative path 
‘share’ instead of ‘etc’?

The placement of the files really should be focused more on the problem it’s 
trying to solve.

The use-cases exposed so far are:

1. For OpenStack-Ansible or any other deployment project deploying from source, 
the only problem we’d like to have any configuration files for services 
included in a compiled wheel. The path is irrelevant to us as we can move the 
files to where they need to be, but we would like to cut out a bunch of code 
which we now use to fetch these files from the git source, or alternatively the 
vendored copies of the files we carry.
2. Packagers I’ve had discussion with also have implementations which fetch 
these files from the git source. For them the sentiment appears to be largely 
the same – consistency of placement for the files is important.
3. For anyone installing the software via a compiled wheel for whatever reason, 
things get a little muddy – some want the files in the default locations that 
the software looks for it so that after installation ‘it just works’.
4. Some packagers want the files to be placed in the system root path 
appropriate for the file when it is installed via a package.

To me the third use-case is a nice-to-have, given that if the files are 
consistently placed then it can be worked with and anyone doing that already 
has something to cover that need.

To me the fourth use-case is out of scope. It needs resolving via setuptools 
and/or pep 491 before that can move forward.

Given that this topic has gone through several cycles of discussion and has 
never gone anywhere, does it perhaps merit definition as a project interface so 
that we can define the problem this is trying to solve and set a standard 
formally once and for all?



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 9/29/17, 6:26 PM, "Jeremy Stanley"  wrote:

On 2017-09-29 18:39:18 +0200 (+0200), Thomas Bechtold wrote:
> There is /etc [1]
[...]

>Not really, no, because the system-context data_files path has to be
>relative to /usr or /usr/local unless we want to have modules going
>into /lib and entrypoints in /bin now.

Right – that’s exactly why I this it would be better to stick with a relative 
path, but make the implementation consistent.

So, given a relative path being used – which is better: etc or share?

To me, etc seems more intuitive given that these are configuration files. Using 
etc benefits those building and consuming wheels by being an intuitive 
placement (putting the files into the etc directory of the venv). Each 
packaging system has their own conventions so I do not think we’re going to be 
able to come to a common consensus that pleases everyone, so I’d like to rather 
focus on attaining a consistent path across services so that packagers can 
adapt their scripts appropriately to cater for their individual quirks, while 
everyone using wheels gets the benefit of the files being a part of the package.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 9/29/17, 7:18 AM, "Thomas Bechtold"  wrote:

This will still install the files into usr/etc :
It's not nice but packagers can workaround that.

Yes, that is true. Is there a ‘better’ location to have them? I noticed that 
Sahara was placing the files into share, resulting in them being installed into 
/usr/share – is that better?

For OSA as a project it’s not really a problem where it goes, just that the 
files are there and ideally in a consistent place.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

On 9/28/17, 5:11 PM, "Doug Hellmann"  wrote:

> In the past we had trouble checking those files into git and gating
> against the results being "up to date" or not changing in any way
> because configuration options that end up in the file are defined in
> libraries used by the services. So as long as the implementation you're
> considering does not check configuration files into git, but generates
> them and then inserts them into the package, it should be fine.

I’m guessing that the aut-generated files you’re referring to are the .conf 
files? For the most part, those are being left out of my proposed patches 
unless the project team specifically requests their inclusion. My patches are 
focused on the far more static files - policy.json if it exists (yes, the 
policy-in-code will remove those in time), api-paste, rootwrap.conf and the 
rootwrap.d contents. As far as I know none of these are auto-generated. If they 
are, I’m all ears to learn how!




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

There’s some history around this discussion [1], but times have changed and the 
purpose of the patches I’m submitting is slightly different [2] as far as I can 
see – it’s a little more focused and less intrusive.

The projects which deploy OpenStack from source or using python wheels 
currently have to either carry templates for api-paste, policy and rootwrap 
files or need to source them from git during deployment. This results in some 
rather complex mechanisms which could be radically simplified by simply 
ensuring that all the same files are included in the built wheel. Distribution 
packagers typically also have mechanisms in place to fetch the files from the 
source repo when building the packages – including the files through pbr’s 
data_files for packagers may or may not be beneficial, depending on how the 
packagers do their build processes.

In neutron [3], glance [4], designate [5] and sahara [6] the use of the 
data_files option in the files section of setup.cfg is established and has been 
that way for some time. However, there have been issues in the past 
implementing something similar – for example in keystone there has been a bit 
of a yoyo situation where a patch was submitted, then reverted.

I’ve been proposing patches [7] to try to make the implementation across 
projects consistent and projects have, for the most part, been happy to go 
ahead and merge them. However concern has been raised that we may end up going 
through another yo-yo experience and therefore I’ve been asked to raise this on 
the ML.

Do any packagers or deployment projects have issues with this implementation? 
If there are any issues, what’re your suggestions to resolve them?

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097123.html
[2] https://launchpad.net/bugs/1718356
[3] 
https://github.com/openstack/neutron/blob/d3c393ff6b5fbd0bdaabc8ba678d755ebfba08f7/setup.cfg#L24-L39
[4] 
https://github.com/openstack/glance/blob/02cd5cba70a8465a951cb813a573d390887174b7/setup.cfg#L20-L21
[5] 
https://github.com/openstack/designate/blob/25eb143db04554d65efe2e5d60ad3afa6b51d73a/setup.cfg#L30-L37
[6] 
https://github.com/openstack/sahara/blob/cff43d6f1eee5c68af16c6f655f4d019669224d9/setup.cfg#L28-L29
[7] 
https://review.openstack.org/#/q/topic:bug/1718356+(status:open+OR+status:merged)



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Ansible] Proposing Markos Chandras for osa-core

[Jesse Pretorius]

In case the meeting vote is lost somehow, you still have my +1 – looking 
forward to working more with Markos!

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

Date: Tuesday, July 18, 2017 at 10:23 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [OpenStack-Ansible] Proposing Markos Chandras for 
osa-core

Following on from last week's meeting I'd like to propose Markos (hwoarang) for 
OSA core.

Markos has done a lot of good reviews and commits over an extended period of 
time, and has shown interest in the project as a whole. (Not to mention the 
addition of SUSE support)

We already have quite a few +1's from the meeting itself, but opening up to 
everybody who wasn't available at the meeting!

Thanks,
Andy






Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] New setuptools release, and the world is broken

[Jesse Pretorius]

On 7/14/17, 5:18 PM, "Jeremy Stanley"  wrote:

>Is there a mechanism to leverage this in tox or when invoking
>virtualenv? We don't run get-pip.py in most jobs because our images
>have pip/setuptools preinstalled to get around bootstrapping issues,
>though I suppose that could with some effort be moved into job
>runtime as a (very early) builder macro. Using constraints to
>control these during image generation doesn't make a whole lot of
>sense though as images are only rebuilt once a day and so tracking
>these in the constraints list won't be self-testing in that regard
>anyway.

Fair enough, although that’s what we have today so I don’t see it as worse. In 
fact, I think it’s an improvement because our constraints can be updated when 
we choose to (through the normal requirements management process) rather than 
whenever the new package releases.

I think it may make sense to do a pre-tox macro which preps 
pip/setuptools/wheel using get-pip.py, then places the relevant wheels into the 
virtualenv_support directory [1] so that tox uses them when building 
virtualenvs. Another option could be to use a configuration file [2] to specify 
a directory to find the right wheels in.

[1] https://virtualenv.pypa.io/en/stable/userguide/#the-extra-search-dir-option
[2] https://virtualenv.pypa.io/en/stable/reference/#configuration-file



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] New setuptools release, and the world is broken

[Jesse Pretorius]

On 7/14/17, 4:54 PM, "Doug Hellmann"  wrote:

> I wonder if we could convince the PyPA folks to allow get-pip.py
>to take a version argument, so we could specify which version we want in
>our jobs. We would still need a way to manage that version number, but
>modifying get-pip.py would solve the bootstrapping issue.

It has been capable of this for quite some time. You can provide both 
requirements
And constraints.

python /opt/get-pip.py pip==9.0.1 setuptools==33.1.1 wheel==0.29.0

Or, far better, is to use constraints because it’ll ensure that any dependent 
packages are also the right versions.

python /opt/get-pip.py pip setuptools wheel –constraint 
http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt






Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] New setuptools release, and the world is broken

[Jesse Pretorius]

On 7/14/17, 4:17 PM, "Jeremy Stanley"  wrote:

>Chicken and egg. Once you get to the point where pip can enforce
>   constraints, you already have a version of setuptools installed. And
>as evidenced by, for example, this current bug you would just end up
>breaking on the downgrade trying to replace your existing broken
>version with whatever version is requested. Also you would need a
>separate phase to upgrade/downgrade setuptools separate from other
>packages using it.

Which is why I think we should do it right at the point where we put pip there. 
This can be done with the get-pip script which only requires python to be there.

I did a little spelunking to try and figure out where it is we put pip onto the 
nodepool nodes. It appears that d-i-b for Ubuntu Xenial uses packages to put it 
there, but that doesn’t explain how the latest version got there. Does anyone 
have any insight into where exactly the latest version is installed?



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] New setuptools release, and the world is broken

[Jesse Pretorius]

FYI if you see the following error in your job logs, you have the new 
setuptools to thank:

AttributeError: Distribution instance has no attribute 'install_requires'

I’ve registered https://github.com/pypa/setuptools/issues/1086 to track the 
issue, and very quickly got a response and there’s a PR up to resolve it.

In our case we saw this when downgrading setuptools to our known, good working 
version.

I’d like to suggest that we include setuptools, pip, wheel and other core 
packages in the upper constraints management process and that all the images 
built for jobs make use of it. The number of times that a new release of 
pip/setuptools has completely ground development to a halt for a day, sometimes 
more, is a little too frequent for my liking.

IIRC we’d need to just change the u-c generation output from ‘pip freeze’ to 
‘pip freeze –all’ for the output to include the versions for pip, setuptools 
and wheel. Then, with that spec, pip can be installed using u-c like so:

CURL_CMD="curl --silent --show-error --retry 5"
OUTPUT_FILE="get-pip.py"
${CURL_CMD} https://bootstrap.pypa.io/get-pip.py > ${OUTPUT_FILE} ||\
${CURL_CMD} 
https://raw.githubusercontent.com/pypa/get-pip/master/get-pip.py > 
${OUTPUT_FILE}

python ${OUTPUT_FILE} pip setuptools wheel -c upper-constraints.txt

That will ensure a consistent, known good version set is installed and will 
also cater for the situation where the primary URL for get-pip.py is down (as 
happens sometimes).



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][openstack-ansible] Moving on

[Jesse Pretorius]

This is most unfortunate. :(

I do wish you the absolute best with whatever lies ahead. I have found your 
skills, patience and willingness to debate and learn most inspirational.

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

Date: Friday, May 19, 2017 at 4:55 AM
To: OpenStack 
Subject: [openstack-dev] [glance][openstack-ansible] Moving on

It is clear to me now that I won't be able to work on OpenStack as a part of my 
next day job, wherever that ends up being. As such, I’ll no longer be able to 
invest the time and energy required to maintain my involvement in the 
community. It's time to resign my role as a core reviewer, effective 
immediately.
Thanks for all the fish.
--
SteveL


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Rename openstack-ansible-security role?

[Jesse Pretorius]

On 5/17/17, 6:25 PM, "Major Hayden"  wrote:

  1) Should the openstack-ansible-security role be
 renamed to alleviate confusion?

Sure, I’ve long thought that the name is misleading.

  2) If it should be renamed, what's your suggestion?

My uninspired suggestion is to make it something like ‘ansible-host-security’. 
A quick google search for that only shows the openstack-ansible-security role 
anyway. (



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][all] etcd tarballs for CI use

[Jesse Pretorius]

On 5/15/17, 11:20 PM, "Davanum Srinivas"  wrote:

> At this moment, though Fedora has 3.1.7 [1], Xenial is way too old, So
> we will need to pull down tar balls from either [2] or [3]. proposing
> backports is a possibility, but then we need some flexibility if we
> end up picking up some specific version (say 3.0.17 vs 3.1.7). So a
> download location would be good to have so we can request infra to
> push versions we can experiment with.

Hi Dims,

I can’t help but ask - how old is too old? By what measure are we saying
something is too old?

I think we need to be careful with what we do here and ensure that the
Distribution partners we have are on board with the criteria and whether
They’re ready to include more recent package versions in their extra
Archives (eg: RDO / UCA).

As developers we want the most recent things because reasons… but
Distributions and Operators are then stuck with raised complexity in
their release and quality management processes.




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

[Jesse Pretorius]

On 4/4/17, 12:06 AM, "Clark Boylan"  wrote:

> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).

An approach that could be taken here is to bake the repo config (and install 
packages from that repo) for the UCA version that’s the earliest version we 
support for that OS. For example – the earliest version that supports Xenial is 
Newton, so pre-configure and install packages into the image from UCA 
Xenial/Newton. Then in any jobs which care about which version of UCA is used 
the repo config can be changed and the packages updated. This potentially saves 
a little gate time.


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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Adding a scenario for shade's functional tests

[Jesse Pretorius]

On 4/4/17, 1:39 PM, "Monty Taylor"  wrote:

>I'd love to make a gate job that:
>   - Deploys a cloud with openstack-ansible
>   - Runs shade's functional tests against that cloud

Fantastic. Let’s see how we can help.

>   Which makes me think it just needs to be an additional scenario perhaps?

Maybe. Our scenario’s, right now, are focused more around what 
Infrastructure/OpenStack services are deployed. If you want/need a larger set 
than our default ‘aio’ scenario, then yes a different scenario would need to be 
setup. The alternative, of course, is to override the confd_overrides var in 
your test setup with an ‘aio’ scenario of your own – but I think it’d be nice 
to rather bake whatever you need in so that we can help maintain it.
https://github.com/openstack/openstack-ansible/blob/master/tests/bootstrap-aio.yml#L28-L46

>As I started to poke, I need to figure out the best way to accomplish
>something. Namely, shade's functional tests expect a clouds.yaml that
>defines two entires - one admin and one non-admin.

>OSA already creates a clouds.yaml with admin creds, so that's done. And
>there is already tempest setup that creates a demo user, so that's done
>too. Here's where I could use some advice:

>- What's the best way to plumb through an option to also write an entry
>to clouds.yaml for the demo user? I'm thinking a boolean in
>openstack-ansible-openstack_openrc like
>"openrc_clouds_yml_add_demo_user" that can be wrapped around a second
>entry in clouds.yaml.j2?

Well, an option could be that an arbitrary dict could be looped through to add 
any content for additional entries in clouds.yml – we could then have the 
tempest demo account settings pulled out of the tempest role (they’re hard 
coded there now, and probably should not be), then have the role loop through 
the same dict if it’s defined. The dict can then be defined in the utility_all 
group vars or are perhaps best only set in the AIO prep config (so that they 
don’t end up being used in production deployments).

>- Can we create the demo user and not run tempest? It's in the
>os_tempest role at the moment. Should I split out the user creation bits
>into a "test_setup" role that tempest depends on - and then also make a
>shade_test role that also depends on the test_setup role?

Well, creating a user and a different clouds.yaml file could also be done with 
a few tasks in a playbook. Unless there’s an opportunity for re-use I don’t 
really see the point of creating a role for it.

>- If we do a test_setup role, should that maybe just write a whole
>additional clouds.yaml out that has the admin and the demo user so that
>we don't have to put conditionals in places that also get used for prod
>deploys?

The existing tempest role creation of a static set of demo accounts is terrible 
anyway. We should ideally make them adaptable and ensure that the passwords are 
randomized.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [deployment][snaps][ansible][puppet][charms] OpenStack snaps delivery strategy

[Jesse Pretorius]

Adding the [deployment] tag as the catch-all for deployment projects as I think 
they’d be interested.

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

Date: Thursday, March 2, 2017 at 3:31 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [snaps][ansible][puppet][charms] OpenStack snaps 
delivery strategy

Hi All,

I'm working to get a strategy in place for delivery of OpenStack snaps. Below 
I've outlined an initial strategy, and I'd like to get your input.

I'm particularly interested in input from snap folks of course, but also from 
projects that install OpenStack and may want to be involved in snap CI/gating 
(ie. Ansible, Puppet, Charms, etc).


First a quick background of snaps, tracks, channels, and versions (skip to 
"Strategy" if you're already familiar with these concepts):

Snaps
-
If you're not familiar with OpenStack snaps, see James Pages' intro at: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109743.html
And if you'd like to just tip your toes in the water quickly, you can give the 
openstackclients snap a try: 
https://javacruft.wordpress.com/2017/02/03/snap-install-openstackclients/

Tracks
-
Snaps have the concept of tracks, which allow for publishing different series 
of software (ie. newton, ocata, pike would be separate tracks). In each track, 
you can publish a snap to any of the 4 channels based on how stable it is.

Channels
-
Snaps can be published to 4 different channels:
* edge:  for your most recent changes, probably untested
* beta:  used to provide preview releases of tested changes
* candidate:  used to vet uploads that should require no further code changes 
before moving to stable
* stable:  what most users will consume, stable and tested

Version
--
Snaps include metadata where the software version can be specified.

For more details on tracks, channels, and versions, see: 
https://snapcraft.io/docs/reference/channels


Strategy
---
Ok on to the strategy. Below I've outlined a proposed strategy for delivering 
snaps to the 4 different channels based on the level of testing they've 
undergone. Long-term we'd like to see the majority of this process automated, 
therefore the strategy I describe here is the end goal (and hence my overuse of 
"auto-").

Track Strategy

pike:  auto-publish to pike channels according to channel strategy
ocata -> latest [0]:  auto-publish to latest (ocata) channels according to 
channel strategy
newton: auto-publish to newton channels according to channel strategy
mitaka: auto-publish to mitaka channels according to channel strategy
[0] The 'latest' track is the default for users when they install a snap. 
Therefore the 'latest' track will always include the latest stable release.

New repo in support of channel strategy
-
snap-releases:
In order to enable channel testing, and publishing, of a known good set of 
snaps across OpenStack projects, I'd like to create a new 'snap-releases' repo. 
This would be a simple repo of yaml mappings, similar to [1], that would 
contain the current tracks/channels/versions for candidate and stable channels. 
For example, the snap-releases/ocata/cinder file may have 'candidate: 9.1.1' 
and 'stable: 9.0.0'.
[1] https://github.com/openstack/releases/tree/master/deliverables

Channel Strategy
-
edge: each snap is auto-published to edge on every upstream commit
1) edge stage is triggered by each new upstream commit
2) version field is auto-populated with short git hash or pbr version
3) auto-publish snap to edge channel
notes:
* unit tests will have already passed on upstream gate by this time and prior 
to all future stages (and snaps don't apply any new patches)
* voting projects may want to vote more often than beta releases but voting on 
every edge update seems overboard; they could also vote on individual snap repo 
changes but they may be seldom.

beta: each snap is auto-published to beta on every upstream stable point 
release or development milestone
1) beta stage is triggered by new upstream release tar, e.g. cinder newton 
watches for 9.x.x
2) version field auto-populated with release version, e.g. for cinder, 
version=9.1.1
3) auto-open launchpad bug for SRU (stable release update)
4) auto-publish snap to beta channel
5) auto-propose snap-releases gerrit review to change candidate version; for 
example:
- candidate: 9.0.0, stable: 9.0.0
+ candidate: 9.1.1, stable: 9.0.0
6) voting projects smoke test, and vote, with this snap from beta, and all 
other snaps from candidate
7) SRU bug auto-updated with results of review
8) human interaction required if tests fail and may require fixed snap to be 
re-published

candidate: each snap is auto-published to candidate after successful testing 

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

[Jesse Pretorius]

On 2/28/17, 12:52 AM, "Michał Jastrzębski"  wrote:

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

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



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jesse Pretorius]

Comments in-line

On 2/27/17, 4:02 PM, "Steven Hardy"  wrote:

If I go ahead and do this is "deployment" a sufficiently project-neutral
term to proceed with?

I think so.

I'd suggest we start with an informal WG, which it seems just requires an
update to the wiki, e.g no need for any formal project team at this point?

A WG is what I had in mind.

Likewise I know some folks have expressed an interest in an IRC channel
(openstack-deployment?), I'm happy to start with the ML but open to IRC
also if someone is willing to set up the channel.

Personally I think we should use #openstack-dev instead. It’s the traditional 
place for cross-project communication, is less exclusive and much like this 
mailing list brings more people into the conversation.

Perhaps we can start by using the tag "deployment" in all cross-project ML
traffic, then potentially discuss IRC (or even regular meetings) if it
becomes apparrent these would add value beyond ML discussion?

Sure, I don’t have any strong feelings about the tag. The tag [deployment] 
makes sense to me.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Jesse Pretorius]

Thank you for your valuable input, drive and commitment to make OSA better. You 
are already missed! I wish you the very best in your next career evolution.

From: "Truman, Travis" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 22, 2017 at 11:48 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

OpenStack-Ansible team,

I’ve very much enjoyed being part of the OpenStack community over the past 14 
months. My time in the OpenStack-Ansible community has been one of the most 
rewarding experiences of my career. However, my career is changing directions 
and I’ll no longer be able to invest the time and energy required to maintain 
my involvement in the community.

As a result, I’m resigning my core reviewer status effective immediately.

Thank you to all of you in the community that I’ve worked with in IRC, at 
summits in Austin and Barcelona and to all of you who gave your time to review 
and improve my contributions.

Travis Truman




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer

[Jesse Pretorius]

Hi everyone,

I’d like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it’s important that 
he’s able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

[Jesse Pretorius]

+1 from me ☺

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

Date: Friday, January 27, 2017 at 2:29 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "a...@demarco.com" , Andy McCrae 

Subject: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

Hi OpenStack-Ansible team,

I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

Amy has been consistently in the top 10 reviewers for our team in the last 30 
[1] and 90 [2] days, respectively, this release alone.

She has been an active and diligent member of the OpenStack-Ansible team since 
the end of 2015 and has continuously provided assistance for code and 
documentation reviews.

I think she will make a great addition to the core team and will help move code 
and doc issues forward quicker.

+1 from me

Thanks,

Alex

[1] http://stackalytics.com/report/contribution/openstackansible-group/30
[2] http://stackalytics.com/report/contribution/openstackansible-group/90









Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

[Jesse Pretorius]

Hi Sean,

Great to see you taking the initiative on this.

I think the starting point we’d have to work from with the way the builds are 
executed now would be to have the upgrade job execute in a periodic pipeline 
that has a longer timeout. While it would be ideal to do on-commit tests it’s 
just untenable right now as it would severely slow down the workflow.

In terms of using a ‘cached’ or pre-built container rootfs, pre-build wheels 
and venvs, etc this is something that we at Rackspace are working on already 
and are hoping to share some experience with at the Pike PTG. The initial work 
is a bit of a hack job, but we’re hoping to learn enough to share and are 
hoping to collaborate to put together something that can be used by a broader 
community and contributed to by a broader community.

Right now, however, I think we need some sort of upgrade tests on a regular 
basis more than we need to implement an alternative emans of deploying. Our 
choices are therefore, as far as I can see, to have this done in External CI or 
to use OpenStack-Infra’s periodic jobs. Once we have something in place we can 
work towards improving the execution speed (using whatever means available) to 
get to the point where we can usefully execute the jobs on-commit.

J
IRC: odyssey4me

On 1/11/17, 11:03 PM, "Sean M. Collins"  wrote:

OK - with https://review.openstack.org/#/c/418521/ we have at least a
working POC of what we can do.

The issue is that we're running into the Zuul timeout.

Depending on how quickly the AIO is built, we can get to the point where
we run the upgrade script[2].

However in some runs we don't get to the end of the AIO build[3].

So, the question is, how do we proceed? I'm not a real LXC expert but if
we could somehow cache stable builds of the LXC containers, so that
bootstrapping the AIO just means downloading and launching them, so that
we can use the majority of the Zuul runtime to execute the upgrade
script, that'd be great.

I know he have diskimage builder that does something sort of like this,
maybe we can do something similar for the LXC containers?


[1]: 
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_16_114022
[2]: 
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_24_895056
[3]: 
http://logs.openstack.org/21/418521/8/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/ac09458/console.html#_2017-01-11_21_13_55_572404
--
Sean M. Collins

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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][openstack-ansible-plugins] error in rabbitmq installation , config template plugin

[Jesse Pretorius]

From: "Shtilman, Tomer (Nokia - IL)" <tomer.shtil...@nokia.com>
Date: Thursday, November 17, 2016 at 2:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, Jesse Pretorius 
<jesse.pretor...@rackspace.co.uk>
Subject: RE: [openstack-dev] [openstack-ansible][openstack-ansible-plugins] 
error in rabbitmq installation , config template plugin

Many thanks
I was aware of the dependencies and download them all to
/home/centos/ansible-installation/roles/dependencies

[centos@ansible-tests-tshtilma dependencies]$ ls
apt_package_pinning  lxc_container_create  lxc_hosts  openstack_hosts  
pip_install

also my test playbook was taken from the examples so its almost identical

Ah, then seeing as you’re not using one of the standard search paths for 
ansible to find the roles, you’ll have to tell it where to find them through 
the standard environment variables or via an ansible.cfg file. You’ll need to 
do that for the plugins too.

For the role tests we implement the roles in ~/.ansible/roles and the plugins 
in ~/.ansible/plugins – those are both default search paths for Ansible to 
check. One more required setting is the library location, which we set to 
~/.ansible/plugins/library


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][openstack-ansible-plugins] error in rabbitmq installation , config template plugin

[Jesse Pretorius]

The error you’re seeing is because that role has dependencies which can’t be 
resolved.

The deps are here:
https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/newton/meta/main.yml#L35

The roles are mostly designed to be re-usable without the integrated 
repository, but to do so you’ll need to inspect the role tests to see what it 
needs to work:

Role requirements, to resolve the meta deps:
https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/newton/tests/ansible-role-requirements.yml

An example inventory, playbook, etc is all here:
https://github.com/openstack/openstack-ansible-rabbitmq_server/tree/stable/newton/tests

If you get stuck, feel free to join us in #openstack-ansible in IRC on Freenode.

HTH,

Jesse
IRC: odyssey4me

From: "Shtilman, Tomer (Nokia - IL)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, November 17, 2016 at 1:33 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [openstack-ansible][openstack-ansible-plugins] error 
in rabbitmq installation , config template plugin

Hi All
I am relatively new to Ansible, trying to run a playbook installing rabbit 
server https://github.com/openstack/openstack-ansible-rabbitmq_server (all 
stable/newton)

- name: Install RabbitMQ server
  hosts: rabbitmq_all
  user: root
  roles:
- { role: "rabbitmq_server", tags: [ "rabbitmq-server" ] }
  vars:
rabbitmq_cookie_token: secrete


I get an error:

statically included: 
/home/centos/ansible-installation/roles/dependencies/pip_install/tasks/configure.yml
ERROR! no action detected in task. This often indicates a misspelled module 
name, or incorrect module path.

The error appears to have been in 
'/home/centos/ansible-installation/roles/dependencies/pip_install/tasks/configure.yml':
 line 40, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:


- name: Drop pip global config(s)
  ^ here


The task is :
- name: Drop pip global config(s)
  config_template:
src: "global.conf.j2"
……



config_template task is coming from 
https://github.com/openstack/openstack-ansible-plugins/blob/master/action/_v2_config_template.py
 and cloned locally
also I have set the action_plugins = 
/home/centos/openstack-ansible-plugins:/home/centos/openstack-ansible-plugins/action
from a bit of debugging its look like the the path is scanned

Any ideas will be appreciated
Tomer


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] pip issues

[Jesse Pretorius]

For the sake of record and FYI - Instead of cross-posting, this discussion has 
been continued on the openstack-operators ML.

From: Jean-Philippe Evrard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, November 17, 2016 at 9:10 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [openstack-ansible] pip issues

Hello,

Is this a greenfield newton?
Could you wget your 
http://172.16.1.2:8181/os-releases/14.0.1/requirements_constraints.txt  file 
reliably?
Are you using haproxy?  Are all the backends OK there?

Don’t hesitate to come by our irc channel, it’s probably easier to have a 
conversation there.

Best regards,
Jean-Philippe

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

Date: Thursday, 17 November 2016 at 08:56
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [openstack-ansible] pip issues


Hi all,

Context:
openstact-ansible newton, tag: 14.0.1
OS: ubuntu 16.04 LTS

the pip command is unable to download packages form the repo container. I can 
reach the repo container from within galera container through the port 8181:

root@node01:~# lxc-attach -n node01_galera_container-368f269a
root@node01-galera-container-368f269a:~# nc -nzv 172.16.1.2 8181
Connection to 172.16.1.2 8181 port [tcp/*] succeeded!

However, when i run galera-install.yml playbook it throws the following error 
(but the root cause is pip_install role)  :
root@maas:/opt/openstack-ansible/playbooks# openstack-ansible galera-install.yml
………..
TASK [pip_install : Install pip packages (fall back mode)] *
FAILED - RETRYING: TASK: pip_install : Install pip packages (fall back mode) (5 
retries left).
FAILED - RETRYING: TASK: pip_install : Install pip packages (fall back mode) (4 
retries left).
FAILED - RETRYING: TASK: pip_install : Install pip packages (fall back mode) (3 
retries left).
FAILED - RETRYING: TASK: pip_install : Install pip packages (fall back mode) (2 
retries left).
FAILED - RETRYING: TASK: pip_install : Install pip packages (fall back mode) (1 
retries left).fatal: [node01_galera_container-368f269a]: FAILED! => {"changed": 
false, "cmd": "/usr/local/bin/pip install -U --isolated --constraint 
http://172.16.1.2:8181/os-releases/14.0.1/requirements_constraints.txt  
ndg-httpsclient requests", "failed": true, "msg": "\n:stderr: Retrying 
(Retry(total=4, connect=None, read=None, redirect=None)) after connection 
broken by 'ProtocolError('Connection aborted.', BadStatusLine(\"''\",))': 
/os-releases/14.0.1/requirements_constraints.txt\nRetrying (Retry(total=3, 
connect=None, read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', BadStatusLine(\"''\",))': 
/os-releases/14.0.1/requirements_constraints.txt\nRetrying (Retry(total=2, 
connect=None, read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', BadStatusLine(\"''\",))': 
/os-releases/14.0.1/requirements_constraints.txt\nRetrying (Retry(total=1, 
connect=None, read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', BadStatusLine(\"''\",))': 
/os-releases/14.0.1/requirements_constraints.txt\nRetrying (Retry(total=0, 
connect=None, read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', BadStatusLine(\"''\",))': 
/os-releases/14.0.1/requirements_constraints.txt\nException:\nTraceback (most 
recent call last):\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py\", line 215, in 
main\nstatus = self.run(options, args)\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py\", line 287, 
in run\nwheel_cache\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py\", line 269, in 
populate_requirement_set\nsession=session, wheel_cache=wheel_cache):\n  
File \"/usr/local/lib/python2.7/dist-packages/pip/req/req_file.py\", line 84, 
in parse_requirements\nfilename, comes_from=comes_from, session=session\n  
File \"/usr/local/lib/python2.7/dist-packages/pip/download.py\", line 409, in 
get_file_content\nresp = session.get(url)\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/sessions.py\", 
line 487, in get\nreturn self.request('GET', url, **kwargs)\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/download.py\", line 378, in 
request\nreturn super(PipSession, self).request(method, url, *args, 
**kwargs)\n  File 
\"/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/sessions.py\", 
line 475, in request\nresp = self.send(prep, **send_kwargs)\n  File 

Re: [openstack-dev] [openstack-ansible] How do you haproxy?

[Jesse Pretorius]

On 11/10/16, 2:01 PM, "Ian Cordasco"  wrote:

There are numerous existing HAProxy Ansible roles on Galaxy

(https://galaxy.ansible.com/list#/roles?page=1_size=10=haproxy).
Ostensibly one or more of these are already flexible enough for what
users might need. Why not adopt one of those and contribute back to it
instead of creating yet another HAProxy role?

All good evaluations start with understanding the requirements. ☺



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Debugging slow Xenial gate

[Jesse Pretorius]

> On 11/2/16, 1:51 PM, "Major Hayden"  wrote:
>I tossed up a horribly written hack[0] to change some CPU scheduler 
> settings back to the Trusty settings.  My initial tests were great!  Also, 
> the first test in OpenStack CI was really good --  62 minutes for trusty and 
> 65 minutes for xenial.  However, that seems to be a fluke since the second 
> test had a 30 minute gap between the test durations. :(

I think that difference was due to the hardware/contention profiles of the 
different nodepool providers. You’ll have to do tests somewhere we you can 
execute on a consistent hardware profile, ideally with no other contention on 
the host, in order to get reliable comparisons.

I think Logan may be able to help with that. Alternatively perhaps you can get 
access to an OSIC host or instance for testing?




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Jesse Pretorius]

On 10/14/16, 12:33 PM, "Sean Dague"  wrote:

> I kind of wonder if that hints to a better model here instead of the
> deployments running services from master. Instead running periodics and
> moving forward reference hashes every day if tests pass, and not if they
> fail. That would let deployment tools automatically move forward, quite
> close to master, but not get tightly coupled into every change.

FWIW That’s pretty much what OpenStack-Ansible does for our ‘integrated build’.

We have the ‘production style’ deployment pinned to upstream SHA’s which Are 
updated once every two weeks. This allows us to get on with our own development 
instead of being disrupted every time something causes a break upstream. We 
then only have to deal with upstream-related issues when we update SHA pins.

However we do also do more focused, slightly less complex builds on a per role 
(per upstream service) basis which build directly from the upstream branch. 
These have a broader testing spectrum (more platforms, more backends) and due 
to the lower level of complexity in the number of components used in the builds 
they are generally successful unless our own patch is bad.

From my own standpoint I think that if production-type build tests (with 
functional testing) are executed using deployment projects there would need to 
be:

1. A good track record of the builds succeeding without failures due to 
circumstances that are specific to the deployment tool project. Ie The builds 
must be at least as successful as DevStack in its results with as few false 
negatives as possible.
2. Each project using these tests would need a designated liaison to the 
deployment project in order to expedite the triage of issues that arise from 
the tests. The service project person understands the service and the 
deployment project liaison understands the deployment project. Effectively they 
should pair up to quickly triage and resolve any check failures that arise.
3. The tests should not just be a deployment test – they should have some level 
of functional testing too. If this is not the case then all that’s happening is 
that the deployment tooling is being tested – not the effect of the patch to 
the service project.

J



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] cinder volume lxc and iscsi

[Jesse Pretorius]

>I found in google a bug for use of open-iscsi inside lxc-container
>(https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855), a bug
>commented by Kevin Carter (openstack-ansible core team) as a "blocking
>issue" (in may 2015).
>Is that bug still relevant ?

Yes, unfortunately it is relevant. We implemented clarification patches in 
Newton to clarify that:
https://github.com/openstack/openstack-ansible/commit/a06d93daa9c0228abd46b1af462fb00651942b7e
https://github.com/openstack/openstack-ansible-os_cinder/commit/d8daff7691de60ffc6bcc4faa851d9a90712d556

So the documentation now makes it more clear in the note at the top of the page:
http://docs.openstack.org/developer/openstack-ansible-os_cinder/configure-cinder.html

>Do I need to rather deploy my cinder-volume on compute host (metal) to
>solve my problem ?

Yes, that is a known good configuration that is very stable.




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ThirdParty][CI] DSS Cinder CI <budik...@list.ru> spam

[Jesse Pretorius]

Hi everyone,

Today we started getting CI feedback for all our (OpenStack-Ansible) patches 
from DSS Cinder CI  which always immediately fail. I expect 
this may be because they’re in the process of getting setup and are supposed to 
be targeting cinder repositories.

We would appreciate it if the administrators of the account would properly 
scope their external CI tests. At the moment it’s feeling quite a bit like spam 
and if it continues without being resolved we’ll have to ask for the account to 
be disabled.

Thanks,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] git repo in infra_repo container not working

[Jesse Pretorius]

Hi Linhao Lu,

I expect that you might be hitting the fact that fastcgi is no longer 
available. Instead of using http the git protocol is now being used. See 
https://github.com/openstack/openstack-ansible-repo_server/commit/c87a8c1d4ca008e03e8dcef4160503b622d1fc1f
 for details.

Operating from the master branch can be challenging as it’s a moving target. 
When doing so I would recommend that you always ensure that you update the 
roles too by executing ‘./script/bootstrap-ansible.sh’ from the integrated repo 
root. This ensures that all the roles are updated along with the playbooks.

The transport_url issues have been resolved for a few weeks already, so I would 
recommend just checking out the current head of master.

HTH,

Jesse

From: "Lu, Lianhao" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, August 11, 2016 at 3:51 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [openstack-ansible] git repo in infra_repo container 
not working

Hi guys,

I’m encounter new problems with the OSA SHA master 
eb3aec7827e78d81469ff4489c28963ee602117c (I use this version because previously 
the master version cf79d4f6 has problems with the nova transport_url settings 
which blocks nova-api to be launched), the problem is that the git repo in 
infra_repo containers not working, which blocks me from going on.

TASK [os_nova : Get package from git] **
FAILED - RETRYING: TASK: os_nova : Get package from git (4 retries left).
… …
FAILED - RETRYING: TASK: os_nova : Get package from git (1 retries left).
fatal: [infra2_nova_console_container-2e227e79]: FAILED! => {"changed": false, 
"cmd": "/usr/bin/git ls-remote 
http://172.29.236.15:8181/openstackgit/spice-html5 -h refs/heads/54cc41299be
a8cd681ed0262735e0fd821cd774a", "failed": true, "msg": "fatal: repository 
'http://172.29.236.15:8181/openstackgit/spice-html5/' not found", "rc": 128, 
"stderr": "fatal: repository 'http:
//172.29.236.15:8181/openstackgit/spice-html5/' not found\n", "stdout": "", 
"stdout_lines": []}

cmd: /usr/bin/git ls-remote http://172.29.236.15:8181/openstackgit/spice-html5 
-h refs/heads/54cc41299bea8cd681ed0262735e0fd821cd774a

msg: fatal: repository 'http://172.29.236.15:8181/openstackgit/spice-html5/' 
not found

stderr: fatal: repository 'http://172.29.236.15:8181/openstackgit/spice-html5/' 
not found


The 172.29.236.15 is my LB ip(which use haproxy). I then “curl -L 
http://172.29.236.15:8181/openstackgit/spice-html5/” and it worked ok.

Then I ssh into one of the infra-repo containers behind  the LB, and find the 
foloowings:

-  “curl http://127.0.0.1:8181/penstackgit/spice-html5/” works, it 
display the file content under directory 
/var/www/repo/openstackgit/spice-html5/.

-  “git ls-remote /var/www/repo/openstackgit/spice-html5/” works.

-  “git ls-remote http://127.0.0.1:8181/penstackgit/spice-html5/” 
doesn’t.  It says “fatal: repository 
'http://127.0.0.1:8181/penstackgit/spice-html5/' not found”

Seems the git repo over http is not working. I checked other repos under 
/var/www/repo/openstackgit/, e.g. ceilometer, neutron, nova, they all have the 
same problems.

Any suggestions?

-Lianhao Lu


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Project Mascot

[Jesse Pretorius]

Hi everyone,

As discussed in the community meeting yesterday [1] the foundation wishes each 
project to select a mascot for the project [2][3]. The mascot needs to be 
appropriate (please read the links for the constraints) and in some way linked 
to the project. We need to come up with a list of 3-5 options.

Options discussed and agreed as appropriate in the meeting yesterday:

  1.  A Bull (links directly to Ansible’s mascot, although ours can be 
different).
  2.  A Cape Buffalo (distinctive, and reasonably close to a Bull).

Please consider and reply with more options, explaining the link to the project 
so that we can all discuss the options at the next meeting to finalise our list.

[1] 
http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
[3] http://www.openstack.org/project-mascots

Thanks,

Jesse
IRC: odyssey4me




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard for core in openstack-ansible and all openstack-ansible-* roles

[Jesse Pretorius]

From: "Truman, Travis" 
>
Subject: [openstack-dev] [openstack-ansible] Nominating Jean-Philippe Evrard 
for core in openstack-ansible and all openstack-ansible-* roles

Jean-Philippe has been providing great code reviews and patches for some time. 
His recent commitment to running bug triage every week shows his willingness to 
step up and take responsibilities within the community. He’s also found an 
opportunity to innovate by introducing an improved bug triage process. He can 
often be found in #openstack-ansible as evrardjp providing support to deployers 
in a welcoming and friendly manner.

In short, just the kind of contribution our community desires from core 
reviewers.

Very much agreed. +1 from me!


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] existing centralized syslog server

[Jesse Pretorius]

On 7/6/16, 3:24 PM, "fabrice grelaud"  wrote:

>
>I would like to know what is the best approach to customize our 
>openstack-ansible deployment if we want to use our existing solution of ELK 
>and centralized rsyslog server.
>
>We deploy openstack-ansible (mitaka 13.1.2 release) on our infrastructure with 
>for convenient and no risk a vm for syslog server role. That is ok. But now if 
>i want to use our centralized syslog server ?
>
>What i need is to set ip address of our existing server to the rsyslog client 
>(containers + metal) and of course configure our rsyslog.conf to manage 
>openstack template.
>So:
>- no need to create on the log server a lxc container (setup-hosts.yml: 
>lxc-hosts-setup, lxc-containers-create)
>- no need to install syslog server (setup-infrastructure.yml: 
>rsyslog-install.yml)

To add more rsyslog targets for logs you can see in 
https://github.com/openstack/openstack-ansible-rsyslog_client/blob/stable/mitaka/defaults/main.yml#L56-L73
 that there is an example of the changes you need to make to 
/etc/openstack_deploy/user_variables.yml to include additional targets.

You may be able to do away with the log host altogether as you desire by simply 
leaving the ‘log_hosts’ group out of the 
/etc/openstack_deploy/openstack_user_config.yml and 
/etc/openstack_deploy/conf.d/*.yml files. This is an untested code path so you 
may find that we make assumptions about the presence of the log_host so please 
register bugs for any issues you find so that we can eradicate those 
assumptions. To my mind the log host is not required for a deployment if the 
deployer so chooses (and especially if the deployer has alternative syslog 
targets in-place).

>How can i modify my openstack-ansible environment (/etc/openstack_deploy, 
>env.d, conf.d, openstack_user_config.yml, user_variables.yml, playbook ?) the 
>most transparent manner and that permits minor release update simply ?

As long as you’re only editing things in user space (i.e. In 
/etc/openstack_deploy/) and not in-tree (i.e. In /opt/openstack-ansible/) then 
the minor upgrade process is documented here: 
http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/app-minorupgrade.html

I hope that this answers your questions!


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Jesse Pretorius]

From: Joshua Hesketh >

I assume you want to wait for the tag to merge before removing the branch?

The only tag job I can see for openstack-ansible* projects is the releasenotes 
one. This should be harmless as it just generates the notes for mitaka and 
liberty branches. I'm going to hold off until the final tag has merged anyway 
if you want to confirm this first.

Thanks Josh – The final Kilo tag has merged so we’re good to go. We’re happy to 
also go straight ahead with the eol tags for the icehouse and juno branches too.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?

[Jesse Pretorius]

On 7/1/16, 8:48 PM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:



>-Original Message-
>From: Jesse Pretorius <jesse.pretor...@rackspace.co.uk>
>
>> In a recent conversation on the Operators list [1] there was a discussion 
>> about purging
>> archived data in the database. It would seem to me an important step in 
>> maintaining an
>> environment which should be done from time to time and perhaps at the very 
>> least prior
>> to a major upgrade.
>>
>> What’re the thoughts on how often this should be done? Should we include it 
>> as an opt-in
>> step, or an opt-out step?
>>
>> [1] 
>> http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html
>
>Is OpenStack-Ansible now going to get into the minutae of operating
>the entire cloud? I was under the impression that it left the easy
>things to the operators (e.g., deciding when and how to purge the
>database) while taking care of the things that are less obvious
>(setting up OpenStack, and interacting with the database directly to
>only set up things for the services).

That’s a good question which betrays the fact that I phrased my question 
poorly. :)

The question is whether we should do something like this:

1) As part of the normal execution of the service playbooks;
2) As part of the automated major upgrade (i.e. The step is not optional);
3) As part of the manual major upgrade (i.e. The step is optional);
4) Never.

If never, it might be useful for our community to curate a few bits of 
operations tooling to automated this sort of thing on demand. The tooling can 
be placed into the Ops repository [1] if this is done.

[1] https://github.com/openstack/openstack-ansible-ops


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Jesse Pretorius]

Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented we’ve 
requested a final tag [1]. Once that merges we are ready to have our kilo-eol 
tag implemented and the ‘kilo’ branch removed.

Whoops – I forget to add the link to the final Kilo tag request.

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



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Jesse Pretorius]

Hi all,

Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented we’ve 
requested a final tag [1]. Once that merges we are ready to have our kilo-eol 
tag implemented and the ‘kilo’ branch removed.

Just to make life interesting, we still have leftover ‘juno’ and ‘icehouse’ 
branches and would like to implement eol tags for them too. I think we have the 
appropriate skips in place for the juno branch so there should be no funky 
post-tag jobs kicking off for them, but the icehouse branch may end up with 
some unknown jobs kicking off. If you can help identify the changes we need to 
get implemented into project-config then we can be rid of the old cruft.

Thanks,

Jesse


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ansible] Fail to install Openstack all in one

[Jesse Pretorius]

On Thu, Jun 23, 2016 at 8:47 AM, Alioune 
> wrote:

I'm trying to install OpenStack all in one using ansible but I got the error 
bellow.
Someone knows how to solve this error?

Regards,

ERROR:
+ openstack-ansible --forks 1 openstack-hosts-setup.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e 
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution 
error: No user config loadaed
No openstack_user_config files are available in either the base location or the 
conf.d directory

For the all-in-one it looks like you’ve skipped the execution of the 
‘bootstrap-aio.sh’ script which puts all the AIO configurations into place. 
This is covered in the AIO documentation [1].

As Jimmy has said, please feel free to drop by in #openstack-ansible on 
freenode for more active assistance.

[1] 
http://docs.openstack.org/developer/openstack-ansible/developer-docs/quickstart-aio.html


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] When to purge the DB, and when not to purge the DB?

[Jesse Pretorius]

Hi everyone,

In a recent conversation on the Operators list [1] there was a discussion about 
purging archived data in the database. It would seem to me an important step in 
maintaining an environment which should be done from time to time and perhaps 
at the very least prior to a major upgrade.

What’re the thoughts on how often this should be done? Should we include it as 
an opt-in step, or an opt-out step?

[1] 
http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html

—
Jesse Pretorius
IRC: odyssey4me
<http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html>


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Deeper diffs in OSA releases

[Jesse Pretorius]

On 14 June 2016 at 13:50, Major Hayden  wrote:
>
>
> Every OpenStack-Ansible release consists of SHA bumps for roles as well as
> OpenStack services (like keystone, nova, and glance).  However, tracking
> the diffs of the changes in those OpenStack services can be challenging.
> It's difficult to tell if that nova fix you've been waiting for has made it
> into a particular OSA release.
>
> I have written a script to make this a little easier (hopefully).[1]  The
> script takes two parameters:
>
> $ ./osadiffer.py [older OSA SHA] [newer OSA SHA]
>
> It digs into the YAML files for the repo build and retrieves the list of
> commits that were applied to the OpenStack services that OSA builds for the
> repo server.  Al of those commits are rolled into a report[2].
>
> The script seems to work fairly well so far, even with big diffs.
> However, I'm not sure where the script actually belongs.  I proposed it for
> openstack-ansible-ops, but we don't have the right scaffolding there yet
> for testing.  Would it make more sense to have it in openstack-ansible's
> 'scripts' directory?
>
> Thanks for your input! :)
>
> [1] https://review.openstack.org/328469
> [2] http://paste.openstack.org/raw/510670/


That's neat Major! It'd be great to extend it to also do the diffs for the
included roles, both OpenStack and non-OpenStack to get full coverage.

I think the ops repo is the right one - we just need to get the scaffolding
in place. I'll put a review up shortly.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Mid-cycle date selection (need input!)

[Jesse Pretorius]

On 9 June 2016 at 19:51, Major Hayden  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey folks,
>
> I've been able to secure a few dates at Rackspace's headquarters in San
> Antonio, Texas:
>
>   1) August 10-12
>   2) August 22-26
>   3) August 29 - September 2
>
> During the meeting earlier today, #3 was determined to cause a lot of
> conflicts for people.  #1 seems to be the most preferred.  I have emails
> out to ask about deals on local hotels and I'm waiting to hear back on
> those.
>
> The room should seat about 20-25 people and we would have at least one
> projector.
>
> Please reply with your thoughts and a date preference!  Once we get that
> sorted out, we can fire up an etherpad for everyone to sign up for a spot.
>

Thanks Major. I have no conflicts for any of the dates. By option 2 I'm
guessing you mean either 22-24 August (Mon-Wed) or 24-26 (Wed-Fri) rather
than the entire week?

I would prefer an option in option 2's range, but option 1 or 3 are also
fine.
__
OpenStack Development Mailing 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] [stable][all] Tagging kilo-eol for "the world"

[Jesse Pretorius]

Hi Tony,

OpenStack-Ansible is just waiting for the requirements repository and the
swift repository kilo-eol tags. Once they're done we'd like to bump the
SHA's for our 'kilo' to the EOL tags of those two repositories, tag a
release, then do our own kilo-eol tag.

Thanks,

Jesse
IRC: odyssey4me

On 2 June 2016 at 11:31, Tony Breeds <t...@bakeyournoodle.com> wrote:

> Hi all,
> In early May we tagged/EOL'd several (13) projects.  We'd like to do a
> final round for a more complete set.  We looked for projects meet one or
> more
> of the following criteria:
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'release:managed' or 'stable:follows-policy' (or both).
>
> The list of 171 projects that match above is at [1].  There are another 68
> projects at [2] that have kilo branches but do NOT match the criteria
> above.
>
> Please look over both lists by 2016-06-09 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of
> EOLing and
>   why.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>
> Any projects that will be EOL'd will need all open reviews abandoned
> before it
> can be processed.  I'm very happy to do this.
>
> I'd like to hand over the list of ready to EOL repos to the infra team on
> 2016-09-10 (UTC)
>
> Yours Tony.
> [1] http://paste.openstack.org/show/507233/
> [2] http://paste.openstack.org/show/507232/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Jesse Pretorius
mobile: +44 7586 906045
email: jesse.pretor...@gmail.com
skype: jesse.pretorius
__
OpenStack Development Mailing 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] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

[Jesse Pretorius]

On 9 May 2016 at 15:27, Jean-Philippe Evrard 
wrote:

> I am using ansible for some time now, and I think the current default
> Ansible inventory system is lacking a few features, at least when working
> on an OpenStack cloud - whether it's for its deployment, its support or its
> usage.
> I'm thinking of developing a new inventory, based on (openstack-)ansible
> experience.
>
There were discussions at the summit around the implementation of an
inventory system to cater for many of the things you're outlining. I wasn't
party to them but as I recall there were both presentations and design
discussions and the effort is being led by a team of OSIC developers.

My view is that all of this most certainly does not belong in Ansible and
most of it does not belong in an Ansible dynamic inventory script either.
It should be handled somewhere else and Ansible should simply consume it.

> I think all the results from this etherpad could be either used for
> ansible upstream or for the openstack-ansible project, so that's why I'm
> spamming here. Thank for your help!
>
Specifically for OpenStack-Ansible we need something that's easily
implemented for small or dev/test environments, but ideally if a deployment
is using a complex production inventory system or a non-complex development
system the interactions should be the same. This is one of the reasons
we've discussed (in theory) the use of a dynamic inventory with the tooz
library - it can do file back-ends or more distributed back-ends.
__
OpenStack Development Mailing 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] cross-project deployment tool meeting

[Jesse Pretorius]

On 26 April 2016 at 17:54, Jan Klare  wrote:

>
>  i just wanted to follow up on this session (
> https://etherpad.openstack.org/p/newton-deployment-tools-discussion) were
> we talked about a cross-project meeting for deployment tools. I would love
> to see something like that happen and it would be great if we can find a
> specific date (maybe monthly) to do something like that. If you are
> interested in going to such a meeting, please reply to this mail with a
> suggestion when you could join such a meeting.
>
> Cheers,
> Jan (OpenStack Chef)
>

Thanks Jan. I think once per month will be enough.

I'm based in the UK and am reasonably flexible around times, although it is
usually more productive if it can be held during my day rather than my
evening.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

[Jesse Pretorius]

On 6 May 2016 at 15:25, Doug Hellmann  wrote:

>
> Someone had a tool that looked at second-order dependencies, I think. I
> can't find the reference in my notes, but maybe someone else has it
> handy?
>

I don't have a specific tool handy, but I'm guessing that we could cludge
something together through the implementation of tooling that effectively
builds venvs for each project and grabs a pip freeze from each of them.
That could at least give us a set of data to examine and work from?

We have something that kinda does this [2] although the purpose is quite
different. I would guess that we could either work out a way to make use of
this to achieve the goal through an automated process, or we could just
derive something useful from it. If this is deemed the best or only option
then I'd be happy to take this up.

If there's a better way then I'm all for it, but from what I see the pip
project has a long standing [1] issue for a resolver.

[1] https://github.com/pypa/pip/issues/988
[2] https://github.com/openstack/openstack-ansible-repo_build
__
OpenStack Development Mailing 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] xenial or trusty

[Jesse Pretorius]

On 6 May 2016 at 16:27, Jeffrey Zhang <zhang.lei@gmail.com> wrote:

>
> On Fri, May 6, 2016 at 9:09 PM, Jesse Pretorius <jesse.pretor...@gmail.com
> > wrote:
>
>> FWIW OpenStack-Ansible is choosing to support deployment on both Ubuntu
>> 14.04 LTS and Ubuntu 16.04 LTS for both the Newton and Ocata cycles, with
>> the current proposal to drop it in P. The intent is to provide our
>> deployers the opportunity to transition with a mixed deployment.
>
>
> Are you meaning the host/baremetal OS? ​the openstack-ansible deploy the
> OpenStack in LXC.​
> So it really do not care about the host machine's OS. Kolla is not care
> about it, too.
> I think the openstack-ansible a specify LXC image, and do not support
> multi base image.
>
> if not, could u provide any prove for this?
>

OSA supports the implementation of OpenStack on bare metal or in LXC
machine containers, so we need to cater for both. When an LXC machine
container is deployed we've chosen to use the strategy of always
implementing the same OS in the container as is implemented on the host.
This simplifies our testing greatly.

For the sake of background information, seeing as you asked, the base LXC
image we're using comes from https://images.linuxcontainers.org/ giving us
the ability to support multiple versions, multiple distributions and
multiple architectures, and it's especially nifty that the entire image
build process is open source and therefore can be implemented and
customised by our deployers.

I guess this is similar for Kolla in a different way because the image
pipeline is defined by the project and implemented through the docker image
building processes.
__
OpenStack Development Mailing 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] xenial or trusty

[Jesse Pretorius]

On 4 May 2016 at 19:21, Emilien Macchi  wrote:

> On Wed, May 4, 2016 at 1:52 PM, Jeffrey Zhang 
> wrote:
> > I'd like to lock the tag version in certain branch. One branch only
> support
> > one
> > distro release.
> >
> > For example, the mitaka branch only build on Trusty and the master/newton
> > branch
> > only build on Xenial.
> >
> > So, the branch and OS matrix should like ( fix me and the ?)
> >
> >   Ubuntu CentOS Debian  OracleLinux
> > Liberty14.047  ? ?
> > Mitaka 14.047  ? ?
> > Master 16.047  ? ?
>
> FWIW, this is what we plan to do in Puppet OpenStack CI (except we
> don't gate on OracleLinux & Debian).


FWIW OpenStack-Ansible is choosing to support deployment on both Ubuntu
14.04 LTS and Ubuntu 16.04 LTS for both the Newton and Ocata cycles, with
the current proposal to drop it in P. The intent is to provide our
deployers the opportunity to transition with a mixed deployment.

Obviously YMMV and our plans may change based on the actual implementation
details.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Nominate Major Hayden for core in openstack-ansible-security

[Jesse Pretorius]

On 3 May 2016 at 23:59, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:

>
> Sounds like a major win for the team!


Haha! Quite!

+1 for me on the proposal. I've spoken to Major and confirmed that he has
the support from his employer to commit the time necessary on a consistent
basis.

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Bug Triage 26 Apr & Community Meeting 28 Apr

[Jesse Pretorius]

Hi everyone,

Due to many of us being at the summit, the weekly meetings for 26 and 28
Apr have been cancelled.

See you in Austin!

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] -The lifecycle of deploying openstack on production environment

[Jesse Pretorius]

On 15 April 2016 at 07:53, Kenny Ji-work  wrote:

>
> We wanner to deploy openstack to the production environment, so what's the
> recommended way to complete it? By using *puppet-openstack *or any else
> tool?
> *Secondly*, we want to add *custom codes* into the openstack's. So the
> problem is that if new version of openstack is released, the efforts taken
> to port the codes to the new version must be put into action. In one word,
> is there some convenient way to realize it?
> *Thirdly*, if we want to *upgrade *our openstack version in the
> production environment, how can we do it easier? Thank you for answering!
>

Hi Kenny,

There are projects within OpenStack which facilitate deployments using
Puppet, Chef, Ansible, Docker, etc. What you choose really depends on your
existing skill set and preferences. I would advise that you evaluate each
project and select one that suits your needs.

>From the point of view of the OpenStack-Ansible project we provide a tool
set to deploy OpenStack using Ansible. Our documentation [1] is pretty good
(and getting better all the time thanks to input from Operators). The
deployment we cater for is a stable, highly available deployment for
production usage and we allow a great deal of customisation in terms of
deployment design and OpenStack configuration.

The project deploys directly from the OpenStack service project git sources
and provides you the ability to change that git source to your own, so you
can easily point it at a fork of the OpenStack service projects if you so
choose.

Lastly the project does include tasks to handle upgrades. We have a
complete and tested set for Juno->Kilo->Liberty and will be working on
Liberty->Mitaka early within the Newton cycle.

I encourage you to engage with us in #openstack-ansible to discuss your
use-case and your experience as you evaluate the tooling we provide. I hope
that it already meets your needs, but if it doesn't then we'd definitely
like feedback to improve our deliverables.

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

Best regards,

Jesse
IRC: odyssey4me
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Design Summit Schedule

[Jesse Pretorius]

Hi everyone,

The Design Summit Schedule has been posted and the details for each session
has been completed [1].

Please can all moderators for the sessions ensure that the session times
don't clash with any other commitments, the content in the description is
correct and ensure that the Etherpads are populated with some initial
content describing the material you wish to cover, questions to ask, etc.

If anyone needs changes made, please let me know and I'll get it done.

Looking forward to seeing you all!

[1]
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=OpenStackAnsible

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Mitaka release

[Jesse Pretorius]

The OpenStack-Ansible project is pleased to announce the availability of
it's Mitaka release, v13.0.0, and with it comes the following features:

Increased modularity:
The Ansible roles we provide deploy OpenStack services directly from a git
source into python venvs, and deploy their key infrastructure dependencies.
For Mitaka we have broken the roles out into their own repositories in
order to allow deployers to make use of them with their own Ansible
playbooks. This further increases the options available to deployers,
giving even more choice for how to use the tools we provide to suit the
needs of the target environment.

Improved Usability:
We have made great strides in improving documentation for both developers
and deployers in order to improve the usability of OpenStack-Ansible
overall.

Additional services:
OpenStack-Ansible can now deploy Neutron LBaaSv2.
OpenStack-Ansible can now deploy Neutron FWaaS.
OpenStack-Ansible has a new experimental roles for the deployment of
Ironic, Designate, Zaqar, Magnum, Barbican. Each of these roles are still
in their early stages of development and are in varying states of
functional completion. Anyone interested in joining the development process
is welcome to make contact with us through the ML or on IRC in
#openstack-ansible.

Increased test coverage:
While we still have full integration testing on every commit to ensure that
the deployment of OpenStack by OpenStack-Ansible's playbooks really works,
we increased test coverage for the dynamic inventory and individual roles
in order to increase the test coverage, improve code quality, reduce
regressions and to cover more difficult test cases (eg: the major version
upgrade of MariaDB).

Some of the work intended for inclusion in the Mitaka release unfortunately
missed the deadline, so we expect that it will be completed and backported
to Mitaka early in the Newton cycle. This work includes:
 - The inclusion of Ironic in the integrated build.
 - Support for Nuage as a networking provider for Neutron.
 - Support for OVS as an ML2 provider for Neutron.

Generally speaking, it has been exciting to see how our community has grown
in the Mitaka cycle. The activity in the IRC channel has shown that we now
have even more organisations making use of OSA to deploy both private and
public OpenStack clouds.

Looking forward into the Newton cycle we'll be continuing work on Multi-OS
enablement, adding support for Ubuntu 16.04 LTS, taking advantage of
Ansible 2.x, revisiting the dynamic inventory with a view on how
environments are deployed across regions and with Cells v2, and of course
adding support for Liberty->Mitaka upgrades.

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] Newton Summit: cross-project session for deployment tools projects

[Jesse Pretorius]

On 31 March 2016 at 22:40, Emilien Macchi  wrote:

>
> OpenStack big tent has different projects for deployments: Puppet,
> Chef, Ansible, Kolla, TripleO, (...) but we still have some topics  in
> common.
> I propose we use the Cross-project day to meet and talk about our
> common topics: CI, doc, release, backward compatibility management,
> etc.
>
> Feel free to look at the proposed session and comment:
> https://etherpad.openstack.org/p/newton-cross-project-sessions
>

Thanks for raising this Emilien. As discussed in #openstack-dev I think
we're long overdue to have a session like this where we can compare notes
and find ways to work together to improve the experience of deployers who
need to implement, upgrade and maintain OpenStack.

I feel strongly that deployment tooling projects play a unique role in the
community where we touch both Operators and Developers. In doing so we can
certainly work together to improve the quality of project documentation,
improve integrated testing for the projects, provide improved design
examples for common use-cases (with example configurations for our
respective projects) and contribute generally to the architecture, security
and other guides which inform operators.

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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Jesse Pretorius]

On 22 March 2016 at 09:15, Thierry Carrez  wrote:

>
> For OSA, we don't produce the deployment tool, only a set of playbooks. I
> was thinking we might need a type:packaging tag to describe which things we
> produce are just about packaging OpenStack things for usage by outside
> deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm not sure
> your type:deployment tag would apply to OSA.
>

Yeah, I suppose it depends on how you define 'deployment tool'. OSA is an
umbrella project providing Ansible roles which deploy services, and
playbooks that put them together in an integrated deployment.

Fuel similarly has libraries, Puppet roles, plugins, etc which are all
packaged together to provide what we call 'Fuel'.

I expect that there are other similarities - for instance 'Keystone' may be
a service, but that service has libraries and all combined together we call
it a daemon service.

I guess it would be nice to have some sort of designation to allow easier
filtering for consumers, assuming that this actually does add value to
Operators/Packagers who consume these projects.
__
OpenStack Development Mailing 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] [OpenStack-Ansible] PTL Candidacy

[Jesse Pretorius]

Hi everyone,

The Mitaka cycle for OpenStack-Ansible (OSA) has had the following
successes:

1. Our community has grown. The activity in the IRC channel has shown that
we now have more people making use of OSA to deploy both private and public
OpenStack clouds. Our development team now includes two non-Rackspace core
team members who are committed to ensuring that OSA's development process
has more diversity in its inputs and outputs. We have also increased the
breadth of roles available to our deployers. Most importantly they were
developed by non-core development team members.

2. The roles are more modular. We've split out the Ansible roles into
composable units which are usable without the dynamic inventory, LXC and
without the general playbook tooling which has been implemented in the
integrated build OSA repository.

3. Multi-OS platform support enablement has progressed. Several of the
roles in our stable are already passing the CentOS-based gate check, even
though this work was very low priority in the cycle.

4. Usability has improved. We've done an amazing job of improving install
guide documentation, improving developer documentation, and adding release
notes for the Mitaka release and retrospectively for the Liberty release.

It would be my honour to serve as PTL for the Newton cycle to continue the
journey along the following themes:

1. Grow the community
I would like to continue to increase our community participation through
the engagement with other OpenStack Projects and the Operator community. I
believe that it's crucial to the success of the project to increase the
diversity of contributors. Our work in the Mitaka cycle has laid a good
foundation on which I'd like to build through active engagement with the
respective communities to share how OSA can meet the needs of both the
Developer and Operator communities.

2. Improve testing
In the Mitaka cycle we laid the foundation for broader and deeper testing
for each role and for the integrated tests. In the Newton cycle we need to
complete that work in order to ensure that we have greater confidence that
every patch submitted produces a functional build and does not introduce
regressions in existing deployments. We need to ensure that each role is
tested both in terms convergence and in terms of function.
We also need to ensure that we have integrated testing for a broader
variety of scenario's to ensure that each scenario that is considered a
supported deployment design is tested.

3. Improve usability
While OSA is reasonably simple to use to deploy OpenStack, a barrier to
most new users is understanding how to customise the inventory and how to
prepare the host networking.
I'd like us to reduce this barrier to entry in the Newton cycle in order to
further simplify an OpenStack deployment for a new user.

4. Improve platform support enablement
In the Newton cycle we have agreed to ensure that we take advantage of
Ansible 2.x and that we also implement support for Ubuntu 16.04 LTS. This
work will implement the patterns which make it much easier to add more
Linux distributions to our supported platform list.

I look forward to working with you all in the Newton cycle and hope that we
can meet our lofty goals!

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

Re: [openstack-dev] [openstack-ansible][security] Security hardening backport to Liberty desirable?

[Jesse Pretorius]

On 7 March 2016 at 14:25, Major Hayden  wrote:

>
> That seems reasonable.  Would it be appropriate to add some documentation
> in the Liberty release that explains how to enable the role with that
> release?
>

Yes, I think that's a perfectly reasonable thing to do.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Security hardening backport to Liberty desirable?

[Jesse Pretorius]

On 4 March 2016 at 16:50, Major Hayden  wrote:

> Hey folks,
>
> I have proposed a review[1] which adds the openstack-ansible-security[2]
> role to OpenStack-Ansible's Liberty release.  I would really appreciate
> some feedback from deployers on whether this change is desirable in Liberty.
>
> The role applies cleanly to Liberty on Ubuntu 14.04 and the role already
> has some fairly basic gating.
>
> The two main questions are:
>
>   1) Does it make sense to backport the openstack-ansible-security
>  role/playbook to Liberty?
>   2) Should it be applied by default on AIO/gate builds as it is
>  in Mitaka (master)?
>
> Thanks!
>
> [1] https://review.openstack.org/#/c/273257/
> [2] http://docs.openstack.org/developer/openstack-ansible-security/


Hi Major,

Liberty is a stable branch and the Mitaka release is just around the
corner. I think it's a bit late in the game to add it. Consider, also, that
deployers can easily consume the role with their own playbook to execute it
if they would like to.

*If* a backport is supported by the consuming community and core team, I
would only support an opt-in model to allow deployers to make use of the
role, but only if they choose to.
__
OpenStack Development Mailing 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] sqlalchemy-utils fails devstack install

[Jesse Pretorius]

On 25 February 2016 at 06:43, Shinobu Kinjo  wrote:

> Sorry, I don't use master.
> But AFAICT there is no issue with stable/liberty.
>

It would seem that this is affecting neutron, oslo.messaging, kolla,
barbican, openstack-ansible, octavia and is affecting master and liberty
branches.

http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Meetings this week

[Jesse Pretorius]

Hi everyone,

Due to being active at the Ops Mid Cycle, the OpenStack-Ansible Mid Cycle
and Ansiblefest this week the bug triage and community meetings this week
will not be taking place.

We'll resume the normal scheduled meetings next week.

Thanks,

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

Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

[Jesse Pretorius]

Darragh - thanks for sharing your thoughts. We look forward to working with
you!

On 1 February 2016 at 14:20, Bailey, Darragh  wrote:

>
> My initial thoughts are that the first 2 places to focus for alignment
> (assuming people agree with the idea of life cycle phases) would be:
>
> a) abstract the different life cycle phases we have for HLM to be
> controlled by a role var. (I'll elaborate more below)
>

Agreed, this does seem to be a pattern which is forming within the Ansible
community. The debate, as always, is what is considered to be the
composable unit. In theory each role should do one thing and should be
simple, but roles have an overhead attached to them so it's becoming useful
to provide code paths within the role instead of separating each
function/life cycle phase (eg: check-prerequisites, install, configure,
upgrade, test) that can be activated as necessary. For me, this strikes a
nice balance between a sprawling set of roles and an over-complex set of
roles. It's easy to use and easy to understand.


> b) Move the current var access in the defaults.yml that has knowledge of
> config-processor output structure to be abstracted at the site level so
> you can use the same roles whether it's with data from the hlm config
> processor or another source (reusability is key). I guess could use
> wrapper roles, but I think that's less desirable except for handling
> edge cases or transition.
>

Yes, this would be good. What also seems to be forming as a pattern within
the community is a concept of internal vars (vars only for use within the
role) and external vars (vars which may be overridden by group_vars, plays,
CLI, etc). The internal vars are not subject to deprecation, whereas the
external vars are as they effectively fall into something akin to an 'API
contract'.

The same pattern should perhaps also be applied to playbooks - some should
be part of the API contract, and some not.

I'd like us to get a discussion going around these patterns sooner rather
than later, which the hope of completing them and setting them as a policy
in place for the Newton cycle. Shall we arrange some sort of discussion at
the OSA mid-cycle [1] to start this work? We have arranged for the
possibility of remote participation if you can't make it to the UK for it.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085810.html

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

Re: [openstack-dev] [openstack-ansible][security] Security hardening is now integrated!

[Jesse Pretorius]

On 27 January 2016 at 13:29, Major Hayden  wrote:

>
> After four months and 80+ gerrit reviews, the security hardening
> configurations provided by the openstack-ansible-security role are now
> integrated with OpenStack-Ansible!  The Jenkins gate jobs for
> OpenStack-Ansible are already applying these configurations by default.
>

Excellent work Major, thanks for leading this effort and thank you to all
the reviewers and contributors for making this happen!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

[Jesse Pretorius]

On 13 January 2016 at 15:10, Major Hayden  wrote:

>
> For example, the STIG requires[1] that all system accounts other than root
> are locked.  This could be dangerous on a running production system as
> Ubuntu has non-root accounts that are not locked.  At the moment, the
> playbook does a hard stop (using the fail module) when this check
> fails[2].  Although that can be skipped with --skip-tag, it can be a little
> annoying if you have automation that depends on the playbook running
> without stopping.
>
> Is there a good alternative for this?  I've found a few options:
>
>   1) Leave it as-is and do a hard stop on these tasks
>   2) Print a warning to the console but let the playbook continue
>   3) Use an Ansible callback plugin to catch these and print them at the
> end of the playbook run
>
> Thanks in advance for any advice!
>
> [1]
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2015-05-26/finding/V-38496
> [2]
> https://github.com/openstack/openstack-ansible-security/blob/master/tasks/auth.yml#L60-L87


I think the best thing to do here is to take a stance on what the
project/role deems to be a good set of defaults for the environment its
catering for. Whatever that stance is should be rigorously enforced (ie the
playbook should hard stop if there is non-compliance).

For anyone using automation, if they wish to skip particular compliance
elements then they should build the skip into their automation (ie add
--skip-tags). Skipping compliance should be a conscious action implemented
deliberately by the consumer of the role.

Darren's reply is interesting and perhaps worth consideration. As far as I
recall the security role adopted the STIG primarily because it was the only
openly available set of standards that didn't require licensing. If there
are other options to explore and ways to consume them, then perhaps that
should be an initiative for the Newton cycle?
__
OpenStack Development Mailing 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] Use of restricted and multiverse in the gate

[Jesse Pretorius]

On 7 February 2016 at 14:11, Monty Taylor  wrote:

> We're working on getting per-region APT mirrors stood up for the nodepool
> nodes to use in the gate. As part of working on this, it struck me that we
> currently have restricted and multiverse enabled in our sources.list file.
>
> I ran a quick test of removing both of them on a devstack-gate change and
> nothing broke, so I believe that it would be safe to remove them, but I
> thought I'd check with everyone.
>
> Any objection to not including these in our apt mirrors?
>

I did a quick test run of our standard commit test (convergence and
functional test) and it has passed: https://review.openstack.org/277178

This covers tempest scenario testing including Nova, Glance, Swift, Cinder,
Keystone, Neutron.

For us (OpenStack-Ansible) it seems that we can do without the restricted
and multiverse components.

Thanks for the heads-up!

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

Re: [openstack-dev] [openstack-ansible][security] Improving SSL/TLS in OpenStack-Ansible

[Jesse Pretorius]

On 15 January 2016 at 14:18, Major Hayden  wrote:
>
>
> I've attended some of the OpenStack Security Mid-Cycle meeting this week
> and Robert Clark was kind enough to give me a deep dive on the Anchor
> project[1].  We had a good discussion around my original email thread[2] on
> improving SSL/TLS certificates within OpenStack-Ansible (OSA) and we went
> over my proposed spec[3] on the topic.
>
> Jean-Philippe Evrard helped me assemble an etherpad[4] this morning where
> we brainstormed some problem statements, user stories, and potential
> solutions for improving the certificate experience in OSA.  It seems like
> an ephemeral PKI solution, like Anchor, might provide a better certificate
> experience for users while also making the revocation and issuance process
> easier.
>
> I'd really like to get some feedback from the OpenStack community on our
> current brainstorming efforts.  We've enumerated a few use cases and user
> stories already, but we've probably missed some other important ones.  Feel
> free to stop by #openstack-ansible or join us in the etherpad.
>
> Thanks!
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Anchor
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077877.html
> [3] https://review.openstack.org/#/c/243332/
> [4] https://etherpad.openstack.org/p/openstack-ansible-tls-improvement


Major - fantastic initiative.

One thing I'd like to say is to remind you that OSA is a toolbox of roles
and plays that a deployer can mix and match to suit the needs of the
specific environment.

This effectively means that we could easily curate or consume Ansible roles
which do any of the options outlined as possible solutions. What we care
about mostly is:

1 - consistency in the deployment of certificates and configuration of
services (consistency improves ease of use)
2 - simplicity of deployment - for example making it easy to apply one set
of certs across the board
3 - modularity - retain the ability to apply a different cert to any one
service, and the ability to have TLS/SSL on for some and not for others
4 - testing - we need to be able to gate test services individually, and in
end-to-end scenario's. Each possible scenario costs time, effort and gate
resources - so ideally we want to reduce our first class tested scenario's
but implement everything in such a way that we have a high level of
confidence that replacing one certificate generation method with another
will not change the result.

Thanks to both yourself and Jean-Philippe for taking this 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] [all][tc] Proposal: Separate design summits from OpenStack conferences

[Jesse Pretorius]

Simply replying to the last reply in the thread to add a thought:

As someone who wants to be speaking more in presentations and be involved
in 'User' or 'Operator' conversations, but also wants to participate in
project-specific design sessions, I find that the context switches make it
difficult to be fully attentive in all activities.

Perhaps a way to do this is to stagger it slightly? In other words - the
User/Operator/Cross-Project presentations/sessions are done in the first
few days and the more project-focused design sessions follow after for a
few days. That way all design sessions are done with User/Operator feedback
in mind.

As a member of the deployment tooling development community we have the
additional desire to somehow attend user/operator sessions, service project
sessions and then also do our own sessions. It would seem far more optimal
if we could somehow follow after the service project sessions so that
operators and service developers could also be a part of our deployment
sessions, although perhaps it'd be useful to service project developers to
attend deployment tooling sessions ahead of their own sessions.

Jesse
IRC: odyssey4me
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Multi-OS Support

[Jesse Pretorius]

Hi everyone,

As part of the Multi-OS support work [1] we've agreed to do proof of
concept reviews for the purpose of discussing and agreeing on patterns
which we need to adopt across our whole stack.

With thanks to Michael Gugino we have a review [2] ready which implements a
pattern for one aspect of the changes we'll need to be making - catering
for different package installers. The review covers apt and yum based
installers, but makes it fairly trivial to extend support for other
installer types in the future.

As part of this initiative we now also have non-voting gate checks for
CentOS7 against all the independent roles [3].

We've already has some discussion in the review and in the community
meetings, but I'd like to extend a request to the broader community for
broader review and discussion. I expect that we'll be finalising the review
by the close of this coming week. Once that's done we'll be reaching out
for volunteers to submit reviews to implement this pattern across all the
OpenStack-Ansible roles [3].

Our next steps in this initiative is to establish patterns for the support
of multiple init systems (sysvinit vs systemd, etc), then move on to
investigate other issues of importance which have been highlighted in the
etherpad [1].

If anyone else wants to volunteer to be a part of making this happen,
please feel free to add your details to the etherpad [1] or to reply to
this email.

Thanks to everyone for your input thus far.

[1] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
[2] https://review.openstack.org/274290
[3] https://github.com/openstack/?query=openstack-ansible-

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

Re: [openstack-dev] [OpenStack-Ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

As discussed in the community meeting today [1] we will be able to include
remote participants in the Mid Cycle via Video Conference. In order to
facilitate this I need to ensure that we have an attendance list for me to
send the Video Conference invitations to, so please get a Remote
Partitipation ticket in Eventbrite [2] if you intend to join us through
this facility.

The agenda is still open for discussion at this stage, so proposals on the
Etherpad [3] are welcome.

As always, please feel free to ping me with any questions/comments.

Thanks,

Jesse
IRC: odyssey4me

[1]
http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-02-04-16.04.html
[2]
https://www.eventbrite.com/e/openstack-ansible-mid-cycle-tickets-20966167371
[3] https://etherpad.openstack.org/p/openstack-ansible-mitaka-midcycle
__
OpenStack Development Mailing 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] [OpenStack-Ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

We've finalised the arrangements for the Mid Cycle sprint.

Given that the Ops Mid Cycle [1] is in the UK (15-16 Feb) and AnsibleFest
[2] is also in the UK (18 Feb), Rackspace has offered to host the Mid Cycle
sprint at their offices in Hayes (West London) on 17 Feb from 8am to 6pm.

The Ops Mid Cycle organisers have also graciously offered for us to be a
part of the Ops Mid Cycle agenda. I would like as many of us as possible to
play a part in the Ops Mid Cycle - listening, learning and contributing
where possible. As such, I'd like us to limit the number of sessions we
have within the Ops Mid Cycle. Let's have a few open design-style sessions.

I've setup an Etherpad [3] to gather proposals for Fishbowl Sessions (at
the Ops Mid Cycle) and Work Sessions (for 17 Feb). Please add any sessions
you'd like to facilitate/moderate. If there are sessions there, then please
feel free to add your +1 to show that you'd like to see it.

Given that we have limited space for the Mid Cycle, and we need to make
arrangements for access and connectivity, we need to collect an attendance
register. To facilitate this we've setup an event on Eventbrite [4]. For
those intending to come to the Mid Cycle, please ensure that you get a
ticket ASAP!

For those who need to arrange accommodation I would recommend staying in
Ealing Broadway - it's located between the Rackspace Office and London
city, so it'll give you relatively easy access to amenities as well as the
events.

[1] https://etherpad.openstack.org/p/MAN-ops-meetup
[2] http://www.ansible.com/ansiblefest
[3] https://etherpad.openstack.org/p/openstack-ansible-mitaka-midcycle
[4]
https://www.eventbrite.com/e/openstack-ansible-mid-cycle-tickets-20966167371

If I've forgotten anything, please feel free to contact me via the ML or
privately via email or IRC.

Thanks,

Jesse
IRC: odyssey4me
__
OpenStack Development Mailing 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] [ansible] tox functional testing rename

[Jesse Pretorius]

On 20 December 2015 at 19:24, Paul Belanger  wrote:
>
>
> I've proposed a series of patches[1] to rename tox -eansible-functional to
> tox -efunctional. While the change is trival, it is meant to workaround an
> interpreter issue with tox[2]. Additionally, the change brings our tox.ini
> inline with other OpenStack projects launching functional tests from tox.
>
>
Thanks for doing 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

Re: [openstack-dev] [openstack-ansible][designate] Regarding Designate install through Openstack-Ansible

[Jesse Pretorius]

Hi Swati,

You're making good progress!

I've reviewed 1 and it looks right.
With regards to 2, it seems that according to [1] you need to run
'designate-manage database sync' after setting up the database. We have a
similar pattern in [2] which you can model from.

With regards to 4, the task 'Get Modern PIP using fallback URL' should
never fail, so something is wrong there. Did you confirm that the container
actually does have access to the internet (via a ping or something)? If so,
did you confirm that it's not an MTU issue which is causing dropped
packets? Alternatively it could also be that your lxc-net is using the same
internal IP range as something in the path of traffic from the container to
the internet.

[1]
http://docs.openstack.org/developer/designate/getting-started.html#initialize-start-the-central-service
[2]
https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_cinder/tasks/cinder_db_setup.yml

On 28 December 2015 at 10:49, Sharma Swati6 <sharma.swa...@tcs.com> wrote:

>
> Hi All,
>
> Thanks alot for your valuable feedback Jesse.
>
> *Point 1 :*
>
> I have made the appropriate Designate entry in the file here :*
> /playbooks/defaults/repo_packages/openstack_services.yml* and uploaded it
> for review here :
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/defaults/repo_packages/openstack_services.yml
> Here, I have taken the* 'designate_git_install_branch:'* as the most
> recent one on '17.12.2015'
>
>
>
> *Point 2 :*The execution of tasks and handlers is very well explained in
> your answer. Thanks for that :)
>
>
>
> *Point 3 :*With regards to creating a DB user & DB, I have modeled the
> file from glance and placed it here:
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/designate_db_setup.yml
>
>
>
> *Point 4 :*I also raised that I am facing an error while running the
> playbook, for which I have pasted the results at
> http://paste.openstack.org/show/482171/ . On IRC, Jesse 
> recommended to attach the designate container first and check the internet
> connection.
> I did attach the new designate_container and pinged some address for the
> connectivity check. This works fine here, but I get the same error while
> running playbook.
> *Any other probable cause? *
>
> Once this is done, I will checkout the next step suggested by Jesse, i.e.
> to see the designate service in the Keystone service catalog and  interact
> with it via the CLI?
>
> Please share your suggestions.
>
> Thanks & Regards
> Swati Sharma
> System Engineer
> Tata Consultancy Services
> Mailto: sharma.swa...@tcs.com
> Website: http://www.tcs.com
> ____
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Jesse Pretorius <jesse.pretor...@gmail.com> wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: Jesse Pretorius <jesse.pretor...@gmail.com>
> Date: 12/17/2015 04:35PM
> Cc: pandey.pree...@tcs.com, Partha Datta <partha.da...@tcs.com>
> Subject: Re: [openstack-dev] Regarding Designate install through
> Openstack-Ansible
>
> Hi Swati,
>
> It looks like you're doing well so far! In addition to my review feedback
> via IRC, let me try to answer your questions.
>
> The directory containing the files which hold the SHA's is here:
>
> https://github.com/openstack/openstack-ansible/tree/master/playbooks/defaults/repo_packages
>
> Considering that Designate is an OpenStack Service, the appropriate
> entries should be added into this file:
>
> https://github.com/openstack/openstack-ansible/blob/master/playbooks/defaults/repo_packages/openstack_services.yml
>
> The order of the services is generally alphabetic, so Designate should be
> added after Cinder and before Glance.
>
> I'm not sure I understand your second question, but let me try and respond
> with what I think you're asking. Assuming a running system with all the
> other components, and an available container for Designate, the workflow
> will be:
>
> 1 - you execute the os-designate-install.yml playbook.
> 2 - Ansible executes the pre-tasks, then the role at
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/os-designate-install.yml#L64
> 3 - Ansible then executes
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/main.yml
> 4 - Handlers are triggered when you notify them, for example:
> https://github.com/sharmaswati6/designate_files/blob/master/playbooks/roles/os_designate/tasks/designate

Re: [openstack-dev] [openstack-ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

Thank you all for responding and giving your feedback.

Given that the Ops Mid Cycle [1] is in the UK (15-16 Feb) and AnsibleFest
[2] is also in the UK (18 Feb), and also that everyone seems ok with the UK
as a location for the mid cycle then we shall have it in the UK!

The Ops Mid Cycle organisers have also graciously offered for us to be a
part of the Ops Mid Cycle agenda. I would like as many of us as possible to
play a part in the Ops Mid Cycle - listening, learning and contributing
where possible. As such, I'd like us to limit the number of sessions we
have within the Ops Mid Cycle. Let's have a few open design-style sessions.

Thereafter, as discussed in today's community meeting [3], we can break
down into work sessions where we can work on specific goals. This will
happen on the Wednesday 17 Feb and we will be hosted at the Rackspace
offices in Hayes (West London).

I've setup an Etherpad [4] to gather proposals for Fishbowl Sessions (at
the Ops Mid Cycle) and Work Sessions (for 17 Feb). Please add any sessions
you'd like to facilitate/moderate. If there are sessions there, then please
feel free to add your +1 to show that you'd like to see it.

As discussed in the meeting today [3] I'm on holiday until the New Year.
Please all have a wonderful time over the year's end and I'll see you all
bright-eyed and bushy tailed next year!

Best regards,

Jesse
IRC: odyssey4me

[1] https://etherpad.openstack.org/p/MAN-ops-meetup
[2] http://www.ansible.com/ansiblefest
[3]
http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2015/openstack_ansible_meeting.2015-12-17-16.01.log.html
[4] https://etherpad.openstack.org/p/openstack-ansible-mitaka-midcycle
__
OpenStack Development Mailing 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] Regarding Designate install through Openstack-Ansible

[Jesse Pretorius]

tions
> Consulting
> 
>
>
> -Sharma Swati6/DEL/TCS wrote: -
> To: ma...@mhtx.net, jean-phili...@evrard.me,
> jesse.pretor...@rackspace.co.uk, kevin.car...@rackspace.com
> From: Sharma Swati6/DEL/TCS
> Date: 12/08/2015 01:56PM
> Cc: openstack-dev@lists.openstack.org, Partha Datta/DEL/TCS@TCS,
> pandey.pree...@tcsin.com
> Subject: Regarding Designate install through Openstack-Ansible
>
> Hi *Major, Jean, Jesse and Kevin,*
>
> Hope you are all doing well.
>
> I have been interacting with you lately on openstack mailing lists and IRC
> chats regarding *Designate component inclusion in Openstack-Ansible*, so
> that its deployment can be made similar to other components.
>
> As recommended, I have opened a *spec* also at :
> https://review.openstack.org/#/c/254161/ and uploaded the sample
> *designate.yml* file at
> https://github.com/prpandey26/Designate/blob/master/designate.yml#L3.
>
> To proceed with the configuration and role setup, I have the following
> queries-
>
>1. I believe for making the starting the initial setup, only conf.d
>and env.d needs to be altered. *In env.d, I edited the designate.yml
>file, then in conf.d, what host changes exactly I need to make for
>designate component?*
>2. Jean suggested that "after making changes in env.d and conf.d,
>ansible will create the new entries for your component". *Do I have to
>run anything for this? At what location will the new entries be created? Is
>it with respect to the roles for designate automatically created?*
>3. As a next step, I am planning to add role directories for designate
>component *'os-designate-yml' file in
>'/opt/openstack-ansible/playbooks'* and a seperate roles directory for 
> *'os-designate'
>at '/opt/openstack-ansible/playbooks/roles'.* *Can you please let me
>know if this has to be created by us or env.d and conf.d will directly
>created it?*
>
> I have not seen any document yet for the extra-containers to be added to
> openstack-ansible, however I checked only specs have been created for
> ironic, trove, etc.
>
> Hence, any help from you regarding the steps in sequence will be highly
> appreciated.
>
>
> Thanks & Regards
> Swati Sharma
> System Engineer
> Tata Consultancy Services
> Mailto: sharma.swa...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Major Hayden <ma...@mhtx.net> wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: Major Hayden <ma...@mhtx.net>
> Date: 12/04/2015 06:53PM
> Subject: Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible
>
> On Fri, 2015-12-04 at 10:01 +0530, Sharma Swati6 wrote:
> > To add a new container, we have followed the steps as mentioned in
> > the extra_container.yml.example. Please find the sample designate.yml
> > file attached and created as per the steps.
>
> That's a good start.  However, you'll need to sign up[1] to be an
> OpenStack developer (agreeing to some contracts and things so you can
> commit this into the upstream repositories.
>
> Once you do that, you'll want to assemble a spec for the changes you
> want to make.  A spec defines what you hope to accomplish and gives
> everyone on the project a chance to review the steps you're planning to
> take.  You can look at a spec I wrote[2] for ideas and then use the
> openstack-ansible-specs template[3] to begin working on your spec.
>
> A spec isn't busywork -- it shows the intention of what you're trying
> to do and allows other people on the project to point out areas of
> concern and improvement.
>
> > To add the new roles in openstack-ansible repository, shall I create
> > the directory looking at what is there for keystone or other
> > components and make the configuration changes only, or can I clone it
> > from somewhere also?
>
> There is a push lately to use independent role repositories, but I'm
> not sure if that's a hard requirement at the moment.  Jesse Pretorius
> or Kevin Carter may be better people to talk about that in this thread.
>
> Details on independent role repositories are in a spec[4] as well.
>
> > Thereafter, as suggested by you, I have to test this new container
> > with the existing ones.
> >
> > I believe there is no such link available with such steps and 'how
> > to' part for openstack-ansible. Please let me know if you/anyone else
&g

[openstack-dev] [openstack-ansible] Mid Cycle Sprint

[Jesse Pretorius]

Hi everyone,

At the Mitaka design summit in Tokyo we had some corridor discussions about
doing a mid-cycle meetup for the purpose of continuing some design
discussions and doing some specific sprint work.

***
I'd like indications of who would like to attend and what
locations/dates/topics/sprints would be of interest to you.
***

For guidance/background I've put some notes together below:

Location

We have contributors, deployers and downstream consumers across the globe
so picking a venue is difficult. Rackspace have facilities in the UK
(Hayes, West London) and in the US (San Antonio) and are happy for us to
make use of them.

Dates
-
Most of the mid-cycles for upstream OpenStack projects are being held in
January. The Operators mid-cycle is on February 15-16.

As I feel that it's important that we're all as involved as possible in
these events, I would suggest that we schedule ours after the Operators
mid-cycle.

It strikes me that it may be useful to do our mid-cycle immediately after
the Ops mid-cycle, and do it in the UK. This may help to optimise travel
for many of us.

Format
--
The format of the summit is really for us to choose, but typically they're
formatted along the lines of something like this:

Day 1: Big group discussions similar in format to sessions at the design
summit.

Day 2: Collaborative code reviews, usually performed on a projector, where
the goal is to merge things that day (if a review needs more than a single
iteration, we skip it. If a review needs small revisions, we do them on the
spot).

Day 3: Small group / pair programming.

Topics
--
Some topics/sprints that come to mind that we could explore/do are:
 - Install Guide Documentation Improvement [1]
 - Development Documentation Improvement (best practises, testing, how to
develop a new role, etc)
 - Upgrade Framework [2]
 - Multi-OS Support [3]

[1] https://etherpad.openstack.org/p/oa-install-docs
[2] https://etherpad.openstack.org/p/openstack-ansible-upgrade-framework
[3] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] Regarding Designate install through Openstack-Ansible

[Jesse Pretorius]

On 8 December 2015 at 08:26, Sharma Swati6  wrote:

> Hi *Major, Jean, Jesse and Kevin,*


Howdy!


> I have been interacting with you lately on openstack mailing lists and IRC
> chats regarding *Designate component inclusion in Openstack-Ansible*, so
> that its deployment can be made similar to other components.
>
> As recommended, I have opened a *spec* also at :
> https://review.openstack.org/#/c/254161/ and uploaded the sample
> *designate.yml* file at
> https://github.com/prpandey26/Designate/blob/master/designate.yml#L3.
>

This is just the beginning, but thank you for getting started!


> To proceed with the configuration and role setup, I have the following
> queries-
>
>1. I believe for making the starting the initial setup, only conf.d
>and env.d needs to be altered. *In env.d, I edited the designate.yml
>file, then in conf.d, what host changes exactly I need to make for
>designate component?*
>
>
>1. Jean suggested that "after making changes in env.d and conf.d,
>ansible will create the new entries for your component". *Do I have to
>run anything for this? At what location will the new entries be created? Is
>it with respect to the roles for designate automatically created?*
>2. As a next step, I am planning to add role directories for designate
>component *'os-designate-yml' file in
>'/opt/openstack-ansible/playbooks'* and a seperate roles directory for 
> *'os-designate'
>at '/opt/openstack-ansible/playbooks/roles'.* *Can you please let me
>know if this has to be created by us or env.d and conf.d will directly
>created it?*
>
> I have not seen any document yet for the extra-containers to be added to
> openstack-ansible, however I checked only specs have been created for
> ironic, trove, etc.
>

It seems that you've misunderstood, so let me try and make this clear.

No code will be created for you. The creation of the role to deploy and
configure Designate will need to be created and developed by you. The
playbook to execute the role will need to be created and developed by you.
The environment group/container spec (env.d) and the assignment of a host
to the group (conf.d) will need to be done by you.
The only thing that will be done automatically is the creation of the
container with a base OS - and this will be based on your env.d/conf.d
files.

We've been discussing these details with you today on IRC [1] and I hope
that all your questions, for now, have been adequately answered. If not,
please feel free to ask more!

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2015-12-08.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Random ssh errors in gate check jobs

[Jesse Pretorius]

On 23 November 2015 at 01:36, Major Hayden  wrote:

> Hey folks,
>
> Some of my recent reviews have been frequent fliers in the land of CI gate
> jobs and I've spent a fair amount of time diagnosing random ssh failures to
> containers in AIO builds.  The error I get most often is this:
>
> SSH Error: data could not be sent to the remote host. Make sure this
> host can be reached over ssh
>
> After digging in Ansible code for a bit, I found the error within the ssh
> connection plugin[1].  It looks like an issue where the ssh connection is
> actually open but data cannot be sent to the subprocess.
>
> I messed around heavily with multiplexing, keys, GSSAPI, and more, but the
> errors randomly appear.  I've proposed a review[2] for a switch to paramiko
> transport mode for gate jobs only and it has run four times without ssh
> errors (although two builds had timeouts due to the repo build taking too
> long).
>
> The fifth build is running now and it seems to be moving along fairly
> quickly.
>
> [1]
> https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L245-L260
> [2] https://review.openstack.org/#/c/248361/


Thanks for digging into this Major. It is a royal pain and will likely be
resolved with the release of Ansible 2, but for now we're stuck with having
to work around the issue with what we have.

I wonder, is there a difference in results or performance between using
paramiko or turning ssh pipelining off?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

[Jesse Pretorius]

On 19 November 2015 at 09:43, Thierry Carrez  wrote:

>
> So we have three models. The release:independent model is for projects
> that don't follow the common development cycle, and therefore won't make
> a "liberty" release. The release:cycle-with-milestones model is the
> traditional "one release at the end of the cycle" model, and the
> release:cycle-with-intermediary model is an hybrid where you follow the
> development cycle (and make an end-of-cycle release) but can still make
> intermediary, featureful releases as necessary.
>

Hmm, then it seems to me that OpenStack-Ansible should be tagged
'release:cycle-with-intermediary' instead of 'release:independent' - is
that correct?


> Looking at your specific case, it appears you could adopt the
> release:cycle-with-intermediary model, since you want to maintain a
> branch mapped to a given release. The main issue is your (a) point,
> especially the "much later" point. Liberty is in the past now, so making
> "liberty" releases now that we are deep in the Mitaka cycle is a bit
> weird.
>

The deployment projects, and probably packaging projects too, are faced
with the same issue. There's no guarantee that their x release will be done
on the same day as the OpenStack services release their x branches as the
deployment projects still need some time to verify stability and
functionality once the services are finalised. While it could be easily
said that we simply create the branch, then backport any fixes, this is not
necessarily ideal as it creates an additional review burden and doesn't
really match how the stable branches are meant to operate according to the
policy.


> Maybe we need a new model to care for such downstream projects when they
> can't release in relative sync with the projects they track.
>

Perhaps. Or perhaps the rules can be relaxed for a specific profile of
projects (non core?).
__
OpenStack Development Mailing 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] [openstack-ansible] Documentation update planning

[Jesse Pretorius]

Hi everyone,

In the community meeting [1] this week we'll be having a facilitated
discussion with regards to documentation improvements for OpenStack-Ansible.

If you have any feedback you'd like considered, would like to be part of
the conversation, or are keen to contribute then please add to the etherpad
[2], respond to this email and ideally be in the meeting. :)

[1]
https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
[2] https://etherpad.openstack.org/p/oa-install-docs

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] [openstack-ansible] Fedora/CentOS/other Support

[Jesse Pretorius]

Hi everyone,

There has been interest expressed from various corners to support more than
just Ubuntu in OpenStack-Ansible. While the project is very happy to work
on this, no-one has yet stepped up to take a lead role in the execution of
this work.

The current community has done some research into appropriate patterns to
use and has a general idea of how to do it - but in order to actually
execute there need to be enough people who commit to actually maintaining
the work once it's done. We don't want to carry the extra code if we don't
also pick up extra contributors to maintain the code.

If you're interested in seeing this become a reality and are prepared to
commit some time to making it happen, the project will be happy to work
with you to achieve it.

In this week's community meeting [1] we'll initiate a discussion on the
topic with the purpose of determining who's on board with the work.

In the following week's community meeting we will have a work breakdown
discussion where we'll work on filling out an etherpad [2] with what we
need to get done and who will be doing it. Naturally the etherpad can be
populated already by anyone who's interested. If you're actually happy to
volunteer to assist with the work, please feel free to add a note to that
effect on the etherpad.

[1]
https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
[2] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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] [openstack-ansible] Mitaka Summit Summary

[Jesse Pretorius]

Hi everyone,

I've put together some thoughts based on the Mitaka Summit from the
OpenStack-Ansible point of view:
http://odyssey4me.github.io/openstack/ansible/mitaka/summit/2015/11/17/mitaka-summit.html

Please feel free to ping me with any feedback!

Thanks,

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

Re: [openstack-dev] [openstack-ansible][security] Next steps: openstack-ansible-security

[Jesse Pretorius]

On 9 November 2015 at 19:38, Major Hayden  wrote:

>
> What would you propose as the final steps to get the blueprint marked as
> completed?  Should documentation be added into openstack-ansible about
> integrating openstack-ansible-security or should a script be provided for
> quicker integration?
>

Based on the spec's proposed change section [1] I would say that items 4 &
5 are the next steps. Those steps, however, are kind-of waiting for the
gate split work. Perhaps the best way to get this done that doesn't have
the dependency is to implement an additional option for gate-check-commit
option to turn on using the security role, but leave it off by default. The
current job will then continue to run and we can add an additional gate
check to run it with the security bits on as a comparison.

[1]
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html#proposed-change
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Converting the AIO bootstrap script to Ansible

[Jesse Pretorius]

On 6 November 2015 at 21:34, Major Hayden  wrote:

> Feel free to critique it and I'll get to work on making the changes.  The
> spec[2] should answer most of the questions about the effort.
>
> Thanks! :)
>
> [1] https://review.openstack.org/#/c/239525/
> [2]
> http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/convert-aio-bootstrap-to-ansible.html


This is excellent work, thanks Major!
__
OpenStack Development Mailing 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] [stable][all] Keeping Juno "alive" for longer.

[Jesse Pretorius]

On 9 November 2015 at 14:42, Sean Dague  wrote:

>
> So lets figure out where the snags are. I'm pretty uninterested in
> threads that just scream LTS without a list of upgrade bugs that have
> been filed to describe why rapid upgrade isn't the right long term
> solution.


I agree with this wholeheartedly. Simpler, more reliable and more online
upgrades are the targeted solution.

As adoption of OpenStack grows, distributors are going to have to play a
much larger role in driving their own end-user concerns by committing their
own resources to make those concerns become a reality.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] Next steps: openstack-ansible-security

[Jesse Pretorius]

On Friday, 6 November 2015, Major Hayden <ma...@mhtx.net> wrote:
>
> At this moment, openstack-ansible-security[1] is feature complete and all
> of the Ansible tasks and documentation for the STIGs are merged.  Exciting!


Excellent work, thank you!


> I've done lots of work to ensure that the role uses sane defaults so that
> it can be applied to the majority of OpenStack deployments without
> disrupting services.  It only supports Ubuntu 14.04 for now, but that's
> openstack-ansible's supported platform as well.


We're on a trajectory to get other platforms supported too, so I think that
work in this regards may as well get going. If there are parties interested
in adding role support for Fedora, Gentoo and others then I'd say that it
should be spec'd and can go ahead!


> I'd like to start by adding it to the gate-check-commit.sh script so that
> the security configurations are applied prior to running tempest.


While I applaud the idea, changing the current commit integration test is
probably not the best approach. We're in the middle of splitting the roles
out into their own repositories and also extending the gate checks into
multiple use-cases.

I think that the best option for now will be to add the implementation of
the security role as an additional use-case. Depending on the results there
we can figure out whether the role should be a default in all use cases.


-- 
Jesse Pretorius
mobile: +44 7586 906045
email: jesse.pretor...@gmail.com
skype: jesse.pretorius
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev