Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Amrith, Some good thoughts in your email. I've replied to a few specific pieces below. Overall I think it's a good start to a plan. On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote: > Trove has evolved rapidly over the past several years, since integration > in

Re: [openstack-dev] [keystone] Colleen Murphy for core

Congrats Colleen! On Tue, May 2, 2017 at 12:39 PM, De Rose, Ronald wrote: > Congrat Colleen, well deserved! > > > > -Ron > > > > *From:* Lance Bragstad [mailto:lbrags...@gmail.com] > *Sent:* Tuesday, May 2, 2017 11:16 AM > *To:* OpenStack Development Mailing List (not

[openstack-dev] [puppet] stepping down from puppet-openstack core

I am stepping down as core in the puppet openstack project. This is the culmination of a long and slow refocus of my work efforts into other areas. Additionally I'm not sure what the future holds for me at this point, and although it's possible that I will be doing puppet again but it's not fair

Re: [openstack-dev] [kolla][keystone] better way to rotate and distribution keystone fernet keys in container env

I don't think it would cause an issue if every controller rotated all at once. The issues are more along the lines of rotating to key C when there are tokens out there that are encrypted with keys A and B. In other words over-rotation. As long as your keys are properly staged, do the rotation all

Re: [openstack-dev] [keystone]PKI token VS Fernet token

On Fri, Feb 24, 2017 at 9:09 PM, joehuang wrote: > Hello, Matt, > > Thank you for your reply, just as what you mentioned, for the slow changed > data, aync. replication should work. My concerns is that the impact of > replication delay, for example (though it's quite low

Re: [openstack-dev] [keystone]PKI token VS Fernet token

> > > At last, we still have one question: > For public cloud, it is very common that multi regions are deployed. And > the distance is usually very far between the regions. So the transport > delay is really a problem. Fernet token requires the data must be the same. > Because of the slow

Re: [openstack-dev] [puppet] Thank you.

Cody, Thank you for your contributions over the years. On Fri, Jan 20, 2017 at 12:29 PM, Cody Herriges wrote: > I attempted to send this out last week but think I messed it up by sending > from my work email address which isn't the one I am signed up to the lists > with.

Re: [openstack-dev] [Trove] Resource not found when creating db instances.

Trove works fine with neutron. I would look deeper into your logs. Do you have any errors about issues with Rabbit message timeouts? If so your guest may have issues talking to Rabbit. That seems to be a common issue. On Wed, Jan 18, 2017 at 8:59 PM, Amrith Kumar wrote:

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

> > > > I'm surprised any AD administrator let Keystone write to it. I've always > hear the inverse that AD admins never would allow keystone to write to it, > therefore it was never used for Projects or Assignments. Users were > likewise read-only when AD was involved. > > I have seen normal LDAP

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

Steve, Your tenure as PTL was excellent for the continued stability and performance of Keystone. You did a great job in taking feedback from operators also. Thanks for your work! On Nov 22, 2016 2:06 PM, "De Rose, Ronald" wrote: > Thank you Steve, we’ve been lucky to

Re: [openstack-dev] [Openstack-operators] [keystone][tripleo][ansible][puppet][all] changing default token format

How to add yourself to Planet OpenStack: https://wiki.openstack.org/wiki/AddingYourBlog As for SuperUser you could reach out to them if you think it's interesting for users/operators. Generally they'll want to publish it there first then you follow-up with your blog post a few days later. On

Re: [openstack-dev] [puppet] Core nominations

+1 to all. Thanks for your work guys! On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi wrote: > While our group keeps moving, it's time to propose again new people > part of core team. > > Dmitry Tantsur / puppet-ironic > Dmitry is the guardian of puppet-ironic. He's driving

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

On Fri, Sep 9, 2016 at 10:05 AM, Emilien Macchi wrote: > Hi, > > I wrote a little blog post about the last cycle in PuppetOpenStack: > http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/ > > I can't describe how much I liked to be PTL during the last 18

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On Thu, Aug 25, 2016 at 1:13 PM, Steve Martinelli wrote: > The keystone team is pursuing a trigger-based approach to support rolling, > zero-downtime upgrades. The proposed operator experience is documented here: > >

Re: [openstack-dev] [puppet] proposal: start gating on puppet4

+1 from me also. This will help everyone who is trying to transition to it. On Wed, Aug 10, 2016 at 1:46 AM, Javier Pena wrote: > > > - Original Message - > > Hi, > > > > Today Puppet OpenStack CI is running unit and functional test jobs > > against puppet 3 and

Re: [openstack-dev] [puppet] Propose Sofer Athlan-Guyot (chem) part of Puppet OpenStack core

+1 from me! On Jul 28, 2016 9:20 AM, "Emilien Macchi" wrote: > You might not know who Sofer is but he's actually "chem" on IRC. > He's the guy who will find the root cause of insane bugs, in OpenStack > in general but also in Puppet OpenStack modules. > Sofer has been

Re: [openstack-dev] [Openstack-operators] [puppet] [desginate] An update on the state of puppet-designate (and designate in RDO)

We're using Designate but still on Juno. We're running puppet from around then, summer of 2015. We'll likely try to upgrade to Mitaka at some point but Juno Designate "just works" so it's been low priority. Look forward to your efforts here. On Tue, Jul 5, 2016 at 7:47 PM, David Moreau Simard

Re: [openstack-dev] [Openstack-operators] [nova] Rabbit-mq 3.4 crashing (anyone else seen this?)

For the record we're on 3.5.6-1. On Jul 5, 2016 11:27 AM, "Mike Lowe" wrote: > I was having just this problem last week. We updated to 3.6.2 from 3.5.4 > on ubuntu and stated seeing crashes due to excessive memory usage. I did > this on each node of my rabbit cluster and haven’t

Re: [openstack-dev] [Openstack-operators] [nova] Rabbit-mq 3.4 crashing (anyone else seen this?)

Yes! This happens often but I'd not call it a crash, just the mgmt db gets behind then eats all the memory. We've started monitoring it and have runbooks on how to bounce just the mgmt db. Here are my notes on that: restart rabbitmq mgmt server - this seems to clear the memory usage. rabbitmqctl

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

On Tue, Jun 28, 2016 at 12:32 PM, Potter, Nathaniel < nathaniel.pot...@intel.com> wrote: > Hi all, > > > > I did some digging into this on the cinder side, and it gets a little > complicated. So, before the target and context are passed into the > _authorize_show method, they’re retrieved through

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

he hierarchy, by looking at the parent and > seeing if it is a project acting as a domain. > > Henry > keystone core > > On 27 Jun 2016, at 17:13, Matt Fischer <m...@mattfischer.com> wrote: > > We upgraded our dev environment last week to Keystone stable/mitaka. Since > then

[openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

We upgraded our dev environment last week to Keystone stable/mitaka. Since then we're unable to show or set quotas on projects of which the admin is not a member. Looking at the cinder code, it seems that cinder is pulling a project list and attempting to determine a hierarchy. On Liberty

Re: [openstack-dev] [puppet] vision on new modules

On Wed, Jun 8, 2016 at 2:42 PM, Emilien Macchi wrote: > Hi folks, > > Over the last months we've been creating more and more modules [1] [2] > and I would like to take the opportunity to continue some discussion > we had during the last Summits about the quality of our

Re: [openstack-dev] [keystone][all] Incorporating performance feedback into the review process

On Fri, Jun 3, 2016 at 1:35 PM, Lance Bragstad wrote: > Hey all, > > I have been curious about impact of providing performance feedback as part > of the review process. From what I understand, keystone used to have a > performance job that would run against proposed patches

Re: [openstack-dev] [puppet] proposal about puppet versions testing coverage

On Wed, May 25, 2016 at 1:09 PM, Emilien Macchi wrote: > Greating folks, > > In a recent poll [1], we asked to our community to tell which version > of Puppet they were running. > The motivation is to make sure our Puppet OpenStack CI test the right > things, that are really

Re: [openstack-dev] [puppet] Proposing Ivan Berezovskiy for puppet-openstack-core

+1 from me! On Thu, May 19, 2016 at 8:17 AM, Emilien Macchi wrote: > Hi, > > I don't need to introduce Ivan Berezovskiy (iberezovskiy on IRC), he's > been doing tremendous work in Puppet OpenStack over the last months, > in a regular way. > > Some highlights about his

Re: [openstack-dev] [all] Deprecated options in sample configs?

> > > If config sample files are being used as a living document then that would > be a reason to leave the deprecated options in there. In my experience as a > cloud deployer I never once used them in that manner so it didn't occur to > me that people might, hence my question to the list. > >

Re: [openstack-dev] [all] Deprecated options in sample configs?

On Tue, May 17, 2016 at 12:47 PM, Andrew Laski <and...@lascii.com> wrote: > > > > On Tue, May 17, 2016, at 02:36 PM, Matt Fischer wrote: > > On Tue, May 17, 2016 at 12:25 PM, Andrew Laski <and...@lascii.com> wrote: > > I was in a discussion earlier abo

Re: [openstack-dev] [all] Deprecated options in sample configs?

On Tue, May 17, 2016 at 12:25 PM, Andrew Laski wrote: > I was in a discussion earlier about discouraging deployers from using > deprecated options and the question came up about why we put deprecated > options into the sample files generated in the various projects. So, why >

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

On May 11, 2016 10:03 PM, "Flavio Percoco" wrote: > > Greetings, > > The Glance team is evaluating the needs and usefulness of the Glance Registry > service and this email is a request for feedback from the overall community > before the team moves forward with anything. > >

Re: [openstack-dev] [puppet] Stepping down from puppet core

On Tue, May 10, 2016 at 9:11 AM, Clayton O'Neill wrote: > I’d like to step down as a core reviewer for the OpenStack Puppet > modules. For the last cycle I’ve had very little time to spend > reviewing patches, and I don’t expect that to change in the next > cycle. In

Re: [openstack-dev] [keystone] Token providers and Fernet as the default

On Mon, May 2, 2016 at 5:26 PM, Clint Byrum wrote: > Hello! I enjoyed very much listening in on the default token provider > work session last week in Austin, so thanks everyone for participating > in that. I did not speak up then, because I wasn't really sure of this > idea

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

On Mon, Apr 18, 2016 at 12:52 PM, Morgan Fainberg wrote: > > > On Mon, Apr 18, 2016 at 7:29 AM, Brant Knudson wrote: > >> >> >> On Fri, Apr 15, 2016 at 9:04 PM, Adam Young wrote: >> >>> We all want Fernet to be a reality. We ain't

Re: [openstack-dev] [puppet] Stepping down from puppet-openstack-core

On Mon, Apr 18, 2016 at 9:37 AM, Sebastien Badia wrote: > Hello here, > > I would like to ask to be removed from the core reviewers team on the > Puppet for OpenStack project. > > I lack dedicated time to contribute on my spare time to the project. And I > don't work anymore on

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

Thanks Brant, I will missing that distinction. On Mon, Apr 18, 2016 at 9:43 AM, Brant Knudson <b...@acm.org> wrote: > > > On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer <m...@mattfischer.com> > wrote: > >> On Mon, Apr 18, 2016 at 8:29 AM, B

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

On Fri, Apr 15, 2016 at 8:04 PM, Adam Young wrote: > We all want Fernet to be a reality. We ain't there yet (Except for mfish > who has no patience) but we are getting closer. The goal is to get Fernet > as the default token provider as soon as possible. The review to do

Re: [openstack-dev] [keystone]Liberty->Mitaka upgrade: is it possible without downtime?

On Thu, Apr 14, 2016 at 7:45 AM, Grasza, Grzegorz wrote: > > From: Gyorgy Szombathelyi > > > > Unknown column 'user.name' in 'field list' > > > > in some operation when the DB is already upgraded to Mitaka, but some > > keystone instances in a HA setup are still

Re: [openstack-dev] [keystone]Liberty->Mitaka upgrade: is it possible without downtime?

Unfortunately Keystone does not handle database upgrades like nova. and they do tend to be disruptive. I have not tried Liberty to mitaka myself, but have you tried to validate a token granted on a mitaka node against the liberty one? If you are lucky the other nodes will still be able to

Re: [openstack-dev] [keystone] Newton midycle planning

Would like to try and make it, no promises, so don't decide based on me, but, I'm with Adam: R-14 June 27-01 or R-11 July 18-22 work On Wed, Apr 13, 2016 at 8:19 PM, Adam Young wrote: > On 04/13/2016 10:07 PM, Morgan Fainberg wrote: > > It is that time again, the time to

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova wrote: > Hey, openstackers! > > Recently I was trying to profile Keystone (OpenStack Liberty vs Mitaka) > using this set of changes > > (that's

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Michael Xin | Manager, Security Engineering - US > Product Security |Rackspace Hosting > Office #: 501-7341 or 210-312-7341 > Mobile #: 210-284-8674 > 5000 Walzem Road, San Antonio, Tx 78218 > > -------

[openstack-dev] [puppet] puppet-trove remove templated guestagent.conf

Right now puppet-trove can configure guestagent.conf in two ways. First via config options in the guestagent class and second via a templated file that taskmanager.pp handles by default [1]. I'd like to drop this behavior, but it's not backwards compatible so would like to discuss. First the

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 2:29 PM, Xav Paice wrote: > Remember that we're talking here about all the projects, not just > keystone. I can't see that we'll move everything to subpaths at any time > soon, and until that point we still need to at least make an informal >

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

This is not the first time. Monasca and Murano had a collision too[1]. When this happens the changes trickle down into automation tools also and complicates things. [1] https://bugs.launchpad.net/murano/+bug/1505785 On Wed, Mar 9, 2016 at 3:30 PM, Xav Paice wrote: > From an

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

On Wed, Mar 9, 2016 at 7:19 AM, Adam Young <ayo...@redhat.com> wrote: > On 03/09/2016 01:11 AM, Tim Bell wrote: > > > From: Matt Fischer < <m...@mattfischer.com>m...@mattfischer.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)&q

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

> > > I don't think your example is right: "PKI will validate that token > without going to any keystone server". How would it track revoked tokens? > I'm pretty sure that they still get validated, they are stored in the DB > even. > > I also disagree that there are different use cases. Just

Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox <jamielen...@gmail.com> wrote: > > > On 18 February 2016 at 10:50, Matt Fischer <m...@mattfischer.com> wrote: > >> I've been having some issues with keystone v3 and versionless endpoints >> and I'd like to

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

ith a keystone endpoint. I'm under the impression that > the different token formats have different use-cases, so am wondering if > there is a conceptual reason why multiple token formats are an either/or > scenario. > > > On 3/8/2016 8:06 AM, Matt Fischer wrote: > > T

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

This would be complicated to setup. How would the Openstack services validate the token? Which keystone node would they use? A better question is why would you want to do this? On Tue, Mar 8, 2016 at 8:45 AM, rezroo wrote: > Keystone supports both tokens and ec2

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

+1 from me! gmail/openstack-dev is doing its thing where I see your email 4 hours before Emilien's original, so apologies for the reply ordering On Fri, Mar 4, 2016 at 8:49 AM, Cody Herriges wrote: > Emilien Macchi wrote: > > Hi, > > > > To scale-up our review process, we

Re: [openstack-dev] [puppet] how to run rspec tests? r10k issue

This worked great. Thanks for this and the upstream fix. On Fri, Feb 26, 2016 at 6:25 AM, Sofer Athlan-Guyot <sathl...@redhat.com> wrote: > Hi Matt, > > Matt Fischer <m...@mattfischer.com> writes: > > > I ended up symlinking the r10k binary I have insta

Re: [openstack-dev] [puppet] Austin Design Summit space needs

On Wed, Feb 24, 2016 at 8:30 AM, Emilien Macchi wrote: > Puppet OpenStack folks, > > As usual, Thierry Carrez sent an e-mail to PTLs about space needs for > the next OpenStack Summit in Austin. > > > We can have 3 kinds of slots: > > * Fishbowl slots (Wed-Thu) - we had 2 in

Re: [openstack-dev] [all] A proposal to separate the design summit

> > > * would it better to keep the ocata cycle at a more normal length, and > >then run the "contributor events" in Mar/Sept, as opposed to Feb/Aug? > >(again to avoid the August black hole) > > > > Late March is treacherous in the US, as spring break is generally around > the last week

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 11:51 AM, Tim Bell wrote: > > > > > > On 22/02/16 17:27, "John Garbutt" wrote: > > >On 22 February 2016 at 15:31, Monty Taylor wrote: > >> On 02/22/2016 07:24 AM, Russell Bryant wrote: > >>> On Mon, Feb 22,

Re: [openstack-dev] [all] A proposal to separate the design summit

Cross-post to openstack-operators... As an operator, there's value in me attending some of the design summit sessions to provide feedback and guidance. But I don't really need to be in the room for a week discussing minutiae of implementations. So I probably can't justify 2 extra trips just to

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

wrote: > Hi Michal, > > Just add --os-identity-api-version=3 to your command it will work. The > provider uses v3 openstackclient via env var > OS_IDENTITY_API_VERSION=3. The default is still 2. > > Best Regards, > Matthew Mosesohn > > On Fri, Feb 19, 2016 at 5:25 PM

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

What version of openstack client do you have? What version of the module are you using? On Feb 19, 2016 7:20 AM, "Ptacek, MichalX" wrote: > Hi all, > > > > I was playing some time with puppet-keystone deployments, > > and also reported one issue related to this: > >

Re: [openstack-dev] [puppet] how to run rspec tests? r10k issue

b 18, 2016 at 3:26 PM, Matt Fischer <m...@mattfischer.com> > wrote: > >> Is anyone able to share the secret of running spec tests since the r10k >> transition? bundle install && bundle exec rake spec have issues because >> r10k is not being installed. Since I'm

[openstack-dev] [puppet] how to run rspec tests? r10k issue

Is anyone able to share the secret of running spec tests since the r10k transition? bundle install && bundle exec rake spec have issues because r10k is not being installed. Since I'm not the only one hopefully this question will help others. +

[openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

I've been having some issues with keystone v3 and versionless endpoints and I'd like to know what's expected to work exactly in Liberty and beyond. I thought with v3 we used versionless endpoints but it seems to cause some breakages and some disagreement as to what should work. Here's what I've

Re: [openstack-dev] [puppet] Push Mitaka beta tag

Emilien, More tags like this cannot hurt, it makes it easier to follow things, thanks for doing this. On Mon, Feb 15, 2016 at 9:13 AM, Emilien Macchi wrote: > Hi, > > While Puppet modules releases are independently managed, we have some > requests from both RDO & Debian

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

45:59.894 | ++ openstack --os-cloud=devstack-admin image > create cirros-0.3.4-x86_64-uec-kernel --public --container-format aki > --disk-format aki > > > > Is there any known way how to get puppet deployments working on systems > behind proxy ? > > > > T

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

If you can't isolate the exact thing you need to get cleaned up here it can be difficult to unwind. You'll either need to read the code to see what's triggering the db setup (which is probably the package installs) or start on a clean box. I'd recommend the latter. On Thu, Feb 4, 2016 at 10:35

Re: [openstack-dev] [puppet] Midcycle Sprint Summary

Perhaps we should cover and assign each module in the meeting after the release? Actually removing the code and tests in many cases would be a good assignment for people trying to get more commits and experience. On Feb 1, 2016 2:22 PM, "Cody Herriges" wrote: > Emilien Macchi

Re: [openstack-dev] [keystone] URLs are not reported in the endpoint listing

I've seen similar odd behavior when using the Keystone client to try to list endpoints created using the v3 API (via puppet). Try using the openstack client and the v3 endpoint. Be sure to set --os-api-version 3. On Feb 2, 2016 3:06 AM, "Pradip Mukhopadhyay" wrote: >

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

The way I'd recommend is to write your own manifests that include the openstack modules. I'd use roles and profiles which make it easy to move things around, but two simple manifests will also work. As Emilien once said we give you the ingredients but don't cook for you. If you want to just do two

Re: [openstack-dev] [puppet] Stepping down from Puppet Core

Mathieu, Thank you for all the work you've done over the past few years in this community. You've done a lot and also done a lot to help answer questions and mentor new folks. On Wed, Jan 27, 2016 at 1:13 PM, Mathieu Gagné wrote: > Hi, > > I would like to ask to be removed

Re: [openstack-dev] [puppet] [infra] adding a third scenario in Puppet OpenStack integration jobs

Also +1 for ceph And Fernet is a great idea, Keystone is moving towards a day where it's default. On Tue, Jan 26, 2016 at 2:20 PM, David Moreau Simard wrote: > +1 for adding puppet-ceph and Ceph integration in Nova, Cinder and Glance. > > This means there would be two

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

One thing that might be tough for operators is dealing with different versions of openstack projects which require different versions of oslo. Right now we have some stuff on Liberty, some stuff not. As we containerize more services that's going to get even more true. Right now we can solve this

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

+1 from me! On Tue, Jan 5, 2016 at 10:55 AM, Emilien Macchi wrote: > Hi, > > Alex Schultz (mwhahaha on IRC) has been a very active contributor over > the last months in the Puppet OpenStack group: > * He's doing a lot of reviews and they are very valuable. He's in my >

Re: [openstack-dev] [puppet] deprecation warning everywhere issue

Thanks Emilien, This is what I was mentioning to you on IRC last week as a must fix for Mitaka. I'd like to also backport this to Liberty once it lands. On Mon, Dec 21, 2015 at 10:48 AM, Emilien Macchi wrote: > Hello, > > I just reported [1] which affects puppet-keystone

Re: [openstack-dev] [puppet] deprecation warning everywhere issue

["${region}/${real_service_name}"] ~> Service <| name == 'glance-api' |> Keystone_endpoint["${region}/${real_service_name}"] -> Glance_image<||> } I have not checked the other modules. I will be around for reviews on this if you ping me via email. On Tue,

Re: [openstack-dev] [puppet] including openstacklib::openstackclient

We decided in the meeting today to just to a naked include: https://review.openstack.org/#/c/253311/ https://review.openstack.org/#/c/254824/ On Tue, Dec 8, 2015 at 11:29 AM, Cody Herriges <c...@herriges.org> wrote: > Matt Fischer wrote: > > I found this bug in the liberty

Re: [openstack-dev] [puppet] proposing Cody Herriges part of Puppet OpenStack core

+1 On Tue, Dec 8, 2015 at 2:07 PM, Rich Megginson wrote: > On 12/08/2015 09:49 AM, Emilien Macchi wrote: > > Hi, > > Back in "old days", Cody was already core on the modules, when they were > hosted by Puppetlabs namespace. > His contributions [1] are very valuable to the

[openstack-dev] [puppet] including openstacklib::openstackclient

I found this bug in the liberty branch [1] over the weekend in the handling of openstack client between glance & keystone. As a part of fixing that I've discussed with Clayton and Michael Chapman just what the right way is to include the openstackclient. Keystone does it by conditionally

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

On Mon, Nov 23, 2015 at 9:42 AM, Morgan Fainberg wrote: > Hi everyone, > > This email is being written in the context of Keystone more than any other > project but I strongly believe that other projects could benefit from a > similar evaluation of the policy. > > Most

Re: [openstack-dev] [puppet] review the core-reviewer members

I too would like to thank Dan, Michael, and François for all their hard work. Michael and Dan in particular have helped me personally learn a bunch and been helpful in answering questions. On Thu, Nov 19, 2015 at 5:45 AM, Emilien Macchi wrote: > So here is a status: > > *

Re: [openstack-dev] [designate] Records for floating addresses are not removed when an instance is removed

You can do it like we did for juno Designate as covered in our Vancouver talk start about 21 minutes: https://www.youtube.com/watch?v=N8y51zqtAPA We've not ported the code to Kilo or Liberty yet but the approach may still work. On Fri, Nov 13, 2015 at 9:49 AM, Jaime Fernández

Re: [openstack-dev] [puppet] about $::os_service_default

This work is already being done by Clayton (and to a lesser extent me). >From the openstack modules POV it mainly involves moving the packaging code into a separate place [1][2] and then integrating with puppet-os_docker[3]. This os_docker work is only done for designate and heat and of course

Re: [openstack-dev] [puppet] weekly meeting #58 and next week

We have a very light schedule if anyone would like to discuss bugs or other issues, it would be a good time to do so. On Sat, Nov 7, 2015 at 12:29 PM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in

Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

Sorry I replied to this right away but used the wrong email address and it bounced! > I've appreciated all of richs v3 contributions to keystone. +1 from me. On Tue, Nov 3, 2015 at 4:38 AM, Sofer Athlan-Guyot wrote: > He's very good reviewer with a deep knowledge of

[openstack-dev] [puppet] operator_roles in puppet-swift?

I'd like to get some clarification and hopefully correction on the values for the two operator_roles variables. One is in manifests/keystone/auth.pp, and it claims "Array of strings. List of roles Swift considers as admin.". The other is in manifests/proxy/keystone.pp and it claims to be "a list

Re: [openstack-dev] [Heat] publicURL vs internalURL for resource validation

>From an operations point of view I'd also prefer all service to service calls to go through the internalURL is there a reason it's not default? On Oct 24, 2015 7:56 AM, "Attila Szlovencsak" wrote: > Hi! > > I am using Openstack Kilo (2015.1.1) > As I learned from the

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko <svasile...@mirantis.com> wrote: > > On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer <m...@mattfischer.com> > wrote: > >> I thought we had code in other places that split out stderr and only >> logged it if th

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

I thought we had code in other places that split out stderr and only logged it if there was an actual error but I cannot find the reference now. I think that matches the original proposal. Not sure I like idea #3. On Wed, Oct 21, 2015 at 9:21 AM, Stanislaw Bogatkin wrote:

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

On Thu, Oct 15, 2015 at 4:10 AM, Vladimir Kuklin wrote: > Gilles, > > 5xx errors like 503 and 502/504 could always be intermittent operational > issues. E.g. when you access your keystone backends through some proxy and > there is a connectivity issue between the proxy and

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

On Thu, Oct 8, 2015 at 5:38 AM, Vladimir Kuklin wrote: > Hi, folks > > * Intro > > Per our discussion at Meeting #54 [0] I would like to propose the uniform > approach of exception handling for all puppet-openstack providers accessing > any types of OpenStack APIs. > > *

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

>From a technical point of view, not forking and using a native library makes total sense. I think it would likely be faster and certainly cleaner than parsing output. Unfortunately I don't think that we have the resources to actively maintain the library. I think that's the main blocker for me.

Re: [openstack-dev] [puppet] Proposing Denis Egorenko core

On Tue, Oct 13, 2015 at 2:29 PM, Emilien Macchi wrote: > Denis Egorenko (degorenko) is working on Puppet OpenStack modules for > quite some time now. > > Some statistics [1] about his contributions (last 6 months): > * 270 reviews > * 49 negative reviews > * 216 positive

Re: [openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

I thought the agreement was that default would be assumed so that we didn't break backwards compatibility? On Oct 7, 2015 10:35 AM, "Rich Megginson" wrote: > tl;dr You must specify a domain when using domain scoped resources. > > If you are using domains with

Re: [openstack-dev] [ops] Operator Local Patches

Is the purge deleted a replacement for nova-manage db archive-deleted? It hasn't worked for several cycles and so I assume it's abandoned. On Sep 30, 2015 4:16 PM, "Matt Riedemann" wrote: > > > On 9/29/2015 6:33 PM, Kris G. Lindgren wrote: > >> Hello All, >> >> We

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

<mvoel...@vmware.com> wrote: > > Mark T. Voelker > > > > > On Sep 29, 2015, at 12:36 PM, Matt Fischer <m...@mattfischer.com> wrote: > > > > > > > > I agree with John Griffith. I don't have any empirical evidences to back > > my "

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

> > > > I agree with John Griffith. I don't have any empirical evidences to back > my "feelings" on that one but it's true that we weren't enable to enable > Cinder v2 until now. > > Which makes me wonder: When can we actually deprecate an API version? I > *feel* we are fast to jump on the

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

Yes, people are probably still using it. Last time I tried to use V2 it didn't work because the clients were broken, and then it went back on the bottom of my to do list. Is this mess fixed? http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html On Mon, Sep 28, 2015

Re: [openstack-dev] [Openstack-operators] [puppet] feedback request about puppet-keystone

On Fri, Sep 25, 2015 at 11:01 AM, Emilien Macchi wrote: > > > So after 5 days, here is a bit of feedback (13 people did the poll [1]): > > 1/ Providers > Except for 1, most of people are managing a few number of Keystone > users/tenants. > I would like to know if it's because

Re: [openstack-dev] [puppet] Fwd: Action required: stackforge/puppet-openstack project move

I'm not sure what value it has anymore but why not just readonly? On Sep 27, 2015 6:09 PM, "Emilien Macchi" wrote: > should we delete it? > > FYI: the module is deprecated in Juno release. > > I vote for yes. > > > Forwarded Message > Subject: Action

Re: [openstack-dev] [puppet] service default value functions

Clint, We're solving a different issue. Before anytime someone added an option we had this logic: if $setting { project_config/setting: value => $setting } else { project_config/setting: ensure => absent; } This was annoying to have to write for every single setting but without it, nobody

Re: [openstack-dev] [puppet] monasca,murano,mistral governance

Emilien, I've discussed this with some of the Monasca puppet guys here who are doing most of the work. I think it probably makes sense to move to that model now, especially since the pace of development has slowed substantially. One blocker before to having it "big tent" was the lack of test

Re: [openstack-dev] [puppet] Liberty Sprint Retrospective

I've updated the bug triage portion but tomorrow is a US holiday so you may not see much traction there until Tuesday. On Sun, Sep 6, 2015 at 6:59 PM, Emilien Macchi wrote: > Hi, > > With the goal to continually improve our way to work together, I would > like to build

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

+1 On Wed, Sep 2, 2015 at 12:09 PM, Emilien Macchi wrote: > TL;DR, I propose to move our developer documentation from wiki to > something like http://docs.openstack.org/developer/puppet-openstack > > (Look at http://docs.openstack.org/developer/tempest/ for example). > > For

  1   2   >