Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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 ?
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
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
