Re: [Openstack-operators] [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann wrote: > The release page says Ocata is planned to go into extended maintenance mode > on Aug 27 [1]. There really isn't much to this except it means we don't do > releases for Ocata anymore [2]. There is a caveat that project teams that do > not

Re: [Openstack-operators] [TripleO] undercloud sshd config override

On Fri, Sep 14, 2018 at 9:41 AM, Cody wrote: > Hello folks, > > I installed TripleO undercloud on a machine with a pre-existing > sshd_config that disabled root and password login. The file was > rewritten by Puppet after the undercloud installation and was made to > allow for both options. This

Re: [Openstack-operators] [openstack-dev] The Forum Schedule is now live

On Mon, Apr 30, 2018 at 9:47 AM, Jimmy McArthur wrote: > Project Updates are in their own track: > https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223 > TripleO is still missing? Thanks, -Alex > As are SIG, BoF and Working Groups: >

Re: [Openstack-operators] nova-placement-api tuning

On Tue, Apr 3, 2018 at 4:48 AM, Chris Dent <cdent...@anticdent.org> wrote: > On Mon, 2 Apr 2018, Alex Schultz wrote: > >> So this is/was valid. A few years back there was some perf tests done >> with various combinations of process/threads and for Keystone it was >>

Re: [Openstack-operators] nova-placement-api tuning

On Fri, Mar 30, 2018 at 11:11 AM, iain MacDonnell wrote: > > > On 03/29/2018 02:13 AM, Belmiro Moreira wrote: >> >> Some lessons so far... >> - Scale keystone accordingly when enabling placement. > > > Speaking of which; I suppose I have the same question for keystone

Re: [Openstack-operators] [openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur wrote: > Hi folks! > > This was raised several times, now I want to bring it to the wider audience. > We're planning [1] to deprecate classic drivers in Queens and remove them in > Rocky. It was pointed at the Forum that we'd

Re: [Openstack-operators] [puppet] keystone.conf and 'federation/trusted_dashboard' (multi valued)

On Fri, Nov 10, 2017 at 12:45 PM, Red Cricket wrote: > Hi, > > I am using https://github.com/openstack/puppet-keystone (stable/newton > branch) and we would like to implement a design that uses federation openid. > > As part of this design I need to add these lines to

[Openstack-operators] [tripleo] Making containerized service deployment the default

Hey ops & devs, We talked about containers extensively at the PTG and one of the items that needs to be addressed is that currently we still deploy the services as bare metal services via puppet. For Queens we would like to switch the default to be containerized services. With this switch we

Re: [Openstack-operators] Fuel setup problem

On Fri, May 19, 2017 at 11:15 PM, Matthieu Lejeune < matthieu.leje...@exxoss.com> wrote: > Hi all, > > Please someone as some experience with fuel and problem like ? > > On an other side someone have production expercience with fuel ? It's a > good idea? > > Matthieu > > > > > Le 11/05/17 à

Re: [Openstack-operators] [puppet] module dependencies in final Mitaka release

On Wed, Apr 26, 2017 at 5:22 AM, Alex Schultz <aschu...@redhat.com> wrote: > On Wed, Apr 26, 2017 at 3:26 AM, Justin Cattle <j...@ocado.com> wrote: >> Hi, >> >> >> It looks like there is some invalid dependencies in the neutron module: >> >> >&

Re: [Openstack-operators] [puppet] module dependencies in final Mitaka release

On Wed, Apr 26, 2017 at 3:26 AM, Justin Cattle wrote: > Hi, > > > It looks like there is some invalid dependencies in the neutron module: > > > +{ > +"name": "openstack/vswitch", > +"version_requirement": ">=4.3.0 <5.0.0" > +}, > > > There

[Openstack-operators] [puppet] Warning running low of contributors

Hey folks, So in recent months, we've seen a drop off contributors and reviewers to the various Puppet OpenStack modules. Additionally with the recent resignation of a few of our cores, we're getting to a spot where the modules under the Puppet OpenStack umbrella are becoming dangerously close to

Re: [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

/releases.html#releases-summary On Fri, Nov 11, 2016 at 2:11 PM, Alex Schultz <aschu...@redhat.com> wrote: > On Thu, Nov 3, 2016 at 11:31 PM, Sam Morrison <sorri...@gmail.com> wrote: >> >> On 4 Nov. 2016, at 1:33 pm, Emilien Macchi <emil...@redhat.com> wrote: >> >>

Re: [Openstack-operators] [puppet] Virtual midcycle/sprint - Jan 11/12

On Tue, Dec 6, 2016 at 12:32 PM, Alex Schultz <aschu...@redhat.com> wrote: > Hey everyone, > > We're going to be running a small midcycle/sprint on January 11-12, > 2017 in #puppet-openstack on freenode. We will be reviewing the work > items for Ocata and doing some bug tri

[Openstack-operators] [puppet] Virtual midcycle/sprint - Jan 11/12

Hey everyone, We're going to be running a small midcycle/sprint on January 11-12, 2017 in #puppet-openstack on freenode. We will be reviewing the work items for Ocata and doing some bug triage. Feel free to add additional topics to the etherpad[0]. Thanks, -Alex [0]

Re: [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

; > > > > > > My guess is that this would also be the case for RedHat and other distros > too. > > > Fedora is shipping Puppet 4 and we're going to do the same for Red Hat > and CentOS7. > > Thoughts? > > > > On 4 Nov. 2016, at 2:58 am, Alex Schultz <as

Re: [Openstack-operators] [puppet] openstack provider errors with openrc and keystone v3

haven't been using puppet-openstack_extras, but I'll look at > that for the openrc file at least :) > > > > > > Cheers, > Just > > On 10 November 2016 at 16:32, Alex Schultz <aschu...@redhat.com> wrote: >> >> Hey Justin, >> >> >> >

Re: [Openstack-operators] [puppet] openstack provider errors with openrc and keystone v3

Hey Justin, On Thu, Nov 10, 2016 at 8:48 AM, Justin Cattle wrote: > Hi, > > > I was looking at this class in the keystone module: > > keystone::disable_admin_token_auth > > ..which suggests: > > # After this class is run, > # future puppet runs must have an openrc file with

[Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

Hey everyone, Puppet 3 is reaching it's end of life at the end of this year[0]. Because of this we are planning on dropping official puppet 3 support as part of the Ocata cycle. While we currently are not planning on doing any large scale conversion of code over to puppet 4 only syntax, we may

Re: [Openstack-operators] [openstack-dev] [puppet][tripleo][fuel] Upcoming changes to defaults around using processor count for worker configurations

Hey Sergii, On Thu, Oct 20, 2016 at 3:34 AM, Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: > Hi, > > > On Thu, Sep 29, 2016 at 11:57 PM, Alex Schultz <aschu...@redhat.com> wrote: >> >> Hello all, >> >> So for many years we've been usin

[Openstack-operators] [puppet] Presence at the PTG

Hi, We chatted about this a bit in the last meeting[0], but I wanted to send a note to the wider audience. Our initial thought was that the puppet group will not have a specific presence at the upcoming PTG in Atlanta. We don't think we'll have any topics that we can't work through via our

[Openstack-operators] [puppet][tripleo][fuel] Upcoming changes to defaults around using processor count for worker configurations

Hello all, So for many years we've been using either the service defaults (usually python determined processor count) or the $processorcount fact from facter in puppet for worker configuration options for the OpenStack services. If you are currently using the default values provided by the

Re: [Openstack-operators] How are people dealing with API rate limiting?

On Tue, Jun 14, 2016 at 9:02 AM, Matt Riedemann wrote: > A question came up in the nova IRC channel this morning about the > api_rate_limit config option in nova which was only for the v2 API. > > Sean Dague explained that it never really worked because it was per API