Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO

[Juan Antonio Osorio Robles]

+1 on making him tripleo-ci core.


Great work!

On 11/15/18 5:50 PM, Sagi Shnaidman wrote:
> Hi,
> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO.
> Quique is actively involved in improvements and development of TripleO
> and TripleO CI. He also helps in other projects including but not
> limited to Infrastructure.
> He shows a very good understanding how TripleO and CI works and I'd
> like suggest him as core reviewer of TripleO in CI related code.
>
> Please vote!
> My +1 is here :)
>
> Thanks
> -- 
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] No meeting next week for the security squad

[Juan Antonio Osorio Robles]

There will be no meeting for the security squad next Tuesday 13th of November 
since there's the
OpenStack summit.


Best Regards


__
OpenStack Development Mailing 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] [TripleO] No weekly meeting next week

[Juan Antonio Osorio Robles]

There will be no meeting next Tuesday 13th of November since there's the
OpenStack summit.


Best Regards


__
OpenStack Development Mailing 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] [tripleo] CI is broken

[Juan Antonio Osorio Robles]

Hello folks,


Please do not attempt to merge or recheck patches until we get this
sorted out.

We are dealing with several issues that have broken all jobs.

https://bugs.launchpad.net/tripleo/+bug/1801769
https://bugs.launchpad.net/tripleo/+bug/1801969
https://bugs.launchpad.net/tripleo/+bug/1802083
https://bugs.launchpad.net/tripleo/+bug/1802085

Best Regards!


__
OpenStack Development Mailing 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] PSA lets use deploy_steps_tasks

[Juan Antonio Osorio Robles]

Thanks! We have been slow to update our docs. I did put up a blog post
about these sections of the templates [1], in case folks find that useful.


[1] http://jaormx.github.io/2018/dissecting-tripleo-service-templates-p2/

On 11/2/18 3:39 PM, Dan Prince wrote:
> I pushed a patch[1] to update our containerized deployment
> architecture docs yesterday. There are 2 new fairly useful sections we
> can leverage with TripleO's stepwise deployment. They appear to be
> used somewhat sparingly so I wanted to get the word out.
>
> The first is 'deploy_steps_tasks' which gives you a means to run
> Ansible snippets on each node/role in a stepwise fashion during
> deployment. Previously it was only possible to execute puppet or
> docker commands where as now that we have deploy_steps_tasks we can
> execute ad-hoc ansible in the same manner.
>
> The second is 'external_deploy_tasks' which allows you to use run
> Ansible snippets on the Undercloud during stepwise deployment. This is
> probably most useful for driving an external installer but might also
> help with some complex tasks that need to originate from a single
> Ansible client.
>
> The only downside I see to these approaches is that both appear to be
> implemented with Ansible's default linear strategy. I saw shardy's
> comment here [2] that the :free strategy does not yet apparently work
> with the any_errors_fatal option. Perhaps we can reach out to someone
> in the Ansible community in this regard to improve running these
> things in parallel like TripleO used to work with Heat agents.
>
> This is also how host_prep_tasks is implemented which BTW we should
> now get rid of as a duplicate architectural step since we have
> deploy_steps_tasks anyway.
>
> [1] https://review.openstack.org/#/c/614822/
> [2] 
> http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/common/deploy-steps.j2#n554
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Juan Antonio Osorio Robles]

On 10/19/18 8:04 PM, Alex Schultz wrote:
> On Fri, Oct 19, 2018 at 10:53 AM James Slagle  wrote:
>> On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz  wrote:
>>> Additionally I took a stab at combining the puppet/docker service
>>> definitions for the aodh services in a similar structure to start
>>> reducing the overhead we've had from maintaining the docker/puppet
>>> implementations seperately.  You can see the patch
>>> https://review.openstack.org/#/c/611188/ for an additional example of
>>> this.
>> That patch takes the approach of removing baremetal support. Is that
>> what we agreed to do?
>>
> Since it's deprecated since Queens[0], yes? I think it is time to stop
> continuing this method of installation.  Given that I'm not even sure
> the upgrade process even works anymore with baremetal, I don't think
> there's a reason to keep it as it directly impacts the time it takes
> to perform deployments and also contributes to increased complexity
> all around.
>
> [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
As an advantage to removing baremetal support, our nested stack usage
would be a little lighter and this might actually help out deployment
times and resource usage. I like the idea of going ahead and starting to
flatten the stacks for our services.
>
>> I'm not specifically opposed, as I'm pretty sure the baremetal
>> implementations are no longer tested anywhere, but I know that Dan had
>> some concerns about that last time around.
>>
>> The alternative we discussed was using jinja2 to include common
>> data/tasks in both the puppet/docker/ansible implementations. That
>> would also result in reducing the number of Heat resources in these
>> stacks and hopefully reduce the amount of time it takes to
>> create/update the ServiceChain stacks.
>>
> I'd rather we officially get rid of the one of the two methods and
> converge on a single method without increasing the complexity via
> jinja to continue to support both. If there's an improvement to be had
> after we've converged on a single structure for including the base
> bits, maybe we could do that then?
>
> Thanks,
> -Alex
>
>> --
>> -- James Slagle
>> --
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [tripleo] Proposing Bob Fournier as core reviewer

[Juan Antonio Osorio Robles]

Hello!


I would like to propose Bob Fournier (bfournie) as a core reviewer in
TripleO. His patches and reviews have spanned quite a wide range in our
project, his reviews show great insight and quality and I think he would
be a addition to the core team.

What do you folks think?


Best Regards



__
OpenStack Development Mailing 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] [tripleo] PTL out of office

[Juan Antonio Osorio Robles]

Hi all!

I'll be out starting from Oct 15th, coming back on Oct 19th.]
The upstream meeting will be led by Alex Schultz (mwhahaha).

Best Regards


__
OpenStack Development Mailing 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] [tripleo] Clearing up the gate

[Juan Antonio Osorio Robles]

We've been having a lot of timeouts and the gate is stacking up. I'm
purging out patches from the gate in order to reduce used resources
while this is sorted out.

Please do not merge patches until this issue is sorted out.


BR


__
OpenStack Development Mailing 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] Regarding dropping Ocata related jobs from TripleO

[Juan Antonio Osorio Robles]

On 09/14/2018 09:01 AM, Alex Schultz wrote:
> On Fri, Sep 14, 2018 at 6:37 AM, Chandan kumar  wrote:
>> Hello,
>>
>> As Ocata release is already EOL on 27-08-2018 [1].
>> In TripleO, we are running Ocata jobs in TripleO CI and in promotion 
>> pipelines.
>> Can we drop it all the jobs related to Ocata or do we need to keep some jobs
>> to support upgrades in CI?
>>
> I think unless there are any objections around upgrades, we can drop
> the promotion pipelines. It's likely that we'll also want to
> officially EOL the tripleo ocata branches.
sounds good to me.
> Thanks,
> -Alex
>
>> Links:
>> [1.] https://releases.openstack.org/
>>
>> Thanks,
>>
>> Chandan Kumar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [TripleO] Stein Forum @ Berlin Brainstorming

[Juan Antonio Osorio Robles]

Hey folks!

It's time to come up with topics to discuss on the forum in Berlin[1]!

There is an etherpad for us to bring up ideas:

https://etherpad.openstack.org/p/tripleo-forum-stein

We need to submit by September 12.

Here's is also the link to the wiki:

https://wiki.openstack.org/wiki/Forum/Berlin2018#Etherpads_from_Teams_and_Working_Groups

Best Regards


[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134336.html



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

[openstack-dev] [TripleO] Meeting cancelled

[Juan Antonio Osorio Robles]

Due to folks being at the Denver PTG (including myself) there won't be
the weekly meeting next week.


BR


__
OpenStack Development Mailing 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] [TripleO] Denver PTG Schedule

[Juan Antonio Osorio Robles]

Hello!


The Denver schedule is now available, still at the same link:
https://etherpad.openstack.org/p/tripleo-ptg-stein

And I also made a Google Calendar that folks can follow:
https://calendar.google.com/calendar?cid=MjdqZmUwNmN1dWhldDdjYm5vb3RvaGRyZTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

In case you would prefer another tool, I also attached the ical file.


See you next week!


BR

<>
__
OpenStack Development Mailing 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] fluentd logging status

[Juan Antonio Osorio Robles]

Logging is a topic that I think should get more love on the TripleO side.


On 08/24/2018 12:17 PM, Juan Badia Payno wrote:
> Recently, I did a little test regarding fluentd logging on the gates
> master[1], queens[2], pike [3]. I don't like the status of it, I'm
> still working on them, but basically there are quite a lot of
> misconfigured logs and some services that they are not configured at all.
>
> I think we need to put some effort on the logging. The purpose of this
> email is to point out that we need to do a little effort on the task.
>
> First of all, I think we need to enable fluentd on all the scenarios,
> as it is on the tests [1][2][3] commented on the beginning of the
> email. Once everything is ok and some automatic test regarding logging
> is done they can be disabled.
Wes, do you have an opinion about this? I think it would be a good idea
to avoid these types of regressions.
>
> I'd love not to create a new bug for every misconfigured/unconfigured
> service, but if requested to grab more attention on it, I will open it.
One bug to fix all this is fine, but we do need a public place to track
all the work that needs to be done. Lets reference that place on the
bug. Could be Trello or an etherpad, or whatever you want, it's up to you.
>
> The plan I have in mind is something like:
>  * Make an initial picture of what the fluentd/log status is (from
> pike upwards).
>  * Fix all misconfigured services. (designate,...)
>  * Add the non-configured services. (manila,...)
>  * Add an automated check to find a possible
> unconfigured/misconfigured problem.
>
> Any comments, doubts or questions are welcome
>
> Cheers,
> Juan
>
> [1] https://review.openstack.org/594836
> [2] https://review.openstack.org/594838
> [3] https://review.openstack.org/594840
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Tripleo] fluentd logging status

[Juan Antonio Osorio Robles]

Logging is a topic that I think should get more love on the TripleO side.


On 08/24/2018 12:17 PM, Juan Badia Payno wrote:
> Recently, I did a little test regarding fluentd logging on the gates
> master[1], queens[2], pike [3]. I don't like the status of it, I'm
> still working on them, but basically there are quite a lot of
> misconfigured logs and some services that they are not configured at all.
>
> I think we need to put some effort on the logging. The purpose of this
> email is to point out that we need to do a little effort on the task.
>
> First of all, I think we need to enable fluentd on all the scenarios,
> as it is on the tests [1][2][3] commented on the beginning of the
> email. Once everything is ok and some automatic test regarding logging
> is done they can be disabled.
Wes, do you have an opinion about this? I think it would be a good idea
to avoid these types of regressions.
>
> I'd love not to create a new bug for every misconfigured/unconfigured
> service, but if requested to grab more attention on it, I will open it.
One bug to fix all this is fine, but we do need a public place to track
all the work that needs to be done. Lets reference that place on the
bug. Could be Trello or an etherpad, or whatever you want, it's up to you.
>
> The plan I have in mind is something like:
>  * Make an initial picture of what the fluentd/log status is (from
> pike upwards).
>  * Fix all misconfigured services. (designate,...)
>  * Add the non-configured services. (manila,...)
>  * Add an automated check to find a possible
> unconfigured/misconfigured problem.
>
> Any comments, doubts or questions are welcome
>
> Cheers,
> Juan
>
> [1] https://review.openstack.org/594836
> [2] https://review.openstack.org/594838
> [3] https://review.openstack.org/594840
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo] PTG topics and agenda

[Juan Antonio Osorio Robles]

Thanks, merged the topics.


On 08/30/2018 07:10 PM, Giulio Fidente wrote:
> On 8/28/18 2:50 PM, Juan Antonio Osorio Robles wrote:
>> Hello folks!
>>
>>
>> With the PTG being quite soon, I just wanted to remind folks to add your
>> topics on the etherpad: https://etherpad.openstack.org/p/tripleo-ptg-stein
> thanks Juan,
>
> I think the Edge (line 53) and Split Control Plane (line 74) sessions
> can probably be merged into a single one.
>
> I'd be fine with James driving it, I think it'd be fine to discuss the
> "control plane updates" issue [1] in that same session.
>
> 1.
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.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] [keystone] [barbican] Keystone's use of Barbican ?

[Juan Antonio Osorio Robles]

FWIW, instead of barbican, castellan could be used as a key manager.


On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>
>
> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>
>> Is that what is being described here ? 
>> 
>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>
>>
>> This is a separate mechanism for storing secrets, not necessarily
>> passwords (although I agree the term credentials automatically makes
>> people assume passwords). This is used if consuming keystone's native
>> MFA implementation. For example, storing a shared secret between the
>> user and keystone that is provided as a additional authentication
>> method along with a username and password combination.
>>  
>
> Is there any interest or plans to potentially allow Keystone's
> credential store to use Barbican as a storage provider? Encryption
> already is better than nothing, but if you already have (or will be
> deploying) a proper secret store with a hardware backend (or at least
> hardware stored encryption keys) then it might make sense to throw
> that in Barbican.
>
> Or is this also too much of a chicken/egg problem? How safe is it to
> rely on Barbican availability for MFA secrets and auth?
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

[Juan Antonio Osorio Robles]

This is not the case. Barbican requires users and systems that use it to
use keystone for authentication. So keystone can't use Barbican for
this. Chicken and egg problem.


On 08/29/2018 08:08 PM, Waines, Greg wrote:
>
> My understanding is that Keystone can be configured to use Barbican to
> securely store user passwords.
>
> Is this true ?
>
>  
>
> If yes, is this the standard / recommended / upstream way to securely
> store Keystone user passwords ?
>
>  
>
> If yes, I can’t find any descriptions of this is configured ?
>
> Can someone provide some pointers ?
>
>  
>
> Greg.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] PTG topics and agenda

[Juan Antonio Osorio Robles]

Hello folks!


With the PTG being quite soon, I just wanted to remind folks to add your
topics on the etherpad: https://etherpad.openstack.org/p/tripleo-ptg-stein

Also, please vote for the topics you're the most interested in, so we
can add them to the agenda. I'll submit a potential agenda by the end of
the week.


Best Regards


__
OpenStack Development Mailing 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] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

[Juan Antonio Osorio]

We have a small project (novajoin) that still relies on unversioned
notifications. Thanks for the notification, I hope we can migrate to
versioned notifications by Stein.

On Thu, Aug 9, 2018 at 12:41 PM, Balázs Gibizer  wrote:

> Dear Nova notification consumers!
>
>
> The Nova team made progress with the new versioned notification interface
> [1] and it is almost reached feature parity [2] with the legacy,
> unversioned one. So Nova team will discuss on the upcoming PTG the
> deprecation of the legacy interface. There is a list of projects (we know
> of) consuming the legacy interface and we would like to know if any of
> these projects plan to switch over to the new interface in the foreseeable
> future so we can make a well informed decision about the deprecation.
>
>
> * Searchlight [3] - it is in maintenance mode so I guess the answer is no
> * Designate [4]
> * Telemetry [5]
> * Mistral [6]
> * Blazar [7]
> * Watcher [8] - it seems Watcher uses both legacy and versioned nova
> notifications
> * Masakari - I'm not sure Masakari depends on nova notifications or not
>
> Cheers,
> gibi
>
> [1] https://docs.openstack.org/nova/latest/reference/notifications.html
> [2] http://burndown.peermore.com/nova-notification/
>
> [3] https://github.com/openstack/searchlight/blob/master/searchl
> ight/elasticsearch/plugins/nova/notification_handler.py
> [4] https://github.com/openstack/designate/blob/master/designate
> /notification_handler/nova.py
> [5] https://github.com/openstack/ceilometer/blob/master/ceilomet
> er/pipeline/data/event_definitions.yaml#L2
> [6] https://github.com/openstack/mistral/blob/master/etc/event_d
> efinitions.yml.sample#L2
> [7] https://github.com/openstack/blazar/blob/5526ed1f9b74d23b588
> 1a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
> [8] https://github.com/openstack/watcher/blob/master/watcher/dec
> ision_engine/model/notification/nova.py#L335
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [oslo] proposing Moisés Guimarães for oslo.config core

[Juan Antonio Osorio]

Yeah! +1 Moisés has been doing a great job there

On Wed, 1 Aug 2018, 16:27 Doug Hellmann,  wrote:

> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
>
> Please indicate your approval or concerns with +1/-1.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] PTL candidacy for the Stein Cycle

[Juan Antonio Osorio]

Hello folks!

I'd like to nominate myself for the TripleO PTL role for the Stein cycle.

Alex has done a great job as a PTL: The project is progressing nicely with
many
new, exciting features and uses for TripleO coming to fruition recently.
It's a
great time for the project. But, there's more work to be done.

I have served the TripleO community as a core-reviewer for some years now
and,
more recently, by driving the Security Squad. This project has been a
great learning experience for me, both technically (I got to learn even
more of
OpenStack) and community-wise. Now I wish to better serve the community
further
by bringing my experiences into PTL role. While I have not yet served as PTL
for a project before,I'm eager to learn the ropes and help improve the
community that has been so influential on me.

For Stein, I would like to focus on:

* Increasing TripleO's usage in the testing of other projects
  Now that TripleO can deploy a standalone OpenStack installation, I hope it
  can be leveraged to add value to other projects' testing efforts. I hope
this
  would subsequentially help increase TripleO's testing coverage, and reduce
  the footprint required for full-deployment testing.

* Technical Debt & simplification
  We've been working on simplifying the deployment story and battle
technical
  depth -- let’s keep  this momentum going.  We've been running (mostly)
fully
  containerized environments for a couple of releases now; I hope we can
reduce
  the number of stacks we create, which would in turn simplify the project
  structure (at least on the t-h-t side). We should also aim for the most
  convergence we can achieve (e.g. CLI and UI workflows).

* CI and testing
  The project has made great progress regarding CI and testing; lets keep
this
  moving forward and get developers easier ways to bring up testing
  environments for them to work on and to be able to reproduce CI jobs.

Thanks!

Juan Antonio Osorio Robles
IRC: jaosorior


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)

[Juan Antonio Osorio]

 Sounds good to me. Even if pacemaker is heavier, less options and
consistency is better.

Greetings from Mexico :D

On Fri, 13 Jul 2018, 13:33 Emilien Macchi,  wrote:

> Greetings,
>
> We have been supporting both Keepalived and Pacemaker to handle VIP
> management.
> Keepalived is actually the tool used by the undercloud when SSL is enabled
> (for SSL termination).
> While Pacemaker is used on the overcloud to handle VIPs but also services
> HA.
>
> I see some benefits at removing support for keepalived and deploying
> Pacemaker by default:
> - pacemaker can be deployed on one node (we actually do it in CI), so can
> be deployed on the undercloud to handle VIPs and manage HA as well.
> - it'll allow to extend undercloud & standalone use cases to support
> multinode one day, with HA and SSL, like we already have on the overcloud.
> - it removes the complexity of managing two tools so we'll potentially
> removing code in TripleO.
> - of course since pacemaker features from overcloud would be usable in
> standalone environment, but also on the undercloud.
>
> There is probably some downside, the first one is I think Keepalived is
> much more lightweight than Pacemaker, we probably need to run some
> benchmark here and make sure we don't make the undercloud heavier than it
> is now.
>
> I went ahead and created this blueprint for Stein:
> https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default
> I also plan to prototype some basic code soon and provide an upgrade path
> if we accept this blueprint.
>
> This is something I would like to discuss here and at the PTG, feel free
> to bring questions/concerns,
> Thanks!
> --
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Novaclient redirect endpoint https into http

[Juan Antonio Osorio]

Are you using http_to_wsgi_middleware? Gotta enable that in the nova config
and make sure its in your paste config.

On Wed, 4 Jul 2018, 20:22 Nguyễn Trọng Tấn, 
wrote:

> Thanks you katynski for response.
>
> But, I had config Haproxy correctly. Here is my config:
> http://prntscr.com/k2ofwv
>
> And, when I use openstack command, that is successful. Here:
> http://prntscr.com/k2ogau
>
> I don’t think I config wrong. I can create, delete, list, show any VM with
> openstack command successfully.
>
>
>
> Thanks and Best Regards!
>
> Nguyen Trong Tan
>
> Openstack group user VietNam.
>
>
>
> -Original Message-
> From: Bogdan Katynski [mailto:bogdan.katyn...@workday.com]
> Sent: Wednesday, July 4, 2018 9:50 PM
> To: Nguyễn Trọng Tấn 
> Cc: openstack-operat...@lists.openstack.org; openstack@lists.openstack.org;
> Lê Quang Long (VDC-IT) 
> Subject: Re: [Openstack] Novaclient redirect endpoint https into http
>
>
> >
> > But, I can not use nova command, endpoint nova have been redirected from
> https to http. Here: http://prntscr.com/k2e8s6 (command: nova –insecure
> service list)
>
> First of all, it seems that the nova client is hitting /v2.1 instead of
> /v2.1/ URI and this seems to be triggering the redirect.
>
> Since openstack CLI works, I presume it must be using the correct URL and
> hence it’s not getting redirected.
>
> >
> > And this is error log: Unable to establish connection to
> http://192.168.30.70:8774/v2.1/: ('Connection aborted.',
> BadStatusLine("''",))
> >
>
> Looks to me that nova-api does a redirect to an absolute URL. I suspect
> SSL is terminated on the HAProxy and nova-api itself is configured without
> SSL so it redirects to an http URL.
>
> In my opinion, nova would be more load-balancer friendly if it used a
> relative URI in the redirect but that’s outside of the scope of this
> question and since I don’t know the context behind choosing the absolute
> URL, I could be wrong on that.
>
> I had a similar problem with heat-api running behind an Apache reverse
> proxy, and managed to resolve it by applying the workaround from this bug
> report:
>
> https://bugs.launchpad.net/python-heatclient/+bug/1420907
>
> Setting
>
> X-Forwarded-Proto: https
>
> before forwarding the request to heat-api fixed the issue for me.
>
> --
> Bogdan Katyński
> freenode: bodgix
>
>
>
>
>
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tripleo] 'overcloud deploy' doesn't restart haproxy (Pike)

[Juan Antonio Osorio]

It is unfortunately a known issue and is present in queens and master as
well. I think Michele (bandini on IRC) was working on it.

On Thu, 21 Jun 2018, 06:45 Lars Kellogg-Stedman,  wrote:

> I've noticed that when updating the overcloud with 'overcloud deploy',
> the deploy process does not restart the haproxy containers when there
> are changes to the haproxy configuration.
>
> Is this expected behavior?
>
> --
> Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] NEW weekly meeting time

[Juan Antonio Osorio]

+1 I dig

On Fri, 15 Jun 2018, 17:41 Dave McCowan (dmccowan), 
wrote:

> +1
> This is a great time.
>
> On 6/14/18, 4:30 PM, "Ade Lee"  wrote:
>
> >The new time slot has been pretty difficult for folks to attend.
> >I'd like to propose a new time slot, which will hopefully be more
> >amenable to everyone.
> >
> >Tuesday 12:00 UTC
> >
> >https://www.timeanddate.com/worldclock/fixedtime.html?hour=12=00
> >c=0
> >
> >This works out to 8 am EST, around 1pm in Europe, and 8 pm in China.
> >Please vote by responding to this email.
> >
> >Thanks,
> >Ade
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Security Squad meeting cancelled this week

[Juan Antonio Osorio]

Hello,

A lot of folks are in the OpenStack summit, so we'll cancel the Security
Squad meeting today.

BR

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [tripleo] Encrypted swift volumes by default in the undercloud

[Juan Antonio Osorio]

Hello!

As part of the work from the Security Squad, we added the ability for the
containerized undercloud to encrypt the overcloud plans. This is done by
enabling Swift's encrypted volumes, which require barbican. Right now it's
turned off, but I would like to enable it by default [1]. What do you folks
think?

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

BR

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Juan Antonio Osorio]

+1 :D hell yeah!

On Thu, 19 Apr 2018, 20:05 John Fulton,  wrote:

> +1
>
> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi 
> wrote:
> > Greetings,
> >
> > As you probably know mcornea on IRC, Marius Cornea has been contributing
> on
> > TripleO for a while, specially on the upgrade bits.
> > Part of the quality team, he's always testing real customer scenarios and
> > brings a lot of good feedback in his reviews, and quite often takes care
> of
> > fixing complex bugs when it comes to advanced upgrades scenarios.
> > He's very involved in tripleo-upgrade repository where he's already core,
> > but I think it's time to let him +2 on other tripleo repos for the
> patches
> > related to upgrades (we trust people's judgement for reviews).
> >
> > As usual, we'll vote!
> >
> > Thanks everyone for your feedback and thanks Marius for your hard work
> and
> > involvement in the project.
> > --
> > Emilien Macchi
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Tatu][Nova] Handling instance destruction

[Juan Antonio Osorio]

Having an interface for vendordata that gets deletes would be quite nice.
Right now for novajoin we listen to the nova notifications for updates and
deletes; if this could be handled natively by vendordata, it would simplify
our codebase.

BR

On Fri, Mar 16, 2018 at 7:34 AM, Michael Still <mi...@stillhq.com> wrote:

> Thanks for this. I read the README for the project after this and I do now
> realise you're using notifications for some of these events.
>
> I guess I'm still pondering if its reasonable to have everyone listen to
> notifications to build systems like these, or if we should messages to
> vendordata to handle these actions. Vendordata is intended at deployers, so
> having a simple and complete interface seems important.
>
> There were also comments in the README about wanting to change the data
> that appears in the metadata server over time. I'm wondering how that maps
> into the configdrive universe. Could you explain those comments a bit more
> please?
>
> Thanks for your quick reply,
> Michael
>
>
>
>
> On Fri, Mar 16, 2018 at 2:18 PM, Pino de Candia <
> giuseppe.decan...@gmail.com> wrote:
>
>> Hi Michael,
>>
>> Thanks for your message... and thanks for your vendordata work!
>>
>> About your question, Tatu listens to events on the oslo message bus.
>> Specifically, it reacts to compute.instance.delete.end by cleaning up
>> per-instance resources. It also listens to project creation and user role
>> assignment changes. The code is at:
>> https://github.com/openstack/tatu/blob/master/tatu/notifications.py
>>
>> best,
>> Pino
>>
>>
>> On Thu, Mar 15, 2018 at 3:42 PM, Michael Still <mi...@stillhq.com> wrote:
>>
>>> Heya,
>>>
>>> I've just stumbled across Tatu and the design presentation [1], and I am
>>> wondering how you handle cleaning up instances when they are deleted given
>>> that nova vendordata doesn't expose a "delete event".
>>>
>>> Specifically I'm wondering if we should add support for such an event to
>>> vendordata somehow, given I can now think of a couple of use cases for it.
>>>
>>> Thanks,
>>> Michael
>>>
>>> 1: https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Z
>>> i4EMvjl-3TKsBW20xEUyYHapfM/edit#slide=id.p
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] TLS by default

[Juan Antonio Osorio]

Correct, only public endpoints.

On Wed, Mar 14, 2018 at 1:52 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> Just to clarify: only for public endpoints, right? I don't think e.g.
> ironic-python-agent can talk to self-signed certificates yet.
>
>
> On 03/14/2018 07:03 AM, Juan Antonio Osorio wrote:
>
>> Hello,
>>
>> As part of the proposed changed by the Security Squad [1], we'd like the
>> deployment to use TLS by default.
>>
>> The first target is to get the undercloud to use it, so a patch has been
>> proposed recently [2] [3]. So, just wanted to give a heads up to people.
>>
>> This should be just fine from a quickstart/testing point of view, since
>> we explicitly set the value for autogenerating certificates in the
>> undercloud [4] [5].
>>
>> Note that there are also plans to change these defaults for the
>> containerized undercloud and the overcloud.
>>
>> BR
>>
>> [1] https://etherpad.openstack.org/p/tripleo-security-squad
>> [2] https://review.openstack.org/#/c/552382/
>> [3] https://review.openstack.org/552781
>> [4] https://github.com/openstack/tripleo-quickstart-extras/blob/
>> master/roles/extras-common/defaults/main.yml#L15
>> [5] https://github.com/openstack/tripleo-quickstart-extras/blob/
>> master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.com>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [tripleo] TLS by default

[Juan Antonio Osorio]

Hello,

As part of the proposed changed by the Security Squad [1], we'd like the
deployment to use TLS by default.

The first target is to get the undercloud to use it, so a patch has been
proposed recently [2] [3]. So, just wanted to give a heads up to people.

This should be just fine from a quickstart/testing point of view, since we
explicitly set the value for autogenerating certificates in the undercloud
[4] [5].

Note that there are also plans to change these defaults for the
containerized undercloud and the overcloud.

BR

[1] https://etherpad.openstack.org/p/tripleo-security-squad
[2] https://review.openstack.org/#/c/552382/
[3] https://review.openstack.org/552781
[4]
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/extras-common/defaults/main.yml#L15
[5]
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117
-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [tripleo] Proposing Security Squad

[Juan Antonio Osorio]

Hello!

As mentioned in the PTG, I would like to start a Security Squad for
TripleO, with the goal of working with the security aspects and challenges
in a more public manner.

We'll have our first meeting tomorrow. With weekly meetings every wednesday
at 1pm UTC.

We started an etherpad already
https://etherpad.openstack.org/p/tripleo-security-squad

And here's the patch adding the Security Squad to the list
https://review.openstack.org/#/c/550001/

Feel free to join if you're interested.

BR

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Draft schedule for PTG

[Juan Antonio Osorio]

Could we change the Security talk to a day before Friday (both Thursday and
Wednesday are fine)? Luke Hinds, the leader of the OpenStack Security group
would like to join that discussion, but is not able to join that day.

On Mon, Feb 19, 2018 at 6:37 PM, Emilien Macchi <emil...@redhat.com> wrote:

> Alex and I have been working on the agenda for next week, based on what
> people proposed in topics.
>
> The draft calendar is visible here:
> https://calendar.google.com/calendar/embed?src=tgpb5tv12mlu7kge5oqertje78%
> 40group.calendar.google.com=Europe%2FDublin
>
> Also you can import the ICS from:
> https://calendar.google.com/calendar/ical/tgpb5tv12mlu7kge5oqertje78%
> 40group.calendar.google.com/public/basic.ics
>
> Note this is a draft - we would love your feedback about the proposal.
>
> Some sessions might be too short or too long? You to tell us. (Please look
> at event details for descriptions).
> Also, for each session we need a "driver", please tell us if you volunteer
> to do it.
>
> Please let us know here and we'll make adjustment, we have plenty of room
> for it.
>
> Thanks!
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [castellan] Transferring ownership of secrets to another user

[Juan Antonio Osorio]

On 4 Jan 2018 23:35, "Alan Bishop"  wrote:

Has there been any previous discussion on providing a mechanism for
transferring ownership of a secret from one user to another?

For castellan there isn't a discussion AFAIK. But it sounds like something
you can enable with Barbican's ACLs.

https://docs.openstack.org/barbican/latest/api/reference/acls.html

You would need to leverage Barbican's API instead of castellan though.


Cinder supports the notion of transferring volume ownership to another
user, who may be in another tenant/project. However, if the volume is
encrypted it's possible (even likely) that the new owner will not be
able to access the encryption secret.

The new user will have the
encryption key ID (secret ref), but may not have permission to access
the secret, let alone delete the secret should the volume be deleted
later. This issue is currently flagged as a cinder bug [1].

This is a use case where the ownership of the encryption secret should
be transferred to the new volume owner.

Alan

[1] https://bugs.launchpad.net/cinder/+bug/1735285

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

Re: [openstack-dev] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

By using the ssl_overcloud flag in your configuration and setting it to
true.

On 6 Dec 2017 17:33, "Moshe Levi" <mosh...@mellanox.com> wrote:

> How do I tell quickstart to generate certs and enable tls?
>
>
>
> *From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
> *Sent:* Wednesday, December 6, 2017 5:24 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
> not determine a suitable URL for the plugin"
>
>
>
>
>
>
>
> On 6 Dec 2017 16:58, "Moshe Levi" <mosh...@mellanox.com> wrote:
>
> I have the access to 10.0.0.0 network
>
> I remove the
>
> -e /home/stack/enable-tls.yaml -e 
> ~/heat-templates/environments/tls-endpoints-public-ip.yaml
> -e /home/stack/inject-trust-anchor.yaml
>
> Form the ./overcloud-deploy.sh and now it working
>
> The issue you posted wasn't a TLS issue, but it might be that it was being
> hidden by nova. You could truly to access keystone directly and that will
> be more revealing.
>
>
>
> My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml
> were taken from
>
> wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
> master/test-environments/enable-tls.yaml
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopenstack-infra%2Ftripleo-ci%2Fmaster%2Ftest-environments%2Fenable-tls.yaml=02%7C01%7Cmoshele%40mellanox.com%7Cadfadec5a9aa40e0d56508d53cbd6053%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481706419069326=MBqec8H5KjiEIPJDT%2F1UxxBntYERIfT6EykQNKCIaIA%3D=0>
>
> wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
> master/test-environments/inject-trust-anchor.yaml
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopenstack-infra%2Ftripleo-ci%2Fmaster%2Ftest-environments%2Finject-trust-anchor.yaml=02%7C01%7Cmoshele%40mellanox.com%7Cadfadec5a9aa40e0d56508d53cbd6053%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481706419069326=SBRviDdKz1OGlrfqyDHVGPWvyKwz4eLxB%2BuxfCKIEj0%3D=0>
>
> This will only work if you use the exact same fixed IP as we use in CI. So
> i don't recommend using that. Rather generate your own certs or tell
> quickstart to do it for you by using the appropriate flag.
>
>
>
> So maybe the is an issue with tripleo or just these config files
>
>
>
> *From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
> *Sent:* Wednesday, December 6, 2017 12:36 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
> not determine a suitable URL for the plugin"
>
>
>
> From the node you're running the nova command, do you have access to the
> 10.0.0.0 network (external)?
>
>
>
> In virtual environments, quickstart will leave an
> overcloud-prep-network.sh script that will create a vlan interface that
> gives the undercloud access to that network. So, if it's a virtual
> environment and you're running that command from the undercloud (which from
> the log you sent it seems that's the case) you need to run that. Note that
> you need to run that every time you update your undercloud.
>
>
>
> BR
>
>
>
>
>
> On 6 Dec 2017 09:06, "Moshe Levi" <mosh...@mellanox.com> wrote:
>
> Hi all,
>
>
>
> We deploy tripleo master using quickstart.
>
> We this delorean repo:
>
> name=delorean
>
> baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/
> ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrunk.rdoproject.org%2Fcentos7-master%2Fac%2F82%2Fac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=R6s6CvAGGAB97GYgCsCsT%2BxU0PQ1fZ89xAuUQFM5tL8%3D=0>
>
>
>
> The undercloud and overcloud deployment were successfully, but we I try to
> run command on the overcloud
>
> I am getting the  keystone error "Could not determine a suitable URL for
> the plugin"
>
> See nova-list with debug info [1]
>
> Do you know how to resolve this? Help in troubleshooting this issue will
> be appreciated.
>
>
>
>
>
> [1]  http://paste.openstack.org/show/628240/
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.openstack.org%2Fshow%2F628240%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7C

Re: [openstack-dev] [tripleo] Proposing Wesley Hayutin core on TripleO CI

[Juan Antonio Osorio]

+1

On 6 Dec 2017 18:25, "Harry Rybacki"  wrote:

On Wed, Dec 6, 2017 at 11:19 AM, mathieu bultel  wrote:
> On 12/06/2017 04:45 PM, Emilien Macchi wrote:
>> Team,
>>
>> Wes has been consistently and heavily involved in TripleO CI work.
>> He has a very well understanding on how tripleo-quickstart and
>> tripleo-quickstart-extras work, his number and quality of reviews are
>> excellent so far. His experience with testing TripleO is more than
>> valuable.
>> Also, he's always here to help on TripleO CI issues or just
>> improvements (he's the guy filling bugs on a Saturday evening).
>> I think he would be a good addition to the TripleO CI core team
>> (tripleo-ci, t-q and t-q-e repos for now).
>> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
>> to move on and get you +2 ;-)
>>
>> As usual, it's open for voting, feel free to bring any feedback.
>> Thanks everyone,
>
> +1 of course
>
+1!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

On 6 Dec 2017 16:58, "Moshe Levi" <mosh...@mellanox.com> wrote:

I have the access to 10.0.0.0 network

I remove the

-e /home/stack/enable-tls.yaml -e
~/heat-templates/environments/tls-endpoints-public-ip.yaml
-e /home/stack/inject-trust-anchor.yaml

Form the ./overcloud-deploy.sh and now it working

The issue you posted wasn't a TLS issue, but it might be that it was being
hidden by nova. You could truly to access keystone directly and that will
be more revealing.



My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml
were taken from

wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
master/test-environments/enable-tls.yaml

wget https://raw.githubusercontent.com/openstack-infra/tripleo-ci/
master/test-environments/inject-trust-anchor.yaml

This will only work if you use the exact same fixed IP as we use in CI. So
i don't recommend using that. Rather generate your own certs or tell
quickstart to do it for you by using the appropriate flag.



So maybe the is an issue with tripleo or just these config files



*From:* Juan Antonio Osorio [mailto:jaosor...@gmail.com]
*Sent:* Wednesday, December 6, 2017 12:36 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [tripleo] overcloud keystone error "Could
not determine a suitable URL for the plugin"



>From the node you're running the nova command, do you have access to the
10.0.0.0 network (external)?



In virtual environments, quickstart will leave an overcloud-prep-network.sh
script that will create a vlan interface that gives the undercloud access
to that network. So, if it's a virtual environment and you're running that
command from the undercloud (which from the log you sent it seems that's
the case) you need to run that. Note that you need to run that every time
you update your undercloud.



BR





On 6 Dec 2017 09:06, "Moshe Levi" <mosh...@mellanox.com> wrote:

Hi all,



We deploy tripleo master using quickstart.

We this delorean repo:

name=delorean

baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/
ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrunk.rdoproject.org%2Fcentos7-master%2Fac%2F82%2Fac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=R6s6CvAGGAB97GYgCsCsT%2BxU0PQ1fZ89xAuUQFM5tL8%3D=0>



The undercloud and overcloud deployment were successfully, but we I try to
run command on the overcloud

I am getting the  keystone error "Could not determine a suitable URL for
the plugin"

See nova-list with debug info [1]

Do you know how to resolve this? Help in troubleshooting this issue will be
appreciated.





[1]  http://paste.openstack.org/show/628240/
<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.openstack.org%2Fshow%2F628240%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=o4nTXxk826W8ys1W1DvZUelSLS5uTT9McwazErh3wOY%3D=0>










__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=Zv8CbJlDuv3ZEiLbp%2BHX%2FQEqTDd%2Fndh4wd700hNdW8I%3D=0>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=T7Tc%2FtBAv1zl4X3TbTJIqQQ5ZW2PtSrvxVACYChEa40%3D=0>


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

Re: [openstack-dev] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Juan Antonio Osorio]

>From the node you're running the nova command, do you have access to the
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh
script that will create a vlan interface that gives the undercloud access
to that network. So, if it's a virtual environment and you're running that
command from the undercloud (which from the log you sent it seems that's
the case) you need to run that. Note that you need to run that every time
you update your undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi"  wrote:

Hi all,



We deploy tripleo master using quickstart.

We this delorean repo:

name=delorean

baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac
82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/



The undercloud and overcloud deployment were successfully, but we I try to
run command on the overcloud

I am getting the  keystone error "Could not determine a suitable URL for
the plugin"

See nova-list with debug info [1]

Do you know how to resolve this? Help in troubleshooting this issue will be
appreciated.





[1]  http://paste.openstack.org/show/628240/









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

Re: [openstack-dev] [tripleo] rename ovb jobs?

[Juan Antonio Osorio]

On Thu, Nov 30, 2017 at 9:11 PM, Emilien Macchi <emil...@redhat.com> wrote:

> A few months ago, we renamed ovb-updates to be
> tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024.
> The name is much longer but it describes better what it's doing.
> We know it's a job with one controller, one compute and one storage
> node, deploying the quickstart featureset n°24.
>
> For consistency, I propose that we rename all OVB jobs this way.
> For example, tripleo-ci-centos-7-ovb-ha-oooq would become
> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001
> etc.
>
Sounds reasonable. That would make it easier for me to check what's
actually in the featureset, as opposed to having to ask folks every time.

>
> Any thoughts / feedback before we proceed?
> Before someone asks, I'm not in favor of renaming the multinode
> scenarios now, because they became quite familiar now, and it would
> confuse people to rename the jobs.
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] IPSEC integration

[Juan Antonio Osorio]

On 21 Nov 2017 01:19, "Alex Schultz" <aschu...@redhat.com> wrote:

On Thu, Nov 16, 2017 at 12:01 AM, Juan Antonio Osorio
<jaosor...@gmail.com> wrote:
> Hello folks!
>
> A few months ago Dan Sneddon and me worked in an ansible role that would
> enable IPSEC for the overcloud [1]. Currently, one would run it as an
extra
> step after the overcloud deployment. But, I would like to start
integrating
> it to TripleO itself, making it another option, probably as a composable
> service.
>

Is there a spec for this or at least some more detail as to what
exactly this is solving?  I would really like some more explanation
around this feature than just an ansible role proposal.


Spec created https://blueprints.launchpad.net/tripleo/+spec/ipsec


> For this, I'm planning to move the tripleo-ipsec ansible role repository
> under the TripleO umbrella. Would that be fine with everyone? Or should I
> add this ansible role as part of another repository? After that's
available
> and packaged in RDO. I'll then look into the actual TripleO composable
> service.
>

As I've previously indicated it probably should live under the tripleo
umbrella but I would like to see more details around this prior to
further integration.  It's also very late in the cycle (almost m2) to
be proposing something like this. Is the target for this Rocky?

That being said I don't see anything specific to this role that would
cause problems as part of the deployment process as it exists today.
I do see some possible conflicts around the iptables configuration as
we currently manage that via heat/puppet but I think it's smart enough
to not stomp on each other if we carefully format the rules.  Another
implementation item that might be problematic is the more hard-coded
configuration via template files. What is the plan to make those more
dynamic to support other roles besides just compute/controller?


It's on the works. It shouldn't be a big change.

Right
now tripleo-heat-templates is the source of configuration items that
we expose for the deployment.  What would we be looking to expose to
deployers since what is currently exposed from the role is minimal?


I'm looking to get deployers to only need to enable it via an environment
variable. The rest should be automatic.



> Any input and contributions are welcome!
>
> [1] https://github.com/JAORMX/tripleo-ipsec
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>

Thanks,
-Alex

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

[openstack-dev] [TripleO] IPSEC integration

[Juan Antonio Osorio]

Hello folks!

A few months ago Dan Sneddon and me worked in an ansible role that would
enable IPSEC for the overcloud [1]. Currently, one would run it as an extra
step after the overcloud deployment. But, I would like to start integrating
it to TripleO itself, making it another option, probably as a composable
service.

For this, I'm planning to move the tripleo-ipsec ansible role repository
under the TripleO umbrella. Would that be fine with everyone? Or should I
add this ansible role as part of another repository? After that's available
and packaged in RDO. I'll then look into the actual TripleO composable
service.

Any input and contributions are welcome!

[1] https://github.com/JAORMX/tripleo-ipsec

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

On Thu, Nov 9, 2017 at 3:27 PM, David Gabriel <davidgab...@gmail.com> wrote:

> My objective is to create a stack using Heat.
> Initially, my code worked properly with http access but when our Openstack
> is updated the access is becoming via https so I got the errors I sent in
> the previous email.
> So I think I need to *authenticate *using the .pem certificate.
> But, I don't know where exactely (which location) I put the .pem file in
> order to be visible to the heatclient (or keystone) and how shall I update
> my code ?
>

I really suggest you ask your administrator what you should be doing.
Having TLS on the endpoint doesn't necessarily mean that you need to
authenticate. It could mean that all you need to do is trust the CA that
issued the certificate that Heat (or the load balancer) is serving publicly.



> I am confusing a little bit!
> Thanks in advance.
> Best regards.
>
> 2017-11-09 9:05 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>
>> Alright,
>>
>> So, first question. What do you actually want to do? Do you need to
>> authenticate with the heat endpoint with TLS (using client certificates) ?
>> Or, do you want to merely use TLS to communicate with Heat and you're
>> getting this verification issue?
>>
>> On Wed, Nov 8, 2017 at 10:48 PM, David Gabriel <davidgab...@gmail.com>
>> wrote:
>>
>>> I forget to send the errors I got:
>>>
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
>>> 109, in create
>>> data=kwargs, headers=headers)
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py",
>>> line 223, in json_request
>>> resp = self._http_request(url, method, **kwargs)
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py",
>>> line 166, in _http_request
>>> **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line
>>> 53, in request
>>> return session.request(method=method, url=url, **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
>>> line 468, in request
>>> resp = self.send(prep, **send_kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
>>> line 576, in send
>>> r = adapter.send(request, **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py",
>>> line 447, in send
>>> raise SSLError(e, request=request)
>>> SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>>> 127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500
>>> 2801
>>>
>>>
>>> 2017-11-08 21:43 GMT+01:00 David Gabriel <davidgab...@gmail.com>:
>>>
>>>> Dear Juan,
>>>>
>>>> Thanks so much for your reply.
>>>> I fact, the command you suggest leads to the structure of a .pem file
>>>> like it is shown in the reference you provide.
>>>>
>>>> Let me please ask another question related to the new pem file.
>>>> In fact, I want to use use it in to call python-heatclient API in order
>>>> to create stacks (Openstack address is based on https).
>>>> I am wondering, where to copy this pem file and how to refer it ?
>>>>
>>>> Thanks in advance.
>>>> Best regards.
>>>>
>>>>
>>>>
>>>> 2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> You need to verify the files and check how they look like. A good
>>>>> guide to do this is this one http://how2ssl.com/articles/wo
>>>>> rking_with_pem_files/ .
>>>>> .cert and .key are not actual formats, but might actually contain the
>>>>> cert and the key in PEM format. The main giveaway is that they should
>>>>> contain the header. If you will use the file for HAProxy, then you need 
>>>>> the
>>>>> certificate and key in the same file. So you would do something like this:
>>>>>
>>>>> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>>>>>
>>>>> And the resulting file is something you could use for your HAProxy
>>>>> instance. But again, it all depends on what you will use it for.
>>>>>
>>>>> On Wed, Nov 

Re: [openstack-dev] [Openstack] generation of .pem file

[Juan Antonio Osorio]

On Thu, Nov 9, 2017 at 3:27 PM, David Gabriel <davidgab...@gmail.com> wrote:

> My objective is to create a stack using Heat.
> Initially, my code worked properly with http access but when our Openstack
> is updated the access is becoming via https so I got the errors I sent in
> the previous email.
> So I think I need to *authenticate *using the .pem certificate.
> But, I don't know where exactely (which location) I put the .pem file in
> order to be visible to the heatclient (or keystone) and how shall I update
> my code ?
>

I really suggest you ask your administrator what you should be doing.
Having TLS on the endpoint doesn't necessarily mean that you need to
authenticate. It could mean that all you need to do is trust the CA that
issued the certificate that Heat (or the load balancer) is serving publicly.



> I am confusing a little bit!
> Thanks in advance.
> Best regards.
>
> 2017-11-09 9:05 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>
>> Alright,
>>
>> So, first question. What do you actually want to do? Do you need to
>> authenticate with the heat endpoint with TLS (using client certificates) ?
>> Or, do you want to merely use TLS to communicate with Heat and you're
>> getting this verification issue?
>>
>> On Wed, Nov 8, 2017 at 10:48 PM, David Gabriel <davidgab...@gmail.com>
>> wrote:
>>
>>> I forget to send the errors I got:
>>>
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
>>> 109, in create
>>> data=kwargs, headers=headers)
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py",
>>> line 223, in json_request
>>> resp = self._http_request(url, method, **kwargs)
>>>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py",
>>> line 166, in _http_request
>>> **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line
>>> 53, in request
>>> return session.request(method=method, url=url, **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
>>> line 468, in request
>>> resp = self.send(prep, **send_kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
>>> line 576, in send
>>> r = adapter.send(request, **kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py",
>>> line 447, in send
>>> raise SSLError(e, request=request)
>>> SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>>> 127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500
>>> 2801
>>>
>>>
>>> 2017-11-08 21:43 GMT+01:00 David Gabriel <davidgab...@gmail.com>:
>>>
>>>> Dear Juan,
>>>>
>>>> Thanks so much for your reply.
>>>> I fact, the command you suggest leads to the structure of a .pem file
>>>> like it is shown in the reference you provide.
>>>>
>>>> Let me please ask another question related to the new pem file.
>>>> In fact, I want to use use it in to call python-heatclient API in order
>>>> to create stacks (Openstack address is based on https).
>>>> I am wondering, where to copy this pem file and how to refer it ?
>>>>
>>>> Thanks in advance.
>>>> Best regards.
>>>>
>>>>
>>>>
>>>> 2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> You need to verify the files and check how they look like. A good
>>>>> guide to do this is this one http://how2ssl.com/articles/wo
>>>>> rking_with_pem_files/ .
>>>>> .cert and .key are not actual formats, but might actually contain the
>>>>> cert and the key in PEM format. The main giveaway is that they should
>>>>> contain the header. If you will use the file for HAProxy, then you need 
>>>>> the
>>>>> certificate and key in the same file. So you would do something like this:
>>>>>
>>>>> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>>>>>
>>>>> And the resulting file is something you could use for your HAProxy
>>>>> instance. But again, it all depends on what you will use it for.
>>>>>
>>>>> On Wed, Nov 

Re: [Openstack] [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Alright,

So, first question. What do you actually want to do? Do you need to
authenticate with the heat endpoint with TLS (using client certificates) ?
Or, do you want to merely use TLS to communicate with Heat and you're
getting this verification issue?

On Wed, Nov 8, 2017 at 10:48 PM, David Gabriel <davidgab...@gmail.com>
wrote:

> I forget to send the errors I got:
>
>   File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
> 109, in create
> data=kwargs, headers=headers)
>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
> 223, in json_request
> resp = self._http_request(url, method, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
> 166, in _http_request
> **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53,
> in request
> return session.request(method=method, url=url, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
> line 468, in request
> resp = self.send(prep, **send_kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
> line 576, in send
> r = adapter.send(request, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py",
> line 447, in send
> raise SSLError(e, request=request)
> SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500 2801
>
>
> 2017-11-08 21:43 GMT+01:00 David Gabriel <davidgab...@gmail.com>:
>
>> Dear Juan,
>>
>> Thanks so much for your reply.
>> I fact, the command you suggest leads to the structure of a .pem file
>> like it is shown in the reference you provide.
>>
>> Let me please ask another question related to the new pem file.
>> In fact, I want to use use it in to call python-heatclient API in order
>> to create stacks (Openstack address is based on https).
>> I am wondering, where to copy this pem file and how to refer it ?
>>
>> Thanks in advance.
>> Best regards.
>>
>>
>>
>> 2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>>
>>> Hello,
>>>
>>> You need to verify the files and check how they look like. A good guide
>>> to do this is this one http://how2ssl.com/articles/wo
>>> rking_with_pem_files/ .
>>> .cert and .key are not actual formats, but might actually contain the
>>> cert and the key in PEM format. The main giveaway is that they should
>>> contain the header. If you will use the file for HAProxy, then you need the
>>> certificate and key in the same file. So you would do something like this:
>>>
>>> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>>>
>>> And the resulting file is something you could use for your HAProxy
>>> instance. But again, it all depends on what you will use it for.
>>>
>>> On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com>
>>> wrote:
>>>
>>>> Dears,
>>>>
>>>> I need to generate the .pem file based on certifcate files (.cert).
>>>> The key (.key file) is available too.
>>>> All my files can be read as text files.
>>>> Could you please detail the procedure for this ?
>>>> I am using ubuntu as OS.
>>>>
>>>> Thanks in advance.
>>>> Best regards.
>>>>
>>>> 
>>>> ______
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Juan Antonio Osorio R.
>>> e-mail: jaosor...@gmail.com
>>>
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Openstack] generation of .pem file

[Juan Antonio Osorio]

Alright,

So, first question. What do you actually want to do? Do you need to
authenticate with the heat endpoint with TLS (using client certificates) ?
Or, do you want to merely use TLS to communicate with Heat and you're
getting this verification issue?

On Wed, Nov 8, 2017 at 10:48 PM, David Gabriel <davidgab...@gmail.com>
wrote:

> I forget to send the errors I got:
>
>   File "/usr/lib/python2.7/dist-packages/heatclient/v1/stacks.py", line
> 109, in create
> data=kwargs, headers=headers)
>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
> 223, in json_request
> resp = self._http_request(url, method, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/heatclient/common/http.py", line
> 166, in _http_request
> **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53,
> in request
> return session.request(method=method, url=url, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
> line 468, in request
> resp = self.send(prep, **send_kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py",
> line 576, in send
> r = adapter.send(request, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py",
> line 447, in send
> raise SSLError(e, request=request)
> SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 127.0.0.1 - - [08/Nov/2017 20:34:56] "POST /stack_create HTTP/1.1" 500 2801
>
>
> 2017-11-08 21:43 GMT+01:00 David Gabriel <davidgab...@gmail.com>:
>
>> Dear Juan,
>>
>> Thanks so much for your reply.
>> I fact, the command you suggest leads to the structure of a .pem file
>> like it is shown in the reference you provide.
>>
>> Let me please ask another question related to the new pem file.
>> In fact, I want to use use it in to call python-heatclient API in order
>> to create stacks (Openstack address is based on https).
>> I am wondering, where to copy this pem file and how to refer it ?
>>
>> Thanks in advance.
>> Best regards.
>>
>>
>>
>> 2017-11-08 15:39 GMT+01:00 Juan Antonio Osorio <jaosor...@gmail.com>:
>>
>>> Hello,
>>>
>>> You need to verify the files and check how they look like. A good guide
>>> to do this is this one http://how2ssl.com/articles/wo
>>> rking_with_pem_files/ .
>>> .cert and .key are not actual formats, but might actually contain the
>>> cert and the key in PEM format. The main giveaway is that they should
>>> contain the header. If you will use the file for HAProxy, then you need the
>>> certificate and key in the same file. So you would do something like this:
>>>
>>> $ cat mycertificate.cert  mykey.key > cert-and-key.pem
>>>
>>> And the resulting file is something you could use for your HAProxy
>>> instance. But again, it all depends on what you will use it for.
>>>
>>> On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com>
>>> wrote:
>>>
>>>> Dears,
>>>>
>>>> I need to generate the .pem file based on certifcate files (.cert).
>>>> The key (.key file) is available too.
>>>> All my files can be read as text files.
>>>> Could you please detail the procedure for this ?
>>>> I am using ubuntu as OS.
>>>>
>>>> Thanks in advance.
>>>> Best regards.
>>>>
>>>> 
>>>> ______
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Juan Antonio Osorio R.
>>> e-mail: jaosor...@gmail.com
>>>
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com> wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best regards.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com> wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best regards.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com> wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best regards.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] generation of .pem file

[Juan Antonio Osorio]

Hello,

You need to verify the files and check how they look like. A good guide to
do this is this one http://how2ssl.com/articles/working_with_pem_files/ .
.cert and .key are not actual formats, but might actually contain the cert
and the key in PEM format. The main giveaway is that they should contain
the header. If you will use the file for HAProxy, then you need the
certificate and key in the same file. So you would do something like this:

$ cat mycertificate.cert  mykey.key > cert-and-key.pem

And the resulting file is something you could use for your HAProxy
instance. But again, it all depends on what you will use it for.

On Wed, Nov 8, 2017 at 3:36 PM, David Gabriel <davidgab...@gmail.com> wrote:

> Dears,
>
> I need to generate the .pem file based on certifcate files (.cert).
> The key (.key file) is available too.
> All my files can be read as text files.
> Could you please detail the procedure for this ?
> I am using ubuntu as OS.
>
> Thanks in advance.
> Best regards.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on

[Juan Antonio Osorio]

Proposed a patch to be able to enable the JSON formatter via an oslo.log
configuration parameter:

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

On Mon, Nov 6, 2017 at 9:43 AM, Cédric Jeanneret <
cedric.jeanne...@camptocamp.com> wrote:

> On 11/06/2017 08:36 AM, Juan Antonio Osorio wrote:
> > Giving this a bit more thought; I'm slightly more inclined on merely
> adding
> > the JSON formatter option to the standard oslo.log configuration options.
>
> Fine for me.
>
> >
> > This is because we right now have the ability to pass oslo.cfg options
> via
> > the CLI, and we would loose that with the advanced logging configuration
> > file. The aforementioned option is something that we're using for
> > containerized openstack services.
>
> OK - I'll check on my own if I can get something nice with the
> logging.conf file. But that won't be for "tomorrow", as I'm not
> full-time on openstack (unfortunately :(). Both solutions have their
> pros and cons in the end.
>
> >
> > I'll look into adding the ability to turn that handler on/off from
> oslo.log.
>
> Ping me if I can help :). And big thanks for that coming change!
>
> >
> >
> >
> > On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio <jaosor...@gmail.com
> >
> > wrote:
> >
> >>
> >>
> >> On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret <
> >> cedric.jeanne...@camptocamp.com> wrote:
> >>
> >>> On 11/04/2017 07:08 AM, Doug Hellmann wrote:
> >>>> Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47
> >>> +0200:
> >>>>>> On 3 Nov 2017 19:59, "Doug Hellmann" <d...@doughellmann.com> wrote:
> >>>>>>
> >>>>>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34
> +0100:
> >>>>>>> Dear Stackers,
> >>>>>>>
> >>>>>>> While working on my locally deployed Openstack (Pike using
> TripleO),
> >>> I
> >>>>>>> was a bit struggling with the logging part. Currently, all logs are
> >>>>>>> pushed to per-service files, in the standard format "one line per
> >>>>>>> entry", plain flat text.
> >>>>>>>
> >>>>>>> It's nice, but if one is wanting to push and index those logs in an
> >>> ELK,
> >>>>>>> the current, default format isn't really good.
> >>>>>>>
> >>>>>>> After some discussions about oslo.log, it appears it provides a
> nice
> >>>>>>> JSONFormatter handler¹ one might want to use for each (python)
> >>> service
> >>>>>>> using oslo central library.
> >>>>>>>
> >>>>>>> A JSON format is really cool, as it's easy to parse for machines,
> >>> and it
> >>>>>>> can be on a multi-line without any bit issue - this is especially
> >>>>>>> important for stack traces, as their output is multi-line without
> >>> real
> >>>>>>> way to have a common delimiter so that we can re-format it and feed
> >>> it
> >>>>>>> to any log parser (logstash, fluentd, …).
> >>>>>>>
> >>>>>>> After some more talks, olso.log will not provide a unified
> interface
> >>> in
> >>>>>>> order to output all received logs as JSON - this makes sens, as
> that
> >>>>>>> would mean "rewrite almost all the python logging management
> >>>>>>> interface"², and that's pretty useless, since (all?) services have
> >>> their
> >>>>>>> own "logging.conf" file.
> >>>>>>>
> >>>>>>> That said… to the main purpose of that mail:
> >>>>>>>
> >>>>>>> - Default format for logs
> >>>>>>> A first question would be "are we all OK with the default output
> >>> format"
> >>>>>>> - I'm pretty sure "humans" are happy with that, as it's really
> >>>>>>> convenient to read and grep. But on a "standard" Openstack deploy,
> >>> I'm
> >>>>>>> pretty sure one does not have only one controller, one ceph node
> and
> >>> one
> >>>>>>> compute. Hence comes the log centralization, and with that

Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on

[Juan Antonio Osorio]

Giving this a bit more thought; I'm slightly more inclined on merely adding
the JSON formatter option to the standard oslo.log configuration options.

This is because we right now have the ability to pass oslo.cfg options via
the CLI, and we would loose that with the advanced logging configuration
file. The aforementioned option is something that we're using for
containerized openstack services.

I'll look into adding the ability to turn that handler on/off from oslo.log.



On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio <jaosor...@gmail.com>
wrote:

>
>
> On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret <
> cedric.jeanne...@camptocamp.com> wrote:
>
>> On 11/04/2017 07:08 AM, Doug Hellmann wrote:
>> > Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47
>> +0200:
>> >>> On 3 Nov 2017 19:59, "Doug Hellmann" <d...@doughellmann.com> wrote:
>> >>>
>> >>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100:
>> >>>> Dear Stackers,
>> >>>>
>> >>>> While working on my locally deployed Openstack (Pike using TripleO),
>> I
>> >>>> was a bit struggling with the logging part. Currently, all logs are
>> >>>> pushed to per-service files, in the standard format "one line per
>> >>>> entry", plain flat text.
>> >>>>
>> >>>> It's nice, but if one is wanting to push and index those logs in an
>> ELK,
>> >>>> the current, default format isn't really good.
>> >>>>
>> >>>> After some discussions about oslo.log, it appears it provides a nice
>> >>>> JSONFormatter handler¹ one might want to use for each (python)
>> service
>> >>>> using oslo central library.
>> >>>>
>> >>>> A JSON format is really cool, as it's easy to parse for machines,
>> and it
>> >>>> can be on a multi-line without any bit issue - this is especially
>> >>>> important for stack traces, as their output is multi-line without
>> real
>> >>>> way to have a common delimiter so that we can re-format it and feed
>> it
>> >>>> to any log parser (logstash, fluentd, …).
>> >>>>
>> >>>> After some more talks, olso.log will not provide a unified interface
>> in
>> >>>> order to output all received logs as JSON - this makes sens, as that
>> >>>> would mean "rewrite almost all the python logging management
>> >>>> interface"², and that's pretty useless, since (all?) services have
>> their
>> >>>> own "logging.conf" file.
>> >>>>
>> >>>> That said… to the main purpose of that mail:
>> >>>>
>> >>>> - Default format for logs
>> >>>> A first question would be "are we all OK with the default output
>> format"
>> >>>> - I'm pretty sure "humans" are happy with that, as it's really
>> >>>> convenient to read and grep. But on a "standard" Openstack deploy,
>> I'm
>> >>>> pretty sure one does not have only one controller, one ceph node and
>> one
>> >>>> compute. Hence comes the log centralization, and with that, the log
>> >>>> indexation and treatments.
>> >>>>
>> >>>> For that, one might argue "I'm using plain files on my logger, and
>> >>>> grep-ing -r in them". That's a way to do things, and for that, plain,
>> >>>> flat logs are great.
>> >>>>
>> >>>> But… I'm pretty sure I'm not the only one wanting to use some kind of
>> >>>> ELK cluster for that kind of purpose. So the right question is: what
>> >>>> about switching the default log format to JSON? On my part, I don't
>> see
>> >>>> "cons", only "pros", but my judgment is of course biased, as I'm
>> "alone
>> >>>> in my corner". But what about you, Community?
>> >>>>
>> >>>> - Provide a way to configure the output format/handler
>> >>>> While poking around in the puppet modules code, I didn't find any
>> way to
>> >>>> set the output handler for the logs. For example, in puppet-nova³ we
>> can
>> >>>> set a lot of things, but not the useful handler for the output.
>> >>>>
>> >&g

Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on

[Juan Antonio Osorio]

> >
> > Great! Let me know if you would like to help figuring out where to do
> > that in the library code.
>
> There's already some (not really documented) feature allowing oslo.log
> to load a configuration file. In fact, there's already one existing in
> the keystone tree (/etc/keystone/logging.conf - altougn not loaded) - we
> might base something "casual" and "generic" on that one.
>
> I think all wsgi/python services should configure the logging through
> that file so that it's clearer and cleaner. But that part is maybe a bit
> too big and "aggressive" :). And the logging configuration isn't that
> friendly, to be honest, at least I have some issues with its doc ;).
>
> But I think we might come to something nice and cool. It would allow
> anyone to push  their own log "formatter", in the end.
> So you (oslo.log) wouldn't need to work with format output requests
> anymore, just provide two basics (plain and json), and let users play
> with the logging configuration (and even output things in XML if they
> want) ;).
>
> Regarding oslo.log: apparently, adding the following entry in the
> service configuration file should do it:
> log-config-append¹
>
> Can anyone confirm that?
>

It seems to be the case at least from the docs in the option [1]. But if we
use this file (in TripleO and puppet) we really need to make it backwards
compatible. Would folks be OK with taking it into use? I guess what it
would take would be to document better the usage of this advanced
configuration. Taking it into use doesn't look that bad; If you look at the
file where the options are being set (_options.py), you will see that there
are several options that get ignored once we start using this file [2]. To
see all the options that get ignored you can look at the instances of
_IGNORE_MESSAGE. So, if we would start taking that into use, we would need
to change the parameters of the oslo::log resource in puppet [3] to also
configure an equivalent option to that advanced logging file.

[1]
https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L44
[2]
https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L32
[3] https://github.com/openstack/puppet-oslo/blob/master/manifests/log.pp

>
>
> ¹ https://github.com/openstack/oslo.log/blob/master/oslo_log/
> _options.py#L44
>
> >
> > Doug
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Logging format: let's discuss a bit about default format, format configuration and so on

[Juan Antonio Osorio]

On 3 Nov 2017 19:59, "Doug Hellmann"  wrote:

Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100:
> Dear Stackers,
>
> While working on my locally deployed Openstack (Pike using TripleO), I
> was a bit struggling with the logging part. Currently, all logs are
> pushed to per-service files, in the standard format "one line per
> entry", plain flat text.
>
> It's nice, but if one is wanting to push and index those logs in an ELK,
> the current, default format isn't really good.
>
> After some discussions about oslo.log, it appears it provides a nice
> JSONFormatter handler¹ one might want to use for each (python) service
> using oslo central library.
>
> A JSON format is really cool, as it's easy to parse for machines, and it
> can be on a multi-line without any bit issue - this is especially
> important for stack traces, as their output is multi-line without real
> way to have a common delimiter so that we can re-format it and feed it
> to any log parser (logstash, fluentd, …).
>
> After some more talks, olso.log will not provide a unified interface in
> order to output all received logs as JSON - this makes sens, as that
> would mean "rewrite almost all the python logging management
> interface"², and that's pretty useless, since (all?) services have their
> own "logging.conf" file.
>
> That said… to the main purpose of that mail:
>
> - Default format for logs
> A first question would be "are we all OK with the default output format"
> - I'm pretty sure "humans" are happy with that, as it's really
> convenient to read and grep. But on a "standard" Openstack deploy, I'm
> pretty sure one does not have only one controller, one ceph node and one
> compute. Hence comes the log centralization, and with that, the log
> indexation and treatments.
>
> For that, one might argue "I'm using plain files on my logger, and
> grep-ing -r in them". That's a way to do things, and for that, plain,
> flat logs are great.
>
> But… I'm pretty sure I'm not the only one wanting to use some kind of
> ELK cluster for that kind of purpose. So the right question is: what
> about switching the default log format to JSON? On my part, I don't see
> "cons", only "pros", but my judgment is of course biased, as I'm "alone
> in my corner". But what about you, Community?
>
> - Provide a way to configure the output format/handler
> While poking around in the puppet modules code, I didn't find any way to
> set the output handler for the logs. For example, in puppet-nova³ we can
> set a lot of things, but not the useful handler for the output.
>
> It would be really cool to get, for each puppet module, the capability
> to set the handler so that one can just push some stuff in hiera, and
> Voilà, we have JSON logs.
>
> Doing so would allow people to chose between the default  (current)
> output, and something more "computable".

Using the JSON formatter currently requires setting a logging
configuration file using the standard library configuration format
and fully specifying things like log levels, handlers, and output
destination. Would it make sense to add an option in oslo.log to
give deployers an easier way to enable the JSON formatter?

This would actually be very useful.


Doug

>
> Of course, either proposal will require a nice code change in all puppet
> modules (add a new parameter for the foo::logging class, and use that
> new param in the configuration file, and so on), but at least people
> will be able to actually chose.
>
> So, before opening an issue on each launchpad project (that would be…
> long), I'd rather open the discussion in here and, eventually, come to
> some nice, acceptable and accepted solution that would make the
> Openstack Community happy :).
>
> Any thoughts?
>
> Thank you for your attention, feedback and wonderful support for that
> monster project :).
>
> Cheers,
>
> C.
>
>
> ¹
> https://github.com/openstack/oslo.log/blob/master/oslo_log/
formatters.py#L166-L235
> ²
> http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/
%23openstack-oslo.2017-11-01.log.html#t2017-11-01T13:23:14
> ³ https://github.com/openstack/puppet-nova/blob/master/
manifests/logging.pp
>

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

Re: [openstack-dev] Logging format: let's discuss a bit about default format, format configuration and so on

[Juan Antonio Osorio]

t
>> modules (add a new parameter for the foo::logging class, and use that
>> new param in the configuration file, and so on), but at least people
>> will be able to actually chose.
>>
>> So, before opening an issue on each launchpad project (that would be…
>> long), I'd rather open the discussion in here and, eventually, come to
>> some nice, acceptable and accepted solution that would make the
>> Openstack Community happy :).
>>
>> Any thoughts?
>>
>> Thank you for your attention, feedback and wonderful support for that
>> monster project :).
>>
>> Cheers,
>>
>> C.
>>
>>
>> ¹
>> https://github.com/openstack/oslo.log/blob/master/oslo_log/f
>> ormatters.py#L166-L235
>> ²
>> http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%
>> 23openstack-oslo.2017-11-01.log.html#t2017-11-01T13:23:14
>> ³ https://github.com/openstack/puppet-nova/blob/master/manifes
>> ts/logging.pp
>>
>>
>> --
>> Cédric Jeanneret
>> Senior Linux System Administrator
>> Infrastructure Solutions
>>
>> Camptocamp SA
>> PSE-A / EPFL, 1015 Lausanne
>>
>> Phone: +41 21 619 10 32
>> Office: +41 21 619 10 02
>> Email: cedric.jeanne...@camptocamp.com
>>
>>
>>
>>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] rh1 outage today

[Juan Antonio Osorio]

Thanks for the postmortem; it's always a good read tp learn stuff :)

On 28 Oct 2017 00:11, "Ben Nemec"  wrote:

Hi all,

As you may or may not have noticed all ovb jobs on rh1 started failing
sometime last night.  After some investigation today I found a few issues.

First, our nova db archiving wasn't working.  This was due to the
auto-increment counter issue described by melwitt in
http://lists.openstack.org/pipermail/openstack-dev/2017-Sept
ember/122903.html  Deleting the problematic rows from the shadow table got
us past that.

On another db-related note, we seem to have turned ceilometer back on at
some point in rh1.  I think that was intentional to avoid notification
queues backing up, but it led to a different problem.  We had approximately
400 GB of mongodb data from ceilometer that we don't actually care about.
I cleaned that up and set a TTL in ceilometer so hopefully this won't
happen again.

Is there an alarm or something we could set to get notified about this kind
of stuff? Or better yet, something we could automate to avoid this? What's
usimg mongodb nowadays?


Unfortunately neither of these things completely resolved the extreme
slowness in the cloud that was causing every testenv to fail.  After trying
a number of things that made no difference, the culprit seems to have been
rabbitmq.  There was nothing obviously wrong with it according to the web
interface, the queues were all short and messages seemed to be getting
delivered.  However, when I ran rabbitmqctl status at the CLI it reported
that the node was down.  Since something was clearly wrong I went ahead and
restarted it.  After that everything seems to be back to normal.

Same questiom as above, could we set and alarm or automate the node
recovery?


I'm not sure exactly what the cause of all this was.  We did get kind of
inundated with jobs yesterday after a zuul restart which I think is what
probably pushed us over the edge, but that has happened before without
bringing the cloud down.  It was probably a combination of some previously
unnoticed issues stacking up over time and the large number of testenvs
requested all at once.

In any case, testenvs are creating successfully again and the jobs in the
queue look good so far.  If you notice any problems please let me know
though.  I'm hoping this will help with the job timeouts, but that remains
to be seen.

-Ben

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

Re: [openstack-dev] [all] connecting nova notification users and developers

[Juan Antonio Osorio]

Novajoin[1] uses notifications to detect when an instance is provisioned
and register it to FreeIPA (in short).

I added it to the etherpad accordingly.

We're not yet using versioned notifications.


[1] https://review.openstack.org/#/admin/projects/openstack/novajoin

On Wed, Aug 30, 2017 at 5:30 PM, Balazs Gibizer <balazs.gibi...@ericsson.com
> wrote:

> Hi,
>
> Nova emits notifications for many different event, like different instance
> actions[1]. Also the nova developer community is working on making nova
> notifications well defined and easy to consume [2].
>
> The goal of this mail is twofold.
>
> 1) We in the nova developer community would like to see which projects are
> using (or planning to use) the nova notification interface. Also we would
> like to know if you are using the legacy unversioned notifications or the
> new versioned ones. We would like to know what are your use cases towards
> our notification interface and we also would like to get any type of
> feedback about the interface (both the old and the new one). Based on this
> information we can make better decision where to focus our development
> effort. As a good example we already have a  cooperation with the
> searchlight project to enhance nova's versioned notification interface
> based on their needs [3].
>
> I opened an etherpad [4] to collect the projects and the feedback and we
> can go through that feedback in the PTG to define some actions.
>
> 2) Creating a well defined and easy to use notification interface gives us
> plenty of work in nova. So we are also looking for developers who can help
> us in this work. Big chunk of [2] is considered as low hanging fruit and
> I'm happy to mentor anybody who is interested learning this part of nova.
> If you want to join to this work just ping me (gibi) or IRC.
>
> Cheers,
> gibi
>
> [1]https://docs.openstack.org/nova/latest/reference/notifications.html
> [2]https://blueprints.launchpad.net/nova/+spec/versioned-
> notification-transformation-queens
> [3]https://blueprints.launchpad.net/nova/+spec/additional-
> notification-fields-for-searchlight
> [4]https://etherpad.openstack.org/p/queens-nova-notifications
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][CI] FreeIPA Deployment

[Juan Antonio Osorio]

Something that just came to my mind: Another option would be to allocate an
extra IP Address for the undercloud, that would be dedicated to FreeIPA,
and that way we MAY be able to deploy the FreeIPA server in the undercloud.
If folks are OK with this I could experiment on this front. Maybe I could
try to run FreeIPA on a container [1] (which wasn't available when I
started working on this).

[1] https://hub.docker.com/r/freeipa/freeipa-server/

On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi <emil...@redhat.com> wrote:

> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
> <jaosor...@gmail.com> wrote:
> > The second option seems like the most viable. Not sure how the TripleO
> > integration would go though. Care to elaborate on what you had in mind?
>
> Trying to reproduce what we did with ceph-ansible and use Mistral to
> deploy FreeIPA with an external deployment tool.
> Though I find the solution quite complex, maybe we can come-up with an
> easier approach this time?
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Juan Antonio Osorio]

est.me
>>> >
>>> > ___
>>> > OpenStack-operators mailing list
>>> > openstack-operat...@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>> k-operators
>>> >
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> openstack-operat...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [nova] Proposing Balazs Gibizer for nova-core

[Juan Antonio Osorio]

Nice!! Congrats Gibi!!

On 23 Aug 2017 11:19, "Stephen Finucane"  wrote:

> On Tue, 2017-08-22 at 20:18 -0500, Matt Riedemann wrote:
> > I'm proposing that we add gibi to the nova core team. He's been around
> > for awhile now and has shown persistence and leadership in the
> > multi-release versioned notifications effort, which also included
> > helping new contributors to Nova get involved which helps grow our
> > contributor base.
> >
> > Beyond that though, gibi has a good understanding of several areas of
> > Nova, gives thoughtful reviews and feedback, which includes -1s on
> > changes to get them in shape before a core reviewer gets to them,
> > something I really value and look for in people doing reviews who aren't
> > yet on the core team. He's also really helpful with not only reporting
> > and triaging bugs, but writing tests to recreate bugs so we know when
> > they are fixed, and also works on fixing them - something I expect from
> > a core maintainer of the project.
> >
> > So to the existing core team members, please respond with a yay/nay and
> > after about a week or so we should have a decision (knowing a few cores
> > are on vacation right now).
>
> Yay, for sure.
>
> Stephen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

[Juan Antonio Osorio]

On Mon, Aug 21, 2017 at 5:48 PM, Ben Nemec <openst...@nemebean.com> wrote:

>
>
> On 08/21/2017 01:45 AM, Juan Antonio Osorio wrote:
>
>> The second option seems like the most viable. Not sure how the TripleO
>> integration would go though. Care to elaborate on what you had in mind?
>>
>
> I can't remember if we discussed this when we were first implementing the
> ci job, but could FreeIPA run on the undercloud itself?  We could have the
> undercloud install process install FreeIPA before it does the rest of the
> undercloud install, and then the undercloud by default would talk to that
> local instance of FreeIPA.  We'd provide configuration options to allow use
> of a standalone server too, of course.
>

Right, this would have been the preferred option, and we did try to do
this. However, FreeIPA not very flexible (it isn't at all) on its port
configuration. And unfortunately there are port conflicts. Hence why we
decided to use a separate node.


> I feel like there was probably a reason we didn't do that in the first
> place (port conflicts?), but it would be the easiest option for deployers
> if we could make it work.
>
>
>> On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi <emil...@redhat.com
>> <mailto:emil...@redhat.com>> wrote:
>>
>> On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki <hryba...@redhat.com
>> <mailto:hryba...@redhat.com>> wrote:
>>  > Greetings Stackers,
>>  >
>>  > Recently, I brought up a discussion around deploying FreeIPA via
>>  > TripleO-Quickstart vs TripleO. This is part of a larger discussion
>>  > around expanding security related CI coverage for OpenStack.
>>  >
>>  > A few months back, I added the ability to deploy FreeIPA via
>>  > TripleO-Quickstart through three reviews:
>>  >
>>  > 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
>>  > 2) Providing OOOQ with the ability to deploy a supplemental node
>>  > (alongside the undercloud)[2]
>>  > 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
>>  >
>>  >
>>  > The reasoning behind this is as follows (copied from a conversation
>>  > with jaosorior):
>>  >
>>  >> So the deal is that both the undercloud and the overcloud need
>> to be registered as a FreeIPA client.
>>  >> This is because they need to authenticate to it in order to
>> execute actions.
>>  >>
>>  >> * The undercloud needs to have FreeIPA credentials because it's
>> running novajoin, which in turn
>>  >> executes requests to FreeIPA in order to create service principals
>>  >>  - The service principals are ultimately the service name and
>> the node name entries for which we'll
>>  >> requests the certificates.
>>  >> * The overcloud nodes need to be registered and authenticated to
>> FreeIPA (which right now happens > through a cloud-init script
>> provisioned by nova/nova-metadata) because that's how it requests
>>  >> certificates.
>>  >>
>>  >> So the flow is as follows:
>>  >>
>>  >> * FreeIPA node is provisioned.
>>  >>  - We'll appropriate credentials at this point.
>>  >>  - We register the undercloud as a FreeIPA client and get an OTP
>> (one time password) for it
>>  >> - We add the OTP to the undercloud.conf and enable novajoin.
>>  >> * We trigger the undercloud install.
>>  >>  - after the install, we have novajoin running, which is the
>> service that registers automatically the
>>  >> overcloud nodes to FreeIPA.
>>  >> * We trigger the overcloud deploy
>>  >>  - We need to set up a flag that tells the deploy to pass
>> appropriate nova metadata (which tells
>>  >> novajoin that the nodes should be registered).
>>  >>  - profit!! we can now get certificates from the CA (and do
>> other stuff that FreeIPA allows you to do,
>>  >> such as use kerberos auth, control sudo rights of the nodes'
>> users, etc.)
>>  >>
>>  >> Since the nodes need to be registered to FreeIPA, we can't rely
>> on FreeIPA being installed by
>>  >> TripleO, even if that's possible by doing it through a
>> composable service.
>>  >> If we would use a composable service to install FreeIPA, the
>> flow would be like this:
&

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

[Juan Antonio Osorio]

puppet-freeipa module to deploy the bits but we're
> working toward migrating to Ansible at some point.
>

This approach is not ideal and will be quite a burdain as I described
above. I wouldn't consider this an option.


> I hope it helps, let me know if you need further details on a specific
> approach.
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Proposing Bogdan Dobrelya core on TripleO / Containers

[Juan Antonio Osorio]

+1!!!

On 21 Jul 2017 22:32, "Alex Schultz"  wrote:

On Fri, Jul 21, 2017 at 12:58 PM, Pradeep Kilambi  wrote:
> On Fri, Jul 21, 2017 at 1:36 PM, Brent Eagles  wrote:
>>
>>
>> On Fri, Jul 21, 2017 at 12:25 PM, Emilien Macchi 
wrote:
>>>
>>> Hi,
>>>
>>> Bogdan (bogdando on IRC) has been very active in Containerization of
>>> TripleO and his quality of review has increased over time.
>>> I would like to give him core permissions on container work in TripleO.
>>> Any feedback is welcome as usual, we'll vote as a team.
>>>
>>> Thanks,
>>> --
>>> Emilien Macchi
>>
>>
>> +1
>>
>> 
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> +1
>
>
> --
> Cheers,
> ~ Prad
>

+1

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

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

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

[Juan Antonio Osorio]

I actually like the idea of moving to kolla-kubernetes. I guess there would
be a bunch of work towards giving folks an upgrade path and reaching
feature parity; but this would happen anyway eurgh the switch to
kubernetes.  And this would have the added value of merging two
communities, thus more devs and folks testing :D . I like it!

On 14 Jul 2017 18:56, "Michał Jastrzębski"  wrote:

Guys you just described Kolla-Kubernetes pretty much... how about
we join effort and work towards this goal together?

On 14 July 2017 at 08:43, Flavio Percoco  wrote:
> On 14/07/17 17:26 +0200, Bogdan Dobrelya wrote:
>>
>> On 14.07.2017 11:17, Flavio Percoco wrote:
>>>
>>>
>>> Greetings,
>>>
>>> As some of you know, I've been working on the second phase of TripleO's
>>> containerization effort. This phase if about migrating the docker based
>>> deployment onto Kubernetes.
>>>
>>> These phase requires work on several areas: Kubernetes deployment,
>>> OpenStack
>>> deployment on Kubernetes, configuration management, etc. While I've been
>>> diving
>>> into all of these areas, this email is about the second point, OpenStack
>>> deployment on Kubernetes.
>>>
>>> There are several tools we could use for this task. kolla-kubernetes,
>>> openstack-helm, ansible roles, among others. I've looked into these
>>> tools and
>>> I've come to the conclusion that TripleO would be better of by having
>>> ansible
>>> roles that would allow for deploying OpenStack services on Kubernetes.
>>>
>>> The existing solutions in the OpenStack community require using Helm.
>>> While I
>>> like Helm and both, kolla-kubernetes and openstack-helm OpenStack
>>> projects, I
>>> believe using any of them would add an extra layer of complexity to
>>> TripleO,
>>
>>
>> It's hard to estimate that complexity w/o having a PoC of such an
>> integration. We should come up with a final choice once we have it done.
>>
>> My vote would go for investing engineering resources into solutions that
>> have problems already solved, even by the price of added complexity (but
>> that sort of depends...). Added complexity may be compensated with
>> removed complexity (like those client -> Mistral -> Heat -> Mistral ->
>> Ansible manipulations discussed in the mail thread mentioned below [0])
>
>
> I agree it's hard to estimate but you gotta draw the line somewhere. I
> actually
> spent time on this and here's a small PoC of ansible+mariadb+helm. I wrote
> the
> pyhelm lib (took some code from the openstack-helm folks) and I wrote the
> ansible helm module myself. I'd say I've spent enough time on this
research.
>
> I don't think getting a full PoC working is worth it as that will require
> way
> more work for not much value since we can anticipate some of the
> complexities
> already.
>
> As far as the complexity comment goes, I disagree with you. I don't think
> you're
> evaluating the amount of complexity that there *IS* already in TripleO and
> how
> adding more complexity (layers, states, services) would make things worse
> for
> not much extra value.
>
> By all means, I might be wrong here so, do let me know if you're seeing
> something I'm not.
> Flavio
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [tripleo] proposing Alex Schultz tripleo-core in all projects

[Juan Antonio Osorio]

+1

He's a great reviewer

On 7 Jul 2017 8:40 pm, "Emilien Macchi"  wrote:

> Alex has demonstrated high technical and community skills in TripleO -
> where he's already core on THT, instack-undercloud, and puppet-tripleo
> - but also very involved in other repos.
> I propose that we extend his core status to all TripleO projects and
> of course trust him (like we trust all core members) to review patches
> were we feel confortable with.
>
> He has shown an high interest in reviewed other TripleO projects and I
> think he would be ready for this change.
> As usual, this is an open proposal, any feedback is welcome.
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] weekly meetings on #tripleo

[Juan Antonio Osorio]

+1

On 5 Jul 2017 19:57, "Emilien Macchi"  wrote:

> After reading http://lists.openstack.org/pipermail/openstack-dev/2017-
> June/118899.html
> - we might want to collect TripleO's community feedback on doing
> weekly meetings on #tripleo instead of #openstack-meeting-alt.
>
> I see some direct benefits:
> - if you come up late in meetings, you could easily read backlog in
> #tripleo
> - newcomers not aware about the meeting channel wouldn't have to search
> for it
> - meeting would maybe get more activity and we would expose the
> information more broadly
>
> Any feedback on this proposal is welcome before we make any change (or
> not).
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

[Juan Antonio Osorio]

On the TripleO side we use the file based approach. Using the API would
have been easier to orchestrate (no need for reloads/restarts) but it's not
available yet in puppet-keystone.

On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad <lbrags...@gmail.com> wrote:

> Hi all,
>
> Keystone has deprecated the domain configuration upload capability
> provided through `keystone-manage`. We discussed it's removal in today's
> meeting [0] and wanted to send a quick note to the operator list. The
> ability to upload a domain config into keystone was done as a stop-gap
> until the API was marked as stable [1]. It seems as though file-based
> domain configuration was only a band-aid until full support was done.
>
> Of the operators using the domain config API in keystone, how many are
> backing their configurations with actual configuration files versus the API?
>
>
> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/
> keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][ci] TripleO OVB check gates to move to third party

[Juan Antonio Osorio]

I would really appreciate that this is done once we finish moving the
TLS-everywhere job to run over oooq. This is on the works currently.

On Tue, Jun 13, 2017 at 2:19 AM, Ronelle Landy <rla...@redhat.com> wrote:

> Greetings,
>
> TripleO OVB check gates are managed by upstream Zuul and executed on nodes
> provided by test cloud RH1. RDO Cloud is now available as a test cloud to
> be used when running CI jobs. To utilize to RDO Cloud, we could either:
>
> - continue to run from upstream Zuul (and spin up nodes to deploy the
> overcloud from RDO Cloud)
> - switch the TripleO OVB check gates to run as third party and manage
> these jobs from the Zuul instance used by Software Factory
>
> The openstack infra team advocates moving to third party.
> The CI team is meeting with Frederic Lepied, Alan Pevec, and other members
> of the Software Factory/RDO project infra tream to discuss how this move
> could be managed.
>
> Note: multinode jobs are not impacted - and will continue to run from
> upstream Zuul on nodes provided by nodepool.
>
> Since a move to third party could have significant impact, we are posting
> this out to gather feedback and/or concerns that TripleO developers may
> have.
>
>
> Thanks!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][ci] tripleo periodic jobs moving to RDO's software factory and RDO Cloud

[Juan Antonio Osorio]

Currently the TLS-everywhere job (fakeha-caserver) runs as a periodic job.
If there's gonna be a move. I would really appreciate that this is done
once we move that job to run over oooq. So don't loose that job.

On Tue, Jun 13, 2017 at 12:01 AM, Wesley Hayutin <whayu...@redhat.com>
wrote:

> Greetings,
>
> I wanted to send out a summary email regarding some work that is still
> developing and being planned to give interested parties time to comment and
> prepare for change.
>
> Project:
> Move tripleo periodic promotion jobs
>
> Goal:
> Increase the cadence of tripleo-ci periodic promotion jobs in a way
> that does not impact upstream OpenStack zuul queues and infrastructure.
>
> Next Steps:
> The dependencies in RDO's instance of software factory are now
> complete and we should be able to create a new a net new zuul queue in RDO
> infra for tripleo-periodic jobs.  These jobs will have to run both
> multinode nodepool and ovb style jobs and utilize RDO-Cloud as the host
> cloud provider.  The TripleO CI team is looking into moving the TripleO
> periodic jobs running upstream to run from RDO's software factory instance.
> This move will allow the CI team more flexibility in managing the periodic
> jobs and resources to run the jobs more frequently.
>
> TLDR:
> There is no set date as to when the periodic jobs will move. The move
> will depend on tenant resource allocation and how easily the periodic jobs
> can be modified.  This email is to inform the group that changes are being
> planned to the tripleo periodic workflow and allow time for comment and
> preparation.
>
> Completed Background Work:
> After long discussion with Paul Belanger about increasing the cadence
> of the promotion jobs [1]. Paul explained infa's position and if he doesn't
> -1/-2 a new pipeline that has the same priority as check jobs someone else
> will. To summarize the point, the new pipeline would compete and slow down
> non-tripleo projects in the gate even when the hardware resources are our
> own.
> To avoid slowing down non-tripleo projects Paul has volunteered to help
> setup the infrastructure in rdoproject to manage the queue ( zuul etc). We
> would still use rh-openstack-1 / rdocloud for ovb, and could also trigger
> multinode nodepool jobs.
> There is one hitch though, currently, rdo-project does not have all the
> pieces of the puzzle in place to move off of openstack zuul and onto
> rdoproject zuul. Paul mentioned that nodepool-builder [2] is a hard
> requirement to be setup in rdoproject before we can proceed here. He
> mentioned working with the software factory guys to get this setup and
> running.
> At this time, I think this issue is blocked until further discussion.
> [1] https://review.openstack.org/#/c/443964/
> [2] https://github.com/openstack-infra/nodepool/blob/master/
> nodepool/builder.py
>
> Thanks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [tripleo] Ansible roles repo and how to inject them into the overcloud

[Juan Antonio Osorio]

Hi folks!

I would like to know if there are thoughts about where to put
tripleo-specific ansible roles.

I've been working lately on a role that would deploy ipsec tunnels for most
networks in an overcloud [1]. And I think that would be quite useful for
folks as an alternative to TLS everywhere. However, I don't know in what
TripleO repository I could put that role. Any ideas?

Also, I know I could call that from a composable service (although I would
need that to be ran after the puppet steps so maybe I'll need an extra
hook). However, is there any recommended way right now on how to inject
extra ansible roles into the overcloud nodes? If not, maybe a dedicated
hook to do this kind of thing would be something useful for others as well.

Any thoughts?

[1] https://github.com/JAORMX/tripleo-ipsec

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [heat] [devstack] [infra] heat api services with uwsgi

[Juan Antonio Osorio]

On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra <ramis...@redhat.com> wrote:

> Hi All,
>
> As per the updated community goal[1]  for api deployment with wsgi, we've
> to transition to use uwsgi rather than mod_wsgi at the gate. It also seems
> mod_wsgi support would be removed from devstack in Queens.
>
What do you mean support for mod_wsgi will be removed from devstack in
Queens? other projects have been using mod_wsgi and we've been deploying
several services (even Heat) in TripleO.

>
> I've been working on a patch[2] for the transition and encountered a few
> issues as below.
>
> 1. We encode stack_indentifer( along with the path
> separator in heatclient. So, requests with encoded path separators are
> dropped by apache (with 404), if we don't have 'AllowEncodedSlashes On'
> directive in the site/vhost config[3].
>
That's correct. You might want to refer to the configuration we use in
puppet/TripleO. We got it working with that :).
https://github.com/openstack/puppet-heat/blob/master/manifests/wsgi/apache.pp#L111-L137

>
> Setting this for mod_proxy_uwsgi[4] seems to work on fedora but not
> ubuntu.  From my testing It seems, it has to be set in 000-default.conf for
> ubuntu.
>
> Rather than messing with the devstack plugin code, I went ahead proposed a
> change to not encode the path separators in heatclient[5] ( Anyway they
> would be decoded by apache with the directive 'AllowEncodedSlashes On'
> before it's consumed by the service) which seem to have fixed those 404s.
>
> Is there a generic way to set the above directive (when using
> apache+mod_proxy_uwsgi) in the devstack plugin?
>
> 2.  With the above, most of the tests seem to work fine other than the
> ones using waitcondition, where we signal back from the vm to the api
> services. I could see " curl: (7) Failed to connect to 10.0.1.78 port 80:
> No route to host" in the vm console logs[6].
>
> It could connect to heat api services using ports 8004/8000 without this
> patch, but not sure why not port 80? I tried testing this locally and
> didn't see the issue though.
>
> Is this due to some infra settings or something else?
>
>
> [1] https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
>
> [2] https://review.openstack.org/#/c/462216/
>
> [3]  https://github.com/openstack/heat/blob/master/devstack/
> files/apache-heat-api.template#L9
>
> [4] http://logs.openstack.org/16/462216/6/check/gate-heat-dsvm-
> functional-convg-mysql-lbaasv2-non-apache-ubuntu-
> xenial/fbd06d6/logs/apache_config/heat-wsgi-api.conf.txt.gz
>
> [5] https://review.openstack.org/#/c/463510/
>
> [6] http://logs.openstack.org/16/462216/11/check/gate-heat-
> dsvm-functional-convg-mysql-lbaasv2-non-apache-ubuntu-
> xenial/e7d9e90/console.html#_2017-05-20_07_04_30_718021
>
>
> --
> Regards,
> Rabi Mishra
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [barbican] Nominating Jeremy Liu for Barbican Core

[Juan Antonio Osorio]

+1 from my side. I think he's been doing pretty good contributions and has
definitely earned it.

On Mon, Apr 24, 2017 at 7:13 PM, Dave McCowan (dmccowan) <dmcco...@cisco.com
> wrote:

> I'm pleased to nominate Jeremy Liu for Barbican core.
>
> He's been a top reviewer and contributor to Barbican since Newton and his
> efforts are very much appreciated.
>
> http://stackalytics.com/?module=barbican-group_id=
> liujiong=pike
>
> Barbicaneers, please indicate your agreement by responding with +1.
>
> --Dave
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [mistral][tripleo] mistralclient release needed

[Juan Antonio Osorio]

Hey,

We're trying to migrate the undercloud to use keystone v3. But we're
currently blocked by having an older version of mistralclient available. We
would really use a release to move forward.

For reference, this is the commit we need to use in mistralclient
https://github.com/openstack/python-mistralclient/commit/83b3d0d39cb8072682fac74f6a40877030e91c18

And this is the commit that's attempting to migrate to keystone v3 in
tripleo: https://review.openstack.org/#/c/446752/

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][CI] OVB combined job and periodic

[Juan Antonio Osorio]

What about the TLS-Everywhere job? (ovb-fakeha-caserver) it's currently
running on the periodic queue.

Are there plans to work on that one? or will it be left running with the
classic script? If it can be taken into account, I can help out with it if
I can pair work with someone that knows the ovb with oooq specifics better.

BR

On Wed, Apr 12, 2017 at 9:05 AM, Sagi Shnaidman <sshna...@redhat.com> wrote:

>
>
> Hi, all
>
> just another point to think about transition of periodic jobs:
> firstly, we need featureset files for them,
> secondly, when we combined ha and nonha job, it should be also one job in
> periodic jobs, which contains now ha, nonha, updates,
> because of all above, I think we will still need 2 jobs, because we check
> overcloud deletion in one of them, undercloud idempotency in second, and
> it's impossible to test all in one job because of time restrictions.
> So it seems to be like:
> 1) combined ovb job + overcloud deletion (+another specific features?)
> 2) combined ovb job + undercloud idempotent install (+another specific
> features?)
> 3) ovb updates job
>
> thoughts?
>
> --
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] os-cloud-config retirement

[Juan Antonio Osorio]

Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.

On 30 Mar 2017 16:42, "Jiří Stránský"  wrote:

> On 30.3.2017 14:58, Dan Prince wrote:
>
>> There is one case that I was thinking about reusing this piece of code
>> within a container to help initialize keystone endpoints. It would
>> require some changes and updates (to match how puppet-* configures
>> endpoints).
>>
>> For TripleO containers we use various puppet modules (along with hiera)
>> to drive the creation of endpoints. This functionally works fine, but
>> is quite slow to execute (puppet is slow here) and takes several
>> minutes to complete. I'm wondering if a single optimized python script
>> might serve us better here. It could be driven via YAML (perhaps
>> similar to our Hiera), idempotent, and likely much faster than having
>> the code driven by puppet. This doesn't have to live in os-cloud-
>> config, but initially I thought that might be a reasonable place for
>> it. It is worth pointing out that this would be something that would
>> need to be driven by our t-h-t workflow and not a post-installation
>> task. So perhaps that makes it not a good fit for os-cloud-config. But
>> it is similar to the keystone initialization already there so I thought
>> I'd mention it.
>>
>
> I agree we could have an optimized python script instead of puppet to do
> the init. However, os-cloud-config also doesn't strike me as the ideal
> place.
>
> What might be interesting is solving the keystone init within containers
> along with our container entrypoint situation. We've talked earlier that we
> may have to build our custom entrypoints into the images as we sometimes
> need to do things that the current entrypoints don't seem fit for, or don't
> give us enough control over what happens. This single optimized python
> script for endpoint config you mentioned could be one of such in-image
> entrypoint scripts. We could build multiple different scripts like this
> into a single image and select the right one when starting the container
> (defaulting to a script that handles the usual "worker" case, in this case
> Keystone API).
>
> This gets somewhat similar to the os-cloud-config usecase, but even if we
> wanted a separate repo, or even a RPM for these, i suppose it would be
> cleaner to just start from scratch rather than repurpose os-cloud-config.
>
> Jirka
>
>
>> Dan
>>
>> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>>
>>> Hi,
>>>
>>> os-cloud-config was deprecated in the Ocata release and is going to
>>> be
>>> removed in Pike.
>>>
>>> TripleO project doesn't need it anymore and after some investigation
>>> in codesearch.openstack.org, nobody is using it in OpenStack.
>>> I'm working on the removal this cycle, please let us know any
>>> concern.
>>>
>>> Thanks,
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] FFE for novajoin in TripleO's undercloud

[Juan Antonio Osorio]

On Fri, Feb 3, 2017 at 5:31 PM, Ben Nemec <openst...@nemebean.com> wrote:

>
>
> On 02/02/2017 06:27 PM, Juan Antonio Osorio wrote:
>
>> Hello,
>>
>> I would like to request an FFE to properly support the novajoin
>> vendordata plugin in TripleO. Most of the work has landed, however, we
>> still need to add it to TripleO's CI in order to have it officially
>> supported.
>>
>> This is crucial for TLS-everywhere configuration's usability, since it
>> makes it easier to populate the required field's in the CA (which in our
>> case is FreeIPA). I'm currently working on a patch to add it to the
>> fakeha-caserver OVB job; which, after this is done, I hope to move from
>> the experimental queue, to the periodic one.
>>
>
> I thought we had bumped TLS everywhere to next release.  Is there still a
> use case for novajoin in Ocata?
>

Well, one can deploy most base services with TLS in the internal network
already. So one can actually try it out.


>
>> BR
>>
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.com>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] FFE for novajoin in TripleO's undercloud

[Juan Antonio Osorio]

On Fri, Feb 3, 2017 at 4:54 PM, Emilien Macchi <emil...@redhat.com> wrote:

> On Thu, Feb 2, 2017 at 7:27 PM, Juan Antonio Osorio <jaosor...@gmail.com>
> wrote:
> > Hello,
> >
> > I would like to request an FFE to properly support the novajoin
> vendordata
> > plugin in TripleO. Most of the work has landed, however, we still need to
> > add it to TripleO's CI in order to have it officially supported.
>
> "Most of the work has landed": do we still have some patches (beside CI
> things)?
>

Well, the latest FreeIPA client code broke our connection code for
novajoin. So either we're fixing that. It shouldn't be too bad.


>
> > This is crucial for TLS-everywhere configuration's usability, since it
> makes
> > it easier to populate the required field's in the CA (which in our case
> is
> > FreeIPA). I'm currently working on a patch to add it to the
> fakeha-caserver
> > OVB job; which, after this is done, I hope to move from the experimental
> > queue, to the periodic one.
>
> I'm ok to add the job as long as it's non voting for now.
>
> > BR
> >
> > --
> > Juan Antonio Osorio R.
> > e-mail: jaosor...@gmail.com
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [TripleO] FFE for novajoin in TripleO's undercloud

[Juan Antonio Osorio]

Hello,

I would like to request an FFE to properly support the novajoin vendordata
plugin in TripleO. Most of the work has landed, however, we still need to
add it to TripleO's CI in order to have it officially supported.

This is crucial for TLS-everywhere configuration's usability, since it
makes it easier to populate the required field's in the CA (which in our
case is FreeIPA). I'm currently working on a patch to add it to the
fakeha-caserver OVB job; which, after this is done, I hope to move from the
experimental queue, to the periodic one.

BR

-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][CI] CI freeze and transition to quickstart

[Juan Antonio Osorio]

Well, even though it's an experimental job, the TLS-everywhere job
(fakeha-caserver) is quite stable at the moment; I still need to add the
novajoin service to it, to reflect what people will hopefully be using, but
other than that it's been running and doing fine. I would like to bring up
that currently, the oooq OVB jobs are incompatible with what we do with
that job.

Basically, from what I've understood, oooq OVB jobs use the undercloud
provided by the quintupleo stack, while currently in CI we rely on the node
provided by nodepool and install the undercloud there. For the
TLS-everywhere job, we use that undercloud as well, and spin up a very low
memory node to deploy FreeIPA in there, but this wouldn't be possible in
the oooq solution. I would like to discuss alternatives for this.

Any thoughts?

BR

On Wed, Feb 1, 2017 at 1:47 AM, Gabriele Cerami <gcer...@redhat.com> wrote:

> Hi,
>
> despite CI freeze for substantial change is in order, I recognize
> there's always the need to add or modify slightly the jobs for
> important fixes or to improve debugging.
>
> Unfortunately in these days we are wrapping up the gap in feature
> coverage between tripleo-ci and quickstart, and any of those change is
> increasing the list of features to be added to the implementation,
> making the wrap a moving target.
> Also, I'm seen some more-than-minor changes merged in these days, and
> that is making this job even more difficult.
>
> For those reason, we're going to ask everybody, from this moment on, for
> every change proposed to tripleo-ci, to propose an equivalent change to
> quickstart, or, if it seems too difficult, to open a bug in quickstart,
> pointing at the change in tripleo-ci, with some explanation on why it's
> needed, if it's not already clear in the commit message.
>
> At the end of this week we're going to make the final cut to the list
> of features we're going to transition to quickstart. If a feature, a
> test, an improvement, a small fix is added in tripleo-ci without
> signaling quickstart in any way, the risk is that the change will go
> unnoticed, and will be lost in transition.
>
> thanks for your collaboration.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

[Juan Antonio Osorio]

+1

On Tue, Jan 31, 2017 at 6:48 PM, John Trowbridge <tr...@redhat.com> wrote:

>
>
> On 01/31/2017 11:02 AM, Ben Nemec wrote:
> > In the spirit of all the core team changes, here are a couple more I'd
> > like to propose.
> >
> > Dmitry has been very helpful reviewing in instack-undercloud for a long
> > time so this is way overdue.  I'm also going to propose that he be able
> > to +2 anything Ironic-related in TripleO since that is his primary area
> > of expertise.
> >
>
> +1 long overdue. Dmitry reviews a ton of TripleO patches.
>
> > Alex has ramped up quickly on TripleO and has also been helping out with
> > instack-undercloud quite a bit.  He's already core for the puppet
> > modules, and a lot of the changes to instack-undercloud these days are
> > primarily in the puppet manifest so it's not a huge stretch to add him.
> >
>
> +1 as well.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

[Juan Antonio Osorio]

Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
on the current CI solution and in getting tripleo-quickstart jobs for
it); So I would like to propose him as part of the TripleO CI core team.

I think he'll make a great addition to the team and will help move CI
issues forward quicker.

Best Regards,



-- 
Juan Antonio Osorio R.
jaosorior
__
OpenStack Development Mailing 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] Proposing Alex Schultz core on puppet-tripleo

[Juan Antonio Osorio]

+1

On Fri, Dec 2, 2016 at 12:50 AM, Pradeep Kilambi <p...@redhat.com> wrote:

>
>
> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi <emil...@redhat.com> wrote:
>
>> Team,
>>
>> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
>> months now.  While he's very active in different areas of TripleO, his
>> reviews and contributions on puppet-tripleo have been very useful.
>> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
>> think he perfectly understands how puppet-tripleo works. His
>> involvement in the project and contributions on puppet-tripleo deserve
>> that we allow him to +2 puppet-tripleo.
>>
>> Thanks Alex for your involvement and hard work in the project, this is
>> very appreciated!
>>
>> As usual, I'll let the team to vote about this proposal.
>>
>
>
> +1
>
>
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] CI scenarios design - how to add more services

[Juan Antonio Osorio]

I don't have a strong opinion about any option, as long as we have
something in place I'm happy.

But regarding option 1.A: what would be done for newton once these
templates are moved to t-h-t. Would they be backported? What about mitaka?

On 24 Nov 2016 17:55, "Carlos Camacho Gonzalez"  wrote:

> I think would be cool to go with option, +1 to 1.A
>
> IMHO,
> - Easier to read.
> - Easier to maintain.
> - We don't make backports, instead we guarantee backwards compatibility.
> - We'll re-use experience from Puppet OpenStack CI.
>
> On Wed, Nov 23, 2016 at 10:13 PM, Giulio Fidente 
> wrote:
> > hi Emilien,
> >
> > thanks for putting some thought into this. We have a similar problem to
> test
> > RGW which was only added in Newton.
> >
> >
> > On 11/23/2016 03:02 AM, Emilien Macchi wrote:
> >>
> >> == Context
> >>
> >> In Newton we added new multinode jobs called "scenarios".
> >> The challenged we tried to solve was "how to test the maximum of
> >> services without overloading the nodes that run tests".
> >>
> >> Each scenarios deploys a set of services, which allows us to
> >> horizontally scale the number of scenarios to increase the service
> >> testing coverage.
> >> See the result here:
> >> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
> >>
> >> To implement this model, we took example of Puppet OpenStack CI:
> >> https://github.com/openstack/puppet-openstack-integration#description
> >> We even tried to keep consistent the services/scenarios relations, so
> >> it's consistent and easier to maintain.
> >>
> >> Everything was fine until we had to add new services during Ocata
> cycles.
> >> Because tripleo-ci repository is not branched, adding Barbican service
> >> in the TripleO environment for scenario002 would break Newton CI jobs.
> >> During my vacations, the team created a new scenario, scenario004,
> >> that deploys Barbican and that is only run for Ocata jobs.
> >> I don't think we should proceed this way, and let me explain why.
> >>
> >> == Problem
> >>
> >> How to scale the number of services that we test without increasing
> >> the number of scenarios and therefore the complexity of maintaining
> >> them on long-term.
> >>
> >>
> >> == Solutions
> >>
> >> The list is not exhaustive, feel free to add more.
> >>
> >> 1) Re-use experience from Puppet OpenStack CI and have environments
> >> that are in a branched repository.
> >> environments.
> >> In Puppet OpenStack CI, the repository that deploys environments
> >> (puppet-openstack-integration) is branched. So if puppet-barbican is
> >> ready to be tested in Ocata, we'll patch
> >> puppet-openstack-integration/master to start testing it and it won't
> >> break stable jobs.
> >> Like this, we were successfully able to maintain a fair number of
> >> scenarios and keep our coverage increasing over each cycle.
> >>
> >> I see 2 sub-options here:
> >>
> >> a) Move CI environments and pingtest into
> >> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
> >> is branched and we could add a README to explain these files are used
> >> in CI and we don't guarantee they would work outside TripleO CI tools.
> >> b) Branch tripleo-ci repository. Personally I don't like this solution
> >> because a lot of patches in this repo are not related to OpenStack
> >> versions, which means we would need to backport most of the things
> >> from master.
> >
> >
> > I'd +1 this idea. It sounds like we could make the scenarios generic
> enough
> > to be usable also outside CI? Maybe they can serve as samples?
> > --
> > Giulio Fidente
> > GPG KEY: 08D733BA
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Pike PTL

[Juan Antonio Osorio]

You were an awesome PTL! thanks for all the work.

BR

On Wed, Nov 23, 2016 at 6:04 PM, Henry Nash <henryna...@mac.com> wrote:

> Steve,
>
> It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy
> taking some time back!
>
> Henry
>
> On 21 Nov 2016, at 19:38, Steve Martinelli <s.martine...@gmail.com> wrote:
>
> one of these days i'll learn how to spell :)
>
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli <s.martine...@gmail.com
> > wrote:
>
>> Keystoners,
>>
>> I do not intend to run for the PTL position of the Pike development
>> cycle. I'm sending this out early so I can work with folks interested in
>> the role, If you intend to run for PTL in Pike and are interested in
>> learning the ropes (or just want to hear more about what the role means)
>> then shoot me an email.
>>
>> It's been an unforgettable ride. Being PTL a is very rewarding
>> experience, I encourage anyone interested to put your name forward. I'm
>> not going away from OpenStack, I just think three terms as PTL has been
>> enough. It'll be nice to have my evenings back :)
>>
>> To *all* the keystone contributors (cores and non-cores), thank you for
>> all your time and commitment. More importantly thank you for putting up
>> with my many questions, pings, pokes and -1s. Each of you are amazing and
>> together you make an awesome team. It has been an absolute pleasure to
>> serve as PTL, thank you for letting me do so.
>>
>> stevemar
>>
>>
>> 
>>
>> Thanks for the idea Lana [1]
>> [1] http://lists.openstack.org/pipermail/openstack-docs/2016
>> -November/009357.html
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [barbican] Nominating Arun Kant for barbican-core

[Juan Antonio Osorio]

+1

On 7 Nov 2016 17:18, "Dave McCowan (dmccowan)"  wrote:

>
> Arun has been a long-time terrific reviewer and contributor to Barbican.
>
> 100% +1
>
>
> --Dave
>
> On 11/7/16, 9:37 AM, "Ade Lee"  wrote:
>
> >Hi everyone,
> >
> >I'd like to nominate Arun Kant for the barbican-core team.
> >
> >Arun has been a very active contributor to the project over the past
> >few years, implementing and seeing through major features like ACLs and
> >multiple secret store back-ends.  This includes providing all the
> >required API documentation.
> >
> >He's also been active squashing bugs, and providing helpful and
> >insightful reviews.
> >
> >As a reminder to barbican-core members, we use the voting process
> >outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
> >members to our team.
> >
> >Thanks,
> >Ade
> >
> >
> >___
> ___
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] proposing Michele Baldessari part of core team

[Juan Antonio Osorio]

+1 :D

On 4 Nov 2016 20:16, "Jiří Stránský"  wrote:

> +1, Michele does great reviews, and his contributions around HA and
> upgrades have been crucial.
>
> On 4.11.2016 18:40, Emilien Macchi wrote:
>
>> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
>> levels of contributions in TripleO projects, specifically in High
>> Availability area where's he's for us a guru (I still don't understand
>> how pacemaker works, but hopefully he does).
>>
>> He has done incredible work on composable services and also on
>> improving our HA configuration by following reference architectures.
>> Always here during meetings, and on #tripleo to give support to our
>> team, he's a great team player and we are lucky to have him onboard.
>> I believe he would be a great core reviewer on HA-related work and we
>> expect his review stats to continue improving as his scope broadens
>> over time.
>>
>> As usual, feedback is welcome and please vote for this proposal!
>>
>> Thanks,
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Getting the UI to talk with Undercloud API service endpoints

[Juan Antonio Osorio]

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


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [TripleO] FFE: TLS everywhere in the overcloud

[Juan Antonio Osorio]

Hello,

I've been working on TLS everywhere in the majority of this newton cycle.
And proposed this blueprint https://review.openstack.org/#/c/282307/ (which
has been approved in launchpad) somewhere around May.

There has been a lot of work trying to tackle blockers and doing a lot of
pre-work that needed to happen before this (such as the keystone endpoints
parts) but I think we're in a good track. The composable services/roles
work also slowed this down, as some of that needed to land before this work
could continue.

Here's the topic to follow the on-going work:
https://review.openstack.org/#/q/status:open++branch:master+topic:bp/tls-via-certmonger

The main remaining pieces of work are:
* Getting the services to listen to FQDNs instead of IP addresses (this
will also help us tackle of IPv6 issues)
* TLS for internal endpoints in HAProxy
  - we need to figure out a way to get different internal certificates (one
per network) and get haproxy to choose which to use. This should be easier
thanks to Shardy's work.
* TLS for apache-based services
* TLS for non-apache based services (we might end up proxying this via
apache or something else since we don't want to do crypto in python)

This is certainly not low-risk; but I think it is achievable and would
bring great value to TripleO, as it would allow deployers that were
previously blocked by regulations in their industry to start considering
actually using TripleO.

I was also working on TLS everywhere in the undercloud, but did not get
enough time to figure out some parts of it. So that work will not be
included here.

BR



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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][release] Plans re newton-3 release and feature freeze exceptions

[Juan Antonio Osorio]

On Fri, Aug 26, 2016 at 7:14 PM, Steven Hardy <sha...@redhat.com> wrote:

> Hi all,
>
> There have been some discussions on $subject recently, so I wanted to give
> a status update.
>
> Next week we will tag our newton-3 release, and we're currently working to
> either land or defer the remaining features tracked here:
>
> https://launchpad.net/tripleo/+milestone/newton-3
>
> We need to land as many of the "Needs Code Review" features as we can
> before cutting the release next week, so please help by prioritizing your
> reviews.
>
> --
> Feature Freeze
> --
>
> After newton-3 is released, we'll have reached Feature Freeze for Newton,
> and any features landed after this point must be agreed as feature freeze
> exceptions (everything else will be deferred to Ocata) - the process is to
> mail this list with a justification, and details of which patches need to
> land, then we'll reach consensus over if it will be accepted or not based
> on the level of risk, and the status of the patches.
>
> Currently there are three potential FFEs which I'm aware of:
>
> 1. Mistral API
>
> We've made good progress on this over recent weeks, but several patches
> remain - this is the umbrella BP, and it links several dependent BPs which
> are mostly posted but need code reviews, please help by testing and
> reviewing these:
>
> https://blueprints.launchpad.net/tripleo/+spec/mistral-deployment-library
>
> 2. Composable Roles
>
> There are two parts to this, some remaining cleanups related to per-service
> configuration (such as bind_ip's) which need to land, and the related
> custom-roles feature:
>
> https://bugs.launchpad.net/tripleo/+bug/1604414
>
> https://blueprints.launchpad.net/tripleo/+spec/custom-roles
>
> Some patches still need to be fixed or written to enable custom-roles -
> it's a stretch but I'd say a FFE may be reasonable provided we can get the
> remaining patches functional in the next few days (I'm planning to do this)
>
> 3. Contrail integration
>
> There are patches posted for this, but they need work - Carlos is helping
> so I'd suggest it should be possible to land these as a FFE (should be low
> risk as it's all disabled by default)
>
> https://blueprints.launchpad.net/tripleo/+spec/contrail-services
>
> These are the main features I'm aware of that are targetted to newton-3
> but will probably slip, are there others folks want to raise?
>
Well, https://review.openstack.org/#/c/282307/ is still in progress and
will need an FFE. What's the official process to apply for the exception?

>
> 
> Bugs
> 
>
> Any bugs not fixed by newton-3 will be deferred to an RC1 milestone I
> created, so that we can track remaining release-blocker bugs in the weeks
> leading to the final release.  Please ensure all bugs are targetted to this
> milestone so we don't miss them.
>
> https://launchpad.net/tripleo/+milestone/newton-rc1
>
> Please let me know if there are any questions or concerns, and thanks to
> everyone for all the help getting to this point, it's been a tough but
> productive cycle, and I'm looking forward to reaching our final newton
> release! :)
>
> Thanks,
>
> Steve
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] [keystone][tripleo] Federation, mod_mellon, and HA Proxy

[Juan Antonio Osorio]

Adam, that should be fixed by https://review.openstack.org/#/c/341354/
which merged not too many days ago. Before that commit we had another
configuration which was already deprecated in keystone upstream.

On 6 Aug 2016 05:04, "Adam Young"  wrote:

> On 08/05/2016 06:40 PM, Fox, Kevin M wrote:
>
> --
> *From:* Adam Young [ayo...@redhat.com]
> *Sent:* Friday, August 05, 2016 3:06 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] [keystone][tripleo] Federation,
> mod_mellon, and HA Proxy
>
> On 08/05/2016 04:54 PM, Adam Young wrote:
>
> On 08/05/2016 04:52 PM, Adam Young wrote:
>
> Today I discovered that we need to modify the HA proxy config to tell it
> to rewrite redirects.  Otherwise, I get a link to
>
> http://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse
>
>
> Which should be https, not http.
>
>
> I mimicked the lines in the horizon config so that the keystone section
> looks like this:
>
>
> listen keystone_public
>   bind 10.0.0.4:13000 transparent ssl crt
> /etc/pki/tls/private/overcloud_endpoint.pem
>   bind 172.16.2.5:5000 transparent
>   mode http
>   redirect scheme https code 301 if { hdr(host) -i 10.0.0.4 } !{ ssl_fc }
>   rsprep ^Location:\ http://(.*)  Location:\
> https://\1
>   http-request set-header X-Forwarded-Proto https if { ssl_fc }
>   http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
>   server overcloud-controller-0 172.16.2.8:5000 check fall 5 inter 2000
> rise 2
>   server overcloud-controller-1 172.16.2.6:5000 check fall 5 inter 2000
> rise 2
>   server overcloud-controller-2 172.16.2.9:5000 check fall 5 inter 2000
> rise 2
>
> And.. it seemed to work the first time, but not the second.  Now I get
>
> "Secure Connection Failed
>
> The connection to openstack.ayoung-dell-t1700.test:5000 was interrupted
> while the page was loading."
>
> Guessing the first success was actually a transient error.
>
> So it looks like my change was necessary but not sufficient.
>
> This is needed to make mod_auth_mellon work when loaded into Apache, and
> Apache is running behind  HA proxy (Tripleo setup).
>
>
> There is no SSL setup inside the Keystone server, it is just doing
> straight HTTP.  While I'd like to change this long term, I'd like to get
> things working this way first, but am willing to make whatever changes are
> needed to get SAML and Federation working soonest.
>
>
>
>
> Ah...just noticed the redirect is to :5000, not port :13000 which is the
> HA Proxy port.
>
>
> OK, this is due to the SAML request:
>
>
>  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> ID="_5089011BEBD0F6B82074F67E904F598D"
> Version="2.0"
> IssueInstant="2016-08-05T21:55:18Z"
> 
> Destination="https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml;
>  
> 
> Consent="urn:oasis:names:tc:SAML:2.0:consent:current-implicit"
> ForceAuthn="false"
> IsPassive="false"
> 
> AssertionConsumerServiceURL="https://openstack.ayoung-dell-t1700.test:5000/v3/mellon/postResponse;
>  
> >
> 
> https://openstack.ayoung-dell-t1700.test:5000/v3/mellon/metadata
>  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> AllowCreate="true"
> />
> 
>
>
> My guess is HA proxy is not passing on the proper, and the mod_auth_mellon
> does not know to rewrite it from 5000 to 13000
>
>
> "rewriting is more expensive then getting the web server to return the
> right prefix. Is that an option? Usually its just a bug that needs a minor
> patch to fix.
>
> Thanks,
> Kevin"
>
>
> Well, I think in this case, the expense is not something to worry about:
> SAML is way more chatty than normal traffic, and the rewrite won't be a
> drop a in the bucket.
>
> I think the right thing to do is to get HA proxy top pass on the correct
> URL, including the port, to the backend, but I don't think it is done in
> the rsprep directive.  As John Dennis pointed out to me, the
> mod_auth_mellon code uses the apache ap_construct_url(r->pool,
> cfg->endpoint_path, r) where r is the current request record.  And that has
> to be passed from HA proxy to Apache.
>
> HA proxy is terminating SSL, and then calling Apache via
>
>
>   server overcloud-controller-0 172.16.2.8:5000 check fall 5 inter 2000
> rise 2
> and two others.  Everything appears to be properly translated except the
> port.
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Tripleo] X509 Management

[Juan Antonio Osorio]

On Tue, Jun 21, 2016 at 10:51 PM, Adam Young <ayo...@redhat.com> wrote:

> On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
>
> Adam, this is pretty much the proposal for TLS for the internal services
> (which you were added already as a reviewer for the spec)
> https://review.openstack.org/#/c/282307/
> The services in the overcloud fetching their certificates via certmonger
> is actually work in progress, which you could review here:
> https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
> Only thing is that currently this approach assumes FreeIPA, so the nodes
> need to be registered beforehand (and then trigger self-enrollment via some
> hooks).
> Also, the spec that I'm pointing to doesn't require the CA to be the in
> undercloud and it could be another node. But hey, if we could deploy Anchor
> on the Undercloud, then that could be used, so we wouldn't need another
> node for this means.
>
>
>
> Yes, I was basing my proposal her around your work.  I want there to be
> something guaranteed for Certmonger to talk to, and I realize that Heat can
> probably play that role.
>
> Anchor might also be viable here, I just don't want to force it as a
> dependency.  We are talking the selfsigned use case here, so it should be
> minimal overhead.
>

 I think it's a better idea to have Anchor as a dependency than try to brew
CA functionality into Heat via os-*-config. Maybe a Heat person can answer
this? Then for more complex use-cases we can use FreeIPA. Do we have Anchor
packetized in RDO?

>
> Anyway, in each of the service's profiles (the puppet manifests) I'm
> setting up the tracking of the certificates with the certmonger's puppet
> manifest.
>
> BR
>
> On Tue, Jun 21, 2016 at 5:39 PM, Adam Young <ayo...@redhat.com> wrote:
>
>> When deploying the overcloud with TLS, the current "no additional
>> technology" approach is to use opensssl and self signed.  While this works
>> for a Proof of concept, it does not make sense if the users need to access
>> the resources from remote systems.
>>
>> It seems to me that the undercloud, as the system of record for deploying
>> the overcloud, should be responsible for centralizing the signing of
>> certificates.
>>
>> When deploying a service, the puppet module sure trigger a getcert call,
>> which registers the cert with  Certmonger.  Certmonger is responsible for
>> making sure the CSR gets to the signing authority, and fetching the cert.
>>
>> Certmonger works via helper apps.  While there is currently a "self
>> signed" helper, this does not do much if two or more systems need to have
>> the same CA sign their certs.
>>
>> It would be fairly simple to write a certmonger helper program that sends
>> a CSR from a controller or compute node to the undercloud, has the Heat
>> instance on the undercloud validate the request, and then pass it on to the
>> signing application.
>>
>> I'm not really too clear on how callbacks are  done from the
>> os-collect-config processes to Heat, but I am guessing it is some form of
>> Rest API that could be reused for this work flow?
>>
>>
>> I would see this as the lowest level of deployment.  We can make use of
>> Anchor or Dogtag helper apps already.  This might also prove a decent
>> middleground for people that need an automated approach to tie in with a
>> third party CA, where they need some confirmation from the deployment
>> process that the data in the CSR is valid and should be signed.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] X509 Management

[Juan Antonio Osorio]

Adam, this is pretty much the proposal for TLS for the internal services
(which you were added already as a reviewer for the spec)
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via certmonger is
actually work in progress, which you could review here:
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the nodes
need to be registered beforehand (and then trigger self-enrollment via some
hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the in
undercloud and it could be another node. But hey, if we could deploy Anchor
on the Undercloud, then that could be used, so we wouldn't need another
node for this means.

Anyway, in each of the service's profiles (the puppet manifests) I'm
setting up the tracking of the certificates with the certmonger's puppet
manifest.

BR

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young <ayo...@redhat.com> wrote:

> When deploying the overcloud with TLS, the current "no additional
> technology" approach is to use opensssl and self signed.  While this works
> for a Proof of concept, it does not make sense if the users need to access
> the resources from remote systems.
>
> It seems to me that the undercloud, as the system of record for deploying
> the overcloud, should be responsible for centralizing the signing of
> certificates.
>
> When deploying a service, the puppet module sure trigger a getcert call,
> which registers the cert with  Certmonger.  Certmonger is responsible for
> making sure the CSR gets to the signing authority, and fetching the cert.
>
> Certmonger works via helper apps.  While there is currently a "self
> signed" helper, this does not do much if two or more systems need to have
> the same CA sign their certs.
>
> It would be fairly simple to write a certmonger helper program that sends
> a CSR from a controller or compute node to the undercloud, has the Heat
> instance on the undercloud validate the request, and then pass it on to the
> signing application.
>
> I'm not really too clear on how callbacks are  done from the
> os-collect-config processes to Heat, but I am guessing it is some form of
> Rest API that could be reused for this work flow?
>
>
> I would see this as the lowest level of deployment.  We can make use of
> Anchor or Dogtag helper apps already.  This might also prove a decent
> middleground for people that need an automated approach to tie in with a
> third party CA, where they need some confirmation from the deployment
> process that the data in the CSR is valid and should be signed.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] Proposed TripleO core changes

[Juan Antonio Osorio]

+1 on my side.
On 9 Jun 2016 18:10, "Emilien Macchi"  wrote:

> On Thu, Jun 9, 2016 at 10:03 AM, Steven Hardy  wrote:
> > Hi all,
> >
> > I've been in discussion with Martin André and Tomas Sedovic, who are
> > involved with the creation of the new tripleo-validations repo[1]
> >
> > We've agreed that rather than create another gerrit group, they can be
> > added to tripleo-core and agree to restrict +A to this repo for the time
> > being (hopefully they'll both continue to review more widely, and
> obviously
> > Tomas is a former TripleO core anyway, so welcome back! :)
> >
> > If folks feel strongly we should create another group we can, but this
> > seems like a low-overhead approach, and well aligned with the scope of
> the
> > repo, let me know if you disagree.
>
> +1 on my side too. I think in this case it's a good choice.
>
> > Also, while reviewing the core group[2] I noticed the following members
> who
> > are no longer active and should probably be removed:
> >
> > - Radomir Dopieralski
> > - Martyn Taylor
> > - Clint Byrum
> >
> > I know Clint is still involved with DiB (which has a separate core
> group),
> > but he's indicated he's no longer going to be directly involved in other
> > tripleo development, and AFAIK neither Martyn or Radomir are actively
> > involved in TripleO reviews - thanks to them all for their contribution,
> > we'll gladly add you back in the future should you wish to return :)
> >
> > Please let me know if there are any concerns or objections, if there are
> > none I will make these changes next week.
> >
> > Thanks,
> >
> > Steve
> >
> > [1] https://github.com/openstack/tripleo-validations
> > [2] https://review.openstack.org/#/admin/groups/190,members
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Issues with gate-barbican-python27

[Juan Antonio Osorio]

This happened because of a change in oslo.messaging that we didn't react
fast enough to.

I have already submitted a bug report
https://bugs.launchpad.net/barbican/+bug/1580461 which is the recommended
approach if something like this is noticed. Thanks for notifying us in the
mailing list though.

I'm working on a fix.

BR

On Wed, May 11, 2016 at 12:19 AM, Freddy Pedraza <
freddy.pedr...@rackspace.com> wrote:

> Hi,
>
> I submitted a simple CR (https://review.openstack.org/#/c/312786) and
> "gate-barbican-python27” is failing and I think it's caused by something
> else upstream. These are the issues that I see in the console log
>
> FAIL:
> barbican.tests.queue.test_keystone_listener.WhenUsingMessageServer.test_keystone_notification_pool_size_used
> FAIL:
> barbican.tests.queue.test_keystone_listener.WhenUsingMessageServer.test_should_start
> FAIL:
> barbican.tests.queue.test_keystone_listener.WhenUsingMessageServer.test_should_stop
> FAIL:
> barbican.tests.queue.test_keystone_listener.WhenUsingMessageServer.test_should_wait
>
> ERROR: InvocationError:
> '/home/jenkins/workspace/gate-barbican-python27/.tox/py27/bin/python
> setup.py testr --coverage --testr-args=‘
> __ summary
> 
> ERROR:   py27: commands failed
>
> More details at —>
> http://logs.openstack.org/86/312786/2/check/gate-barbican-python27/833bcc2/console.html#_2016-05-10_20_29_16_472
>
> Any ideas on what’s going on?
>
> Thanks in Advance
>
> Freddy Pedraza
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] FreeIPA integration

[Juan Antonio Osorio]

lly want to re implement Rippowam in Puppet.
>
> As we are using Puppet for our configuration I think this is currently
> a requirement. There are many good puppet examples out there of various
> servers and a quick google search showed some IPA modules are available
> as well.
>
> I think most TripleO users are quite happy in using puppet modules for
> configuration in that the puppet openstack modules are quite mature and
> well tested. Making a one-off exception for FreeIPA at this point
> doesn't make sense to me.
>
> >
> > So, big question: is Heat->ansible (instead of Puppet) for an
> > overcloud
> > deployment an acceptable path?  We are talking Ansible 1.0
> > Playbooks,
> > which should be relatively straightforward ports to 2.0 when the time
> > comes.
> >
> > Thus, the sequence would be:
> >
> > 1. Run existing overcloud deploy steps.
> > 2. Install IPA server on the allocated VM
> > 3. Register the compute nodes and the controller as IPA clients
> > 4. Convert service users over to LDAP backed services, complete with
> > necessary kerberos steps to do password-less authentication.
> > 5. Register all web services with IPA and allocate X509 certificates
> > for
> > HTTPS.
> > 6. Set up Host based access control (HBAC) rules for SSH access to
> > overcloud machines.
> >
> >
> > When we did the Rippowam demo, we used the Proton driver and
> > Kerberos
> > for securing the message broker.  Since Rabbit seems to be the tool
> > of
> > choice,  we would use X509 authentication and TLS for
> > encryption.  ACLs,
> > for now, would stay in the flat file format.  In the future, we
> > might
> > chose to use the LDAP backed ACLs for Rabbit, as they seem far more
> > flexible.  Rabbit does not currently support Kerberos for either
> > authentication or encryption, but we can engage the upstream team to
> > implement it if desired in the future, or we can shift to a Proton
> > based
> > deployment if Kerberos is essential for a deployment.
> >
> >
> > There are a couple ongoing efforts that will tie in with this:
> >
> > 1. Designate should be able to use the DNS from FreeIPA.  That was
> > the
> > original implementation.
> >
> > 2.  Juan Antonio Osorio  has been working on TLS everywhere.  The
> > issue
> > thus far has been Certificate management.  This provides a Dogtag
> > server
> > for Certs.
> >
> > 3. Rob Crittenden has been working on auto-registration of virtual
> > machines with an Identity Provider upon launch.  This gives that
> > efforts
> > an IdM to use.
> >
> > 4. Keystone can make use of the Identity store for administrative
> > users
> > in their own domain.
> >
> > 5. Many of the compliance audits have complained about cleartext
> > passwords in config files. This removes most of them.  MySQL
> > supports
> > X509 based authentication today, and there is Kerberos support in
> > the
> > works, which should remove the last remaining cleartext Passwords.
> >
> > I mentioned Centralized SUDO and HBAC.  These are both tools that may
> > be
> > used by administrators if so desired on the install. I would
> > recommend
> > that they be used, but there is no requirement to do so.
> >
> >
> >
> >
> >
> >
> >
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing 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] FreeIPA integration

[Juan Antonio Osorio]

I was planning to bring it up informally for TripleO. But it would be cool
to have a slot to talk about this.

BR
On 5 Apr 2016 18:51, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

> Yeah, and they just deprecated vendor data plugins too, which eliminates
> my other workaround. :/
>
> We need to really discuss this problem at the summit and get a viable path
> forward. Its just getting worse. :/
>
> Thanks,
> Kevin
> ----------
> *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> *Sent:* Tuesday, April 05, 2016 5:16 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>
>
>
> On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>
>> This sounds suspiciously like, "how do you get a secret to the instance
>> to get a secret from the secret store" issue :)
>>
> Yeah, sounds pretty familiar. We were using the nova hooks mechanism for
> this means, but it was deprecated recently. So bummer :/
>
>>
>> Nova instance user spec again?
>>
>> Thanks,
>> Kevin
>>
>> --
>> *From:* Juan Antonio Osorio
>> *Sent:* Tuesday, April 05, 2016 4:07:06 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>>
>>
>>
>> On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <sha...@redhat.com> wrote:
>>
>>> On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
>>> > I finally have enough understanding of what is going on with Tripleo to
>>> > reasonably discuss how to implement solutions for some of the main
>>> security
>>> > needs of a deployment.
>>> >
>>> >
>>> > FreeIPA is an identity management solution that can provide support
>>> for:
>>> >
>>> > 1. TLS on all network communications:
>>> >A. HTTPS for web services
>>> >B. TLS for the message bus
>>> >C. TLS for communication with the Database.
>>> > 2. Identity for all Actors in the system:
>>> >   A.  API services
>>> >   B.  Message producers and consumers
>>> >   C.  Database consumers
>>> >   D.  Keystone service users
>>> > 3. Secure  DNS DNSSEC
>>> > 4. Federation Support
>>> > 5. SSH Access control to Hosts for both undercloud and overcloud
>>> > 6. SUDO management
>>> > 7. Single Sign On for Applications running in the overcloud.
>>> >
>>> >
>>> > The main pieces of FreeIPA are
>>> > 1. LDAP (the 389 Directory Server)
>>> > 2. Kerberos
>>> > 3. DNS (BIND)
>>> > 4. Certificate Authority (CA) server (Dogtag)
>>> > 5. WebUI/Web Service Management Interface (HTTPD)
>>> >
>>> > Of these, the CA is the most critical.  Without a centralized CA, we
>>> have no
>>> > reasonable way to do certificate management.
>>> >
>>> > Now, I know a lot of people have an allergic reaction to some, maybe
>>> all, of
>>> > these technologies. They should not be required to be running in a
>>> > development or testbed setup.  But we need to make it possible to
>>> secure an
>>> > end deployment, and FreeIPA was designed explicitly for these kinds of
>>> > distributed applications.  Here is what I would like to implement.
>>> >
>>> > Assuming that the Undercloud is installed on a physical machine, we
>>> want to
>>> > treat the FreeIPA server as a managed service of the undercloud that
>>> is then
>>> > consumed by the rest of the overcloud. Right now, there are conflicts
>>> for
>>> > some ports (8080 used by both swift and Dogtag) that prevent a drop-in
>>> run
>>> > of the server on the undercloud controller.  Even if we could
>>> deconflict,
>>> > there is a possible battle between Keystone and the FreeIPA server on
>>> the
>>> > undercloud.  So, while I would like to see the ability to run the
>>> FreeIPA
>>> > server on the Undercloud machine eventuall, I think a more realistic
>>> > deployment is to build a separate virtual machine, parallel to the
>>> overcloud
>>> > controller, and install FreeIPA there. I've been able to modify Tripleo
>>> > Quickstart to provision this VM.
>>>
>>> IMO these servi

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

Having an extra node for FreeIPA spawn up by heat works for me. And it's
not a hard-requirement that we have to wire this into the TripleO CI. But
the most sustainable approach to having TLS everywhere (at least for the
admin and internal endpoints of Openstack, the message broker server nodes
and the database) is using FreeIPA as a CA. So if we advertise (at some
point) that TripleO will support such a feature, then it's probably a good
idea to have it in the official CI.

BR

On Tue, Apr 5, 2016 at 4:01 PM, Steven Hardy <sha...@redhat.com> wrote:

> On Tue, Apr 05, 2016 at 02:07:06PM +0300, Juan Antonio Osorio wrote:
> >On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <sha...@redhat.com>
> wrote:
> >
> >  On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
> >  > I finally have enough understanding of what is going on with
> Tripleo
> >  to
> >  > reasonably discuss how to implement solutions for some of the main
> >  security
> >  > needs of a deployment.
> >  >
> >  >
> >  > FreeIPA is an identity management solution that can provide
> support
> >  for:
> >  >
> >  > 1. TLS on all network communications:
> >  >Â  Â  A. HTTPS for web services
> >  >Â  Â  B. TLS for the message bus
> >  >Â  Â  C. TLS for communication with the Database.
> >  > 2. Identity for all Actors in the system:
> >  >   A.  API services
> >  >   B.  Message producers and consumers
> >  >   C.  Database consumers
> >  >   D.  Keystone service users
> >  > 3. Secure  DNS DNSSEC
> >  > 4. Federation Support
> >  > 5. SSH Access control to Hosts for both undercloud and overcloud
> >  > 6. SUDO management
> >  > 7. Single Sign On for Applications running in the overcloud.
> >  >
> >  >
> >  > The main pieces of FreeIPA are
> >  > 1. LDAP (the 389 Directory Server)
> >  > 2. Kerberos
> >  > 3. DNS (BIND)
> >  > 4. Certificate Authority (CA) server (Dogtag)
> >  > 5. WebUI/Web Service Management Interface (HTTPD)
> >  >
> >  > Of these, the CA is the most critical.  Without a centralized
> CA, we
> >  have no
> >  > reasonable way to do certificate management.
> >  >
> >  > Now, I know a lot of people have an allergic reaction to some,
> maybe
> >  all, of
> >  > these technologies. They should not be required to be running in a
> >  > development or testbed setup.  But we need to make it possible to
> >  secure an
> >  > end deployment, and FreeIPA was designed explicitly for these
> kinds of
> >  > distributed applications.  Here is what I would like to
> implement.
> >  >
> >  > Assuming that the Undercloud is installed on a physical machine,
> we
> >  want to
> >  > treat the FreeIPA server as a managed service of the undercloud
> that
> >  is then
> >  > consumed by the rest of the overcloud. Right now, there are
> conflicts
> >  for
> >  > some ports (8080 used by both swift and Dogtag) that prevent a
> drop-in
> >  run
> >  > of the server on the undercloud controller.  Even if we could
> >  deconflict,
> >  > there is a possible battle between Keystone and the FreeIPA
> server on
> >  the
> >  > undercloud.  So, while I would like to see the ability to run the
> >  FreeIPA
> >  > server on the Undercloud machine eventuall, I think a more
> realistic
> >  > deployment is to build a separate virtual machine, parallel to the
> >  overcloud
> >  > controller, and install FreeIPA there. I've been able to modify
> >  Tripleo
> >  > Quickstart to provision this VM.
> >
> >  IMO these services shouldn't be deployed on the undercloud - we only
> >  support a single node undercloud, and atm it's completely possible
> to
> >  take
> >  the undercloud down without any impact to your deployed cloud (other
> >  than
> >  losing the ability to manage it temporarily).
> >
> >This is fair enough, however, for CI purposes, would it be acceptable
> to
> >deploy it there? Or where do you recommend we have it?
>
> We're already well beyond capacity in CI, so to me this seems like
> something that's probably appropriate for a third-party CI job?
&g

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> This sounds suspiciously like, "how do you get a secret to the instance to
> get a secret from the secret store" issue :)
>
Yeah, sounds pretty familiar. We were using the nova hooks mechanism for
this means, but it was deprecated recently. So bummer :/

>
> Nova instance user spec again?
>
> Thanks,
> Kevin
>
> ------
> *From:* Juan Antonio Osorio
> *Sent:* Tuesday, April 05, 2016 4:07:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>
>
>
> On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <sha...@redhat.com> wrote:
>
>> On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
>> > I finally have enough understanding of what is going on with Tripleo to
>> > reasonably discuss how to implement solutions for some of the main
>> security
>> > needs of a deployment.
>> >
>> >
>> > FreeIPA is an identity management solution that can provide support for:
>> >
>> > 1. TLS on all network communications:
>> >A. HTTPS for web services
>> >B. TLS for the message bus
>> >C. TLS for communication with the Database.
>> > 2. Identity for all Actors in the system:
>> >   A.  API services
>> >   B.  Message producers and consumers
>> >   C.  Database consumers
>> >   D.  Keystone service users
>> > 3. Secure  DNS DNSSEC
>> > 4. Federation Support
>> > 5. SSH Access control to Hosts for both undercloud and overcloud
>> > 6. SUDO management
>> > 7. Single Sign On for Applications running in the overcloud.
>> >
>> >
>> > The main pieces of FreeIPA are
>> > 1. LDAP (the 389 Directory Server)
>> > 2. Kerberos
>> > 3. DNS (BIND)
>> > 4. Certificate Authority (CA) server (Dogtag)
>> > 5. WebUI/Web Service Management Interface (HTTPD)
>> >
>> > Of these, the CA is the most critical.  Without a centralized CA, we
>> have no
>> > reasonable way to do certificate management.
>> >
>> > Now, I know a lot of people have an allergic reaction to some, maybe
>> all, of
>> > these technologies. They should not be required to be running in a
>> > development or testbed setup.  But we need to make it possible to
>> secure an
>> > end deployment, and FreeIPA was designed explicitly for these kinds of
>> > distributed applications.  Here is what I would like to implement.
>> >
>> > Assuming that the Undercloud is installed on a physical machine, we
>> want to
>> > treat the FreeIPA server as a managed service of the undercloud that is
>> then
>> > consumed by the rest of the overcloud. Right now, there are conflicts
>> for
>> > some ports (8080 used by both swift and Dogtag) that prevent a drop-in
>> run
>> > of the server on the undercloud controller.  Even if we could
>> deconflict,
>> > there is a possible battle between Keystone and the FreeIPA server on
>> the
>> > undercloud.  So, while I would like to see the ability to run the
>> FreeIPA
>> > server on the Undercloud machine eventuall, I think a more realistic
>> > deployment is to build a separate virtual machine, parallel to the
>> overcloud
>> > controller, and install FreeIPA there. I've been able to modify Tripleo
>> > Quickstart to provision this VM.
>>
>> IMO these services shouldn't be deployed on the undercloud - we only
>> support a single node undercloud, and atm it's completely possible to take
>> the undercloud down without any impact to your deployed cloud (other than
>> losing the ability to manage it temporarily).
>>
> This is fair enough, however, for CI purposes, would it be acceptable to
> deploy it there? Or where do you recommend we have it?
>
>>
>> These auth pieces all appear critical to the operation of the deployed
>> cloud, thus I'd assume you really want them independently managed
>> (probably
>> in an HA configuration on multiple nodes)?
>>
>> So, I'd say we support one of:
>>
>> 1. Document that FreeIPA must exist, installed by existing non-TripleO
>> tooling
>>
>> 2. Support a heat template (in addition to overcloud.yaml) that can deploy
>> FreeIPA.
>>
>> I feel like we should do (1), as it fits better with the TripleO vision
>> (which is to deploy OpenStack), and it removes the need for us to maintain
>> a bunch 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

g
> proven IPA environment in as a tripleo/heat environment file - same model
> we already support for all kinds of vendor integration, SSL etc etc.
>
> > The IdM team did just this last summer in preparing for the Tokyo summit,
> > using Ansible and Packstack.  The Rippowam project
> > https://github.com/admiyo/rippowam was able to fully lock down a
> Packstack
> > based install.  I'd like to reuse as much of Rippowam as possible, but
> > called from Heat Templates as part of an overcloud deploy.  I do not
> really
> > want to re implement Rippowam in Puppet.
> >
> > So, big question: is Heat->ansible (instead of Puppet) for an overcloud
> > deployment an acceptable path?  We are talking Ansible 1.0 Playbooks,
> which
> > should be relatively straightforward ports to 2.0 when the time comes.
>
> In short, no.  I don't see how you can do the hardening with ansible,
> unless you're proposing to reimplement the entire overcloud deployment in
> the same tool.
>
> The data required to configure the OpenStack services should be passed in
> via an environment file, e.g
>
> openstack overcloud deploy --templates -e ipa-params.yaml
>
> Then all the data from ipa-params.yaml should be mapped into hieradata
> which puppet then uses to configure the OpenStack services appropriately -
> this is the same model we support for integration with  everything atm.
>
> While it's technically possible to configure an overcloud, then reconfigure
> it with some other tool (or even manually), you get the worst of all worlds
> doing this - you modify things out-of-band (from a TripleO perspective) so
> that all your changed get destroyed every overcloud update, and you run the
> risk of "config management split brain" where e.g puppet configures a
> service disabled, then ansible starts it or whatever.
>
> > Thus, the sequence would be:
> >
> > 1. Run existing overcloud deploy steps.
> > 2. Install IPA server on the allocated VM
> > 3. Register the compute nodes and the controller as IPA clients
> > 4. Convert service users over to LDAP backed services, complete with
> > necessary kerberos steps to do password-less authentication.
> > 5. Register all web services with IPA and allocate X509 certificates for
> > HTTPS.
> > 6. Set up Host based access control (HBAC) rules for SSH access to
> overcloud
> > machines.
>
> This should be:
>
> 1. Install and validate IPA server $somewhere
> 2. Generate environment file with parameters (this could be automated)
> 3. Install overcloud passing in environment file with IPA $stuff
> 4. Done
>
This is an acceptable solution IMO and was according to what I was
thinking. It will also be easier to setup the overcloud with FreeIPA
specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is.
To me, for testing purposes it seemed acceptable to have FreeIPA running in
the same node as the undercloud. And in production it would be a separate
node (or set of nodes).

>
> Basically *anything* touching the overcloud configuration should happen via
> puppet in our current architecture, which I think means (4) and (5).
>
> I'm less clear about (3) - this sounds like an IPA admin action, can it be
> done before deploying the overcloud, or do we need each node to register
> itself?
>
The nodes need to get the IPA client installation which pretty much
involves enrollment. For this, they need to have some type of credentials.
So this is the main thing Rob is working towards. To have a safe method to
pass credentials to the nodes, and have them autoregister to FreeIPA.

>
> Similarly not sure about (6), probably need more info about what that
> entails.
>
> > When we did the Rippowam demo, we used the Proton driver and Kerberos for
> > securing the message broker.  Since Rabbit seems to be the tool of
> choice,
> > we would use X509 authentication and TLS for encryption.  ACLs, for now,
> > would stay in the flat file format.  In the future, we might chose to use
> > the LDAP backed ACLs for Rabbit, as they seem far more flexible.  Rabbit
> > does not currently support Kerberos for either authentication or
> encryption,
> > but we can engage the upstream team to implement it if desired in the
> > future, or we can shift to a Proton based deployment if Kerberos is
> > essential for a deployment.
> >
> >
> > There are a couple ongoing efforts that will tie in with this:
> >
> > 1. Designate should be able to use the DNS from FreeIPA.  That was the
> > original implementation.
> >
> > 2.  Juan Antonio Osorio  has been working on TLS everywhere.  The issue

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

p Host based access control (HBAC) rules for SSH access to
> overcloud machines.
>
>
> When we did the Rippowam demo, we used the Proton driver and Kerberos for
> securing the message broker.  Since Rabbit seems to be the tool of choice,
> we would use X509 authentication and TLS for encryption.  ACLs, for now,
> would stay in the flat file format.  In the future, we might chose to use
> the LDAP backed ACLs for Rabbit, as they seem far more flexible.  Rabbit
> does not currently support Kerberos for either authentication or
> encryption, but we can engage the upstream team to implement it if desired
> in the future, or we can shift to a Proton based deployment if Kerberos is
> essential for a deployment.
>
>
> There are a couple ongoing efforts that will tie in with this:
>
> 1. Designate should be able to use the DNS from FreeIPA.  That was the
> original implementation.
>
> 2.  Juan Antonio Osorio  has been working on TLS everywhere.  The issue
> thus far has been Certificate management.  This provides a Dogtag server
> for Certs.
>
> 3. Rob Crittenden has been working on auto-registration of virtual
> machines with an Identity Provider upon launch.  This gives that efforts an
> IdM to use.
>
> 4. Keystone can make use of the Identity store for administrative users in
> their own domain.
>
> 5. Many of the compliance audits have complained about cleartext passwords
> in config files. This removes most of them.  MySQL supports X509 based
> authentication today, and there is Kerberos support in the works, which
> should remove the last remaining cleartext Passwords.
>
> I mentioned Centralized SUDO and HBAC.  These are both tools that may be
> used by administrators if so desired on the install. I would recommend that
> they be used, but there is no requirement to do so.
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev