Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

On Sat, Jun 16, 2018 at 12:47:10PM +, Jeremy Stanley wrote: > On 2018-06-15 23:15:01 -0700 (-0700), Emilien Macchi wrote: > [...] > > ## Dockerhub proxy issue > > Infra using wrong image layer object storage proxy for Dockerhub: > > https://review.openstack.org/#/c/575787/ > > Huge thanks to

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

On 2018-06-15 23:15:01 -0700 (-0700), Emilien Macchi wrote: [...] > ## Dockerhub proxy issue > Infra using wrong image layer object storage proxy for Dockerhub: > https://review.openstack.org/#/c/575787/ > Huge thanks to infra team, specially Clark for fixing this super quickly, > it clearly

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

Sending an update before the weekend: Gate was in very bad shape today (long queue, lot of failures) again today, and it turns out we had a few more issues that we tracked here: https://etherpad.openstack.org/p/tripleo-gate-issues-june-2018 ## scenario007 broke because of a patch in

Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

On Mon, Jun 4, 2018 at 6:26 PM, Emilien Macchi wrote: > TL;DR: we made nice progress and you can checkout this demo: > https://asciinema.org/a/185533 > > We started the discussion back in Dublin during the last PTG. The idea of > Standalone (aka All-In-One, but can be mistaken with all-in-one

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Fri, Jun 15, 2018 at 2:13 AM Michele Baldessari wrote: > On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: > > During the Storyboard session today: > > https://etherpad.openstack.org/p/continuing-the-migration-lp-sb > > > > We mentioned that TripleO would continue to migrate

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On Thu, Jun 14, 2018 at 11:03 PM Michele Baldessari wrote: > > +1 > > On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote: > > Alan Bishop has been highly involved in the Storage backends integration in > > TripleO and Puppet modules, always here to update with new features, fix >

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Fri, Jun 15, 2018 at 3:12 AM, Michele Baldessari wrote: > On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: >> During the Storyboard session today: >> https://etherpad.openstack.org/p/continuing-the-migration-lp-sb >> >> We mentioned that TripleO would continue to migrate during

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: > During the Storyboard session today: > https://etherpad.openstack.org/p/continuing-the-migration-lp-sb > > We mentioned that TripleO would continue to migrate during Rocky cycle. > Like Alex mentioned in this thread, we need to

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration in > TripleO and Puppet modules, always here to update with new features, fix > (nasty and untestable third-party backends) bugs and manage all the >

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

It sounds like we merged a bunch last night thanks to the revert, so I went ahead and restored/rechecked everything that was out of the gate. I've checked and nothing was left over, but let me know in case I missed something. I'll keep updating this thread with the progress made to improve the

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

On 06/13/2018 07:50 PM, Emilien Macchi wrote: TL;DR: gate queue was 25h+, we put all patches from gate on standby, do not restore/recheck until further announcement. We recently enabled the containerized undercloud for multinode jobs and we believe this was a bit premature as the container

[openstack-dev] [tripleo][heat][jinja] resources.RedisVirtualIP: Property error: resources.VipPort.properties.network: Error validating value 'internal_api': Unable to find network with name or id 'in

I am trying to delete the Storage, StorageMgmt, Tenant, and Management networks and trying to deploy using TripleO. The following patch https://hamzy.fedorapeople.org/0001-RedisVipPort-error-internal_api.patch applied on top of /usr/share/openstack-tripleo-heat-templates from

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

On 6/14/18 3:50 AM, Emilien Macchi wrote: TL;DR: gate queue was 25h+, we put all patches from gate on standby, do not restore/recheck until further announcement. We recently enabled the containerized undercloud for multinode jobs and we believe this was a bit premature as the container

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On 13.6.2018 17:50, Emilien Macchi wrote: Alan Bishop has been highly involved in the Storage backends integration in TripleO and Puppet modules, always here to update with new features, fix (nasty and untestable third-party backends) bugs and manage all the backports for stable releases:

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1. Well deserved. On Thu, Jun 14, 2018 at 11:08 AM, Bogdan Dobrelya wrote: > On 6/13/18 6:50 PM, Emilien Macchi wrote: >> >> Alan Bishop has been highly involved in the Storage backends integration >> in TripleO and Puppet modules, always here to update with new features, fix >> (nasty and

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

On 6/13/18 6:50 PM, Emilien Macchi wrote: Alan Bishop has been highly involved in the Storage backends integration in TripleO and Puppet modules, always here to update with new features, fix (nasty and untestable third-party backends) bugs and manage all the backports for stable releases:

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration in > TripleO and Puppet modules, always here to update with new features, fix > (nasty and untestable third-party backends) bugs and manage all the > backports for

Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

https://review.openstack.org/575264 just landed (and didn't timeout in check nor gate without recheck, so good sigh it helped to mitigate). I've restore and rechecked some patches that I evacuated from the gate, please do not restore others or recheck or approve anything for now, and see how it

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 Regards, Saravanan KR On Wed, Jun 13, 2018 at 9:20 PM, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration in > TripleO and Puppet modules, always here to update with new features, fix > (nasty and untestable third-party backends) bugs and manage

[openstack-dev] [tripleo] zuul change gating repo name change

Greetings, Please be aware the yum repo created in tripleo ci jobs is going to change names to include the release [1]. This is done to ensure that only the appropriate patches are installed when patches from multiple branches are in play. This is especially important to upgrade jobs. If you

[openstack-dev] [tripleo] tripleo gate is blocked - please read

TL;DR: gate queue was 25h+, we put all patches from gate on standby, do not restore/recheck until further announcement. We recently enabled the containerized undercloud for multinode jobs and we believe this was a bit premature as the container download process wasn't optimized so it's not

Re: [openstack-dev] TripleO NeutronNetworkVLANRanges

On Thu, Jun 14, 2018 at 12:50 AM, Remo Mattei wrote: > Hello guys, just want to double check and make sure that this option can > be ignored if using vxlan. > > NeutronNetworkVLANRanges (used in the network isolation template) > > Hi Remo, this parameter maps to the neutron config

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

Dell - Internal Use - Confidential +1 From: Kanevsky, Arkady Sent: Wednesday, June 13, 2018 12:52 PM To: ful...@redhat.com; openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits +1 From: John Fulton [mailto:johfu

[openstack-dev] TripleO NeutronNetworkVLANRanges

Hello guys, just want to double check and make sure that this option can be ignored if using vxlan. NeutronNetworkVLANRanges (used in the network isolation template) Thanks, Remo __ OpenStack Development Mailing List

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 From: John Fulton [mailto:johfu...@redhat.com] Sent: Wednesday, June 13, 2018 11:23 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits On Wed, Jun 13, 2018, 12:04 PM Marios Andreou

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On Wed, Jun 13, 2018 at 9:50 AM, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration in > TripleO and Puppet modules, always here to update with new features, fix > (nasty and untestable third-party backends) bugs and manage all the > backports for

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

On Wed, Jun 13, 2018, 12:04 PM Marios Andreou wrote: > > On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente > wrote: > >> On 06/13/2018 05:50 PM, Emilien Macchi wrote: >> > Alan Bishop has been highly involved in the Storage backends integration >> > in TripleO and Puppet modules, always here to

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente wrote: > On 06/13/2018 05:50 PM, Emilien Macchi wrote: > > Alan Bishop has been highly involved in the Storage backends integration > > in TripleO and Puppet modules, always here to update with new features, > > fix (nasty and untestable

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

On 06/13/2018 05:50 PM, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration > in TripleO and Puppet modules, always here to update with new features, > fix (nasty and untestable third-party backends) bugs and manage all the > backports for stable

[openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

Alan Bishop has been highly involved in the Storage backends integration in TripleO and Puppet modules, always here to update with new features, fix (nasty and untestable third-party backends) bugs and manage all the backports for stable releases:

Re: [openstack-dev] [TripleO] config-download/ansible next steps

Hi, On Wed, Jun 13, 2018 at 3:17 PM, James Slagle wrote: > On Wed, Jun 13, 2018 at 6:49 AM, Dmitry Tantsur wrote: >> Slightly hijacking the thread to provide a status update on one of the items >> :) > > Thanks for jumping in. > > >> The immediate plan right now is to wait for metalsmith 0.4.0

Re: [openstack-dev] [TripleO] config-download/ansible next steps

On Wed, Jun 13, 2018 at 6:49 AM, Dmitry Tantsur wrote: > Slightly hijacking the thread to provide a status update on one of the items > :) Thanks for jumping in. > The immediate plan right now is to wait for metalsmith 0.4.0 to hit the > repositories, then start experimenting. I need to find a

Re: [openstack-dev] [TripleO] config-download/ansible next steps

Slightly hijacking the thread to provide a status update on one of the items :) On 06/12/2018 07:04 PM, James Slagle wrote: I wanted to provide an update on some next steps around config-download/Ansible and TripleO. Now that we've completed transitioning to config-download by default in Rocky,

[openstack-dev] [tripleo] The Weekly Owl - 24th Edition

Welcome to the twenty-fourth edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version:

[openstack-dev] [TripleO] config-download/ansible next steps

I wanted to provide an update on some next steps around config-download/Ansible and TripleO. Now that we've completed transitioning to config-download by default in Rocky, some might be wondering where we're going next. 1. Standalone roles. The idea here is to refactor the ansible tasks lists

Re: [openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

On Tue, Jun 12, 2018 at 11:21 AM James Slagle wrote: > On Tue, Jun 12, 2018 at 11:03 AM, Jiří Stránský wrote: > > On 12.6.2018 15:06, James Slagle wrote: > >> > >> On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin > >> wrote: > >>> > >>> Greetings, > >>> > >>> I wanted to let everyone know that

Re: [openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

On Tue, Jun 12, 2018 at 11:03 AM, Jiří Stránský wrote: > On 12.6.2018 15:06, James Slagle wrote: >> >> On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin >> wrote: >>> >>> Greetings, >>> >>> I wanted to let everyone know that we have a keystone only deployment and >>> upgrade job in check

Re: [openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

On 12.6.2018 15:06, James Slagle wrote: On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin wrote: Greetings, I wanted to let everyone know that we have a keystone only deployment and upgrade job in check non-voting. I'm asking everyone in TripleO to be mindful of this job and to help make sure

Re: [openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

On Mon, Jun 11, 2018 at 3:34 PM, Wesley Hayutin wrote: > Greetings, > > I wanted to let everyone know that we have a keystone only deployment and > upgrade job in check non-voting. I'm asking everyone in TripleO to be > mindful of this job and to help make sure it continues to pass as we move it

[openstack-dev] [tripleo] scenario000-multinode-oooq-container-upgrades

Greetings, I wanted to let everyone know that we have a keystone only deployment and upgrade job in check non-voting. I'm asking everyone in TripleO to be mindful of this job and to help make sure it continues to pass as we move it from non-voting check to check and eventually gating. Upgrade

[openstack-dev] [tripleo][heat] where does ip_netmask in network_config come from?

When the system boots up, the IP addresses seem correct: Jun 6 12:43:07 overcloud-controller-0 cloud-init: ci-info: | eno5: | True | . | . | . | 6c:ae:8b:25:34:ed | Jun 6 12:43:07 overcloud-controller-0 cloud-init: ci-info: | eno4: | True | 9.114.118.241

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

On 06/06/2018 06:59 AM, Mike Carden wrote: > > \o/ - care to add the links on the doc? Would be really helpful for > others I guess :). > > > Doc? What doc? This one: https://docs.openstack.org/oslo.privsep/latest/index.html I just created https://review.openstack.org/#/c/572670/

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

> > > \o/ - care to add the links on the doc? Would be really helpful for > others I guess :). > Doc? What doc? -- MC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

On 06/06/2018 06:37 AM, Mike Carden wrote: > > > In regards to your suggested positions within python code such as the > > client, its worth looking at oslo.privsep [1] where a decorator can be > > used for when needing to setuid. > > hmm yep, have to understand how to use it -

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

> > > > In regards to your suggested positions within python code such as the > > client, its worth looking at oslo.privsep [1] where a decorator can be > > used for when needing to setuid. > > hmm yep, have to understand how to use it - its doc is.. well. kind of > sparse. Would be good to get

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

On 06/05/2018 06:08 PM, Luke Hinds wrote: > > > On Tue, Jun 5, 2018 at 3:44 PM, Cédric Jeanneret > wrote: > > Hello guys! > > I'm currently working on python-tripleoclient in order to squash the > dreadful "NOPASSWD:ALL" allowed to the "stack" user. >

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 2018-05-31 13:00:47 + (+), Jeremy Stanley wrote: > On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote: > > Ade Lee wrote: > > > [...] > > > So it seems that the two blockers above have been resolved. So is it > > > time to ad a castellan compatible secret store to the base

Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

On Mon, Jun 4, 2018 at 8:26 PM, Emilien Macchi wrote: > TL;DR: we made nice progress and you can checkout this demo: > https://asciinema.org/a/185533 > > We started the discussion back in Dublin during the last PTG. The idea of > Standalone (aka All-In-One, but can be mistaken with all-in-one

Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

On Tue, Jun 5, 2018 at 3:31 AM Raoul Scarazzini wrote: > On 05/06/2018 02:26, Emilien Macchi wrote: > [...] > > I hope this update was useful, feel free to give feedback or ask any > > questions, > [...] > > I'm no prophet here, but I see a bright future for this approach. I can > imagine how

[openstack-dev] [tripleo] The Weekly Owl - 23th Edition

Welcome to the twenty third edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version:

Re: [openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

On Tue, Jun 5, 2018 at 3:44 PM, Cédric Jeanneret wrote: > Hello guys! > > I'm currently working on python-tripleoclient in order to squash the > dreadful "NOPASSWD:ALL" allowed to the "stack" user. > > The start was an issue with the rights on some files being wrong (owner > by root instead of

[openstack-dev] [tripleo][tripleoclient] No more global sudo for "stack" on the undercloud

Hello guys! I'm currently working on python-tripleoclient in order to squash the dreadful "NOPASSWD:ALL" allowed to the "stack" user. The start was an issue with the rights on some files being wrong (owner by root instead of stack, in stack home). After some digging and poking, it appears the

Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

On 05/06/2018 02:26, Emilien Macchi wrote: [...] > I hope this update was useful, feel free to give feedback or ask any > questions, [...] I'm no prophet here, but I see a bright future for this approach. I can imagine how useful this can be on the testing and much more the learning side. Thanks

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

We are using them for one of our deployments and are working on moving our other one to use the same modules :) Best regards On 06/04/2018 11:06 PM, Arnaud Morin wrote: > Hey, > > OVH is also using them as well as some custom ansible playbooks to manage the > deployment. But as for red had,

[openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

TL;DR: we made nice progress and you can checkout this demo: https://asciinema.org/a/185533 We started the discussion back in Dublin during the last PTG. The idea of Standalone (aka All-In-One, but can be mistaken with all-in-one overcloud) is to deploy a single node OpenStack where the

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

gt; > Date: Thursday, 31 May 2018 at 16:24 > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules > > > > On Wed, May 30, 2018 at 3:18 PM, Remo Mattei mailto:r...@rm

Re: [openstack-dev] [tripleo] Containerized Undercloud by default

On Thu, May 31, 2018 at 9:13 PM, Emilien Macchi wrote: > > - all multinode scenarios - current blocked by 1774297 as well but also >> https://review.openstack.org/#/c/571566/ >> > This part is done and ready for review (CI team + others): https://review.openstack.org/#/c/571529/ Thanks! --

Re: [openstack-dev] [tripleo] Containerized Undercloud by default

I forgot to mention Steve's effort to update the containers when deploying the undercloud, this is a critical piece if we want to continue to test changes in projects like tripleo-common that are embedded in Mistral containers for example. The patch that will enable it is

[openstack-dev] [tripleo] Containerized Undercloud by default

Hi, During Rocky cycle we would like to switch tripleoclient to deploy containeirzed undercloud by default but before to get there, we want to switch all CI jobs to it, like it was done when enabling config-download by default. Right now we have 3 jobs which test the containerized undercloud: -

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

usage questions)" Subject: Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules On Wed, May 30, 2018 at 3:18 PM, Remo Mattei mailto:r...@rm.ht>> wrote: Hello all, I have talked to several people about this and I would love to get this finalized once and for all. I have ch

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

On Wed, May 30, 2018 at 3:18 PM, Remo Mattei wrote: > Hello all, > I have talked to several people about this and I would love to get this > finalized once and for all. I have checked the OpenStack puppet modules > which are mostly developed by the Red Hat team, as of right now, TripleO is >

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote: > Ade Lee wrote: > > [...] > > So it seems that the two blockers above have been resolved. So is it > > time to ad a castellan compatible secret store to the base services? > > It's definitely time to start a discussion about it, at

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

Ade Lee wrote: [...] So it seems that the two blockers above have been resolved. So is it time to ad a castellan compatible secret store to the base services? It's definitely time to start a discussion about it, at least :) Would you be interested in starting a ML thread about it ? If not,

[openstack-dev] [tripleo] The Weekly Owl - 22th Edition

Welcome to the twenty second edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version:

[openstack-dev] [tripleo] CI Team Sprint 13 Summary

Greetings, The TripleO CI team has just completed Sprint 13 (5/3 - 05/23). The following is a summary of activities during our sprint. Details on our team structure can be found in the spec [1]. # Sprint 13 Epic (CI Squad): Upgrade Support and Refactoring - Epic Card:

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On Thu, 2018-05-17 at 10:33 +0200, Cédric Jeanneret wrote: > > On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote: > > On 5/17/18 9:58 AM, Thierry Carrez wrote: > > > Jeremy Stanley wrote: > > > > [...] > > > > As a community, we're likely to continue to make imbalanced > > > > trade-offs against

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On Thu, 2018-05-17 at 09:58 +0200, Thierry Carrez wrote: > Jeremy Stanley wrote: > > [...] > > As a community, we're likely to continue to make imbalanced > > trade-offs against relevant security features if we don't move > > forward and declare that some sort of standardized key storage > >

Re: [openstack-dev] [tripleo] Containerized Undercloud deep-dive

On 05/30/2018 04:10 PM, Dan Prince wrote: > We are on for this tomorrow (Thursday) at 2pm UTC (10am EST). meaning 3:00pm CET - conflicting with my squad meeting (3:30pm for squad red) :(. I'll watch it on youtube then. > > We'll meet here: https://redhat.bluejeans.com/dprince/ and record it >

Re: [openstack-dev] [tripleo] Containerized Undercloud deep-dive

We are on for this tomorrow (Thursday) at 2pm UTC (10am EST). We'll meet here: https://redhat.bluejeans.com/dprince/ and record it live. We'll do an overview presentation and then perhaps jump into a terminal for some live questions. Dan On Tue, May 15, 2018 at 10:51 AM, Emilien Macchi wrote:

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

On 5/23/18 6:49 PM, Sagi Shnaidman wrote: Alex, the problem is that you're working and focusing mostly on release specific code like featuresets and some scripts. But tripleo-quickstart(-extras) and tripleo-ci is much *much* more than set of featuresets. Only 10% of the code may be related

[openstack-dev] [tripleo] Using derive parameters workflow for FixedIPs

As discussed in the IRC over , here is the outline: * Derive parameters workflow could be used for deriving FixedIPs parameters also (started as part of the review https://review.openstack.org/#/c/569818/) * Above derivation should be done for all the deployments, so invoking of derive parameters

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

Hi, On Wed, May 23, 2018 at 8:20 PM, Sagi Shnaidman wrote: > >> >> to reduce the impact of a change. From my original reply: >> >> > If there's a high maintenance cost, we haven't properly identified the >> > optimal way to separate functionality between tripleo/quickstart.

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

> to reduce the impact of a change. From my original reply: > > > If there's a high maintenance cost, we haven't properly identified the > optimal way to separate functionality between tripleo/quickstart. > > IMHO this is a side effect of having a whole bunch of roles in a > single repo.

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

On Wed, May 23, 2018 at 10:49 AM, Sagi Shnaidman wrote: > Alex, > > the problem is that you're working and focusing mostly on release specific > code like featuresets and some scripts. But tripleo-quickstart(-extras) and > tripleo-ci is much *much* more than set of

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

Alex, the problem is that you're working and focusing mostly on release specific code like featuresets and some scripts. But tripleo-quickstart(-extras) and tripleo-ci is much *much* more than set of featuresets. Only 10% of the code may be related to releases and branches, while other 90% is

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

On Wed, May 23, 2018 at 8:30 AM, Sagi Shnaidman wrote: > Hi, Sergii > > thanks for the question. It's not first time that this topic is raised and > from first view it could seem that branching would help to that sort of > issues. > > Although it's not the case.

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

Hi, Sergii thanks for the question. It's not first time that this topic is raised and from first view it could seem that branching would help to that sort of issues. Although it's not the case. Tripleo-quickstart(-extras) is part of CI code, as well as tripleo-ci repo which have never been

Re: [openstack-dev] [tripleo][ci][infra] Quickstart Branching

On 5/23/18 2:43 PM, Sergii Golovatiuk wrote: Hi, Looking at [1], I am thinking about the price we paid for not branching tripleo-quickstart. Can we discuss the options to prevent the issues such as [1]? Thank you in advance. [1] https://review.openstack.org/#/c/569830/4 That was only a half

[openstack-dev] [tripleo][ci][infra] Quickstart Branching

Hi, Looking at [1], I am thinking about the price we paid for not branching tripleo-quickstart. Can we discuss the options to prevent the issues such as [1]? Thank you in advance. [1] https://review.openstack.org/#/c/569830/4 -- Best Regards, Sergii Golovatiuk

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

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)

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

On Tue, May 22, 2018 at 8:24 AM, Cédric Jeanneret wrote: > > > On 05/22/2018 09:08 AM, Luke Hinds wrote: > > > > > > On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret > > wrote: > > > > > > > > On 05/21/2018 03:49 PM,

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

On 05/22/2018 09:24 AM, Cédric Jeanneret wrote: > > > On 05/22/2018 09:08 AM, Luke Hinds wrote: >> >> >> On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret > > wrote: >> >> >> >> On 05/21/2018 03:49 PM, Luke Hinds wrote: >> > A few

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

On 05/22/2018 09:08 AM, Luke Hinds wrote: > > > On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret > wrote: > > > > On 05/21/2018 03:49 PM, Luke Hinds wrote: > > A few operators have requested if its possible to limit sudo's coverage

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret wrote: > > > On 05/21/2018 03:49 PM, Luke Hinds wrote: > > A few operators have requested if its possible to limit sudo's coverage > > on both the under / overcloud. There is concern over `ALL=(ALL) > > NOPASSWD:ALL` , which

Re: [openstack-dev] [tripleo] cannot configure host kernel-args for pci passthrough with first-boot

Hi, We found the cause of the problem. We forgot the following in the first-boot.yaml outputs: # This means get_resource from the parent template will get the userdata, see: # http://docs.openstack.org/developer/heat/template_guide/composition.html#making-your-template-resource-more-transparent #

Re: [openstack-dev] [tripleo] cannot configure host kernel-args for pci passthrough with first-boot

Could you check the log in the /var/log/cloud-init-output.log file to see what are the first-boot scripts which are executed on the node? Add "set -x" in the kernel-args.sh file to better logs. Regards, Saravanan KR On Tue, May 22, 2018 at 12:49 AM, Samuel Monderer

Re: [openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

On 05/21/2018 03:49 PM, Luke Hinds wrote: > A few operators have requested if its possible to limit sudo's coverage > on both the under / overcloud. There is concern over `ALL=(ALL) > NOPASSWD:ALL` , which allows someone to  `sudo su`. > > This task has come under the care of the tripleo

Re: [openstack-dev] [tripleo] Migration to Storyboard

During the Storyboard session today: https://etherpad.openstack.org/p/continuing-the-migration-lp-sb We mentioned that TripleO would continue to migrate during Rocky cycle. Like Alex mentioned in this thread, we need to migrate the scripts used by the CI squad so they work with SB. Once this is

[openstack-dev] [tripleo] Limiting sudo coverage of heat-admin / stack and other users.

A few operators have requested if its possible to limit sudo's coverage on both the under / overcloud. There is concern over `ALL=(ALL) NOPASSWD:ALL` , which allows someone to `sudo su`. This task has come under the care of the tripleo security squad. The work is being tracked and discussed

[openstack-dev] [tripleo][rdo] Fwd: Status of activities related to python3 PoC in RDO

FYI -- Forwarded message -- From: Alfredo Moralejo Alonso Date: Fri, May 18, 2018 at 1:02 PM Subject: Status of activities related to python3 PoC in RDO To: d...@lists.rdoproject.org, us...@lists.rdoproject.org Hi, One of the goals for RDO during this

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote: > On 5/17/18 9:58 AM, Thierry Carrez wrote: >> Jeremy Stanley wrote: >>> [...] >>> As a community, we're likely to continue to make imbalanced >>> trade-offs against relevant security features if we don't move >>> forward and declare that some sort

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 5/17/18 9:58 AM, Thierry Carrez wrote: Jeremy Stanley wrote: [...] As a community, we're likely to continue to make imbalanced trade-offs against relevant security features if we don't move forward and declare that some sort of standardized key storage solution is a fundamental component on

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

Jeremy Stanley wrote: [...] As a community, we're likely to continue to make imbalanced trade-offs against relevant security features if we don't move forward and declare that some sort of standardized key storage solution is a fundamental component on which OpenStack services can rely. Being

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

On 2018-05-16 17:42:09 + (+), Jeremy Stanley wrote: [...] > Unfortunately, I'm unable to find any follow-up summary on the > mailing list from the aforementioned session, but recollection from > those who were present (I had a schedule conflict at that time) was > that a

Re: [openstack-dev] [tripleo] Cancel IRC meeting for May 22, 2018

On Wed, May 16, 2018 at 1:07 PM, Alex Schultz wrote: > Since the summit is coming up, there will likely be very low > attendance. We'll carry any open items until the following week. > No Weekly Owl as well, but be patient for the next Edition special Summit. -- Emilien

[openstack-dev] [tripleo] Cancel IRC meeting for May 22, 2018

Since the summit is coming up, there will likely be very low attendance. We'll carry any open items until the following week. Thanks, -Alex __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

Excerpts from Jeremy Stanley's message of 2018-05-16 17:42:09 +: > On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote: > > On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote: > > > As part of the work from the Security Squad, we added the > > > ability for the containerized undercloud

[openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote: > On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote: > > 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

Re: [openstack-dev] [tripleo] Encrypted swift volumes by default in the undercloud

Hi, On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote: 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

[openstack-dev] [tripleo] Encrypted swift volumes by default in the undercloud

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

<    1   2   3   4   5   6   7   8   9   10   >