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: > I spoken with Sergii

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 wrote: > > On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer > wrote: > >> 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.

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 code, heat-engine uses the e

[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 of

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 keystone and puppet. > Thank

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 #openstack-meeting-4: > > https://et

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 requ

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 wrote: > When re

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: > > * François Charlier told

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 projects have a policy that

[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 including

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 group: > * strong knowl

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 wrote: > Matt Fischer wrote: > > I found this bug in the liberty branch [1] over the weeke

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 > do we do that? > > I

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

On Tue, May 17, 2016 at 12:47 PM, Andrew Laski wrote: > > > > On Tue, May 17, 2016, at 02:36 PM, Matt Fischer wrote: > > On Tue, May 17, 2016 at 12:25 PM, Andrew Laski wrote: > > I was in a discussion earlier about discouraging deployers from using > deprecated optio

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. > > This

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 contributions: > * Fantasti

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 useful. > > Right now

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 (I've only heard > abo

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 modules. > > [1] octavia, v

[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 Keystone

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

ng 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 wrote: > > We upgraded our dev environment last week to Keystone stable/mitaka. Since > then we're unable to show or set quotas

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] [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] [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 had any problems

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 wro

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

n | 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 > > -------- > Experience fanatical

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 > currently on review -

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 plan the Keystone mid

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 validat

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 Liberty. > > Currently we don't su

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 this > has uncovered a

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

On Mon, Apr 18, 2016 at 8: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 there yet (Except for mfish >> who has no patience) but we are getting closer. The goal is to get Fernet >> as the default token prov

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 wrote: > > > On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer > wrote: > >> On Mon, Apr 18, 2016 at 8:29 AM, Brant Knudson wrote: >> >>> >>> >>&

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 OpenStack deployme

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 there yet (Except for >>> mfish who has no patience) but we are

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 that has been bouncin

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 addition, it used to be tha

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. > > Historically, there ha

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 but also *all* modules.

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

f $configure_endpoint { Keystone_endpoint["${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 f

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 > opinion fully aware of our

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 by

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 scenarios involving Cinder

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 from the core reviewe

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] [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: > Hello, > > > I did a stackin

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 wrote: > > Last wee

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 AM,

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

_64-vmlinuz > ']' > > 2016-02-01 09: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 >

Re: [openstack-dev] [puppet] First Sprint proposal

Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly. Thanks. On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi wrote: > > > On 07/06/2015 02:05 PM, Matt Fischer wrote: > > I think this is a great idea. I'd like to get a firm date on the > > operato

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Is it really worth it to change the name? I agree the old name is somewhat confusing but the new name is not perfectly clear either and will still require a several line comment to explain what it's trying to do. What could simply be done now is to improve the existing comment in the conf file as w

Re: [openstack-dev] [puppet] running tempest on beaker jobs

We used Tempest for a time against our production environment. It was a pain to clean up but ephemeral test jobs solves that for you. A few questions: What version of tempest will be using? Will we maintain a blacklist if there are known failures? (although this is a pain to keep updated) On Sun,

Re: [openstack-dev] [puppet] running tempest on beaker jobs

My tempest experience is dated to Havana, so I'll consider it to be completely out of date. Glad to he about all these improvements. On Jul 13, 2015 2:12 PM, "Matthew Treinish" wrote: > On Sun, Jul 12, 2015 at 09:29:57PM -0600, Matt Fischer wrote: > > We used Tempes

[openstack-dev] [keystone] token revocation woes

I'm having some issues with keystone revocation events. The bottom line is that due to the way keystone handles the clean-up of these events[1], having more than a few leads to: - bad performance, up to 2x slower token validation with about 600 events based on my perf measurements. - database de

Re: [openstack-dev] [fuel][puppet] The state of collaboration: 5 weeks

Dmitry and I chatted some this morning and I'd at least like to address those issues so that we can resolve them and move on to the other discussions. I am not speaking for Emilien here, just jumping in as a core and trying to help resolve some of this. As Emilien notes, many of us do not work ful

[openstack-dev] [puppet] weekly meeting Agenda for July 21

A late notice but here's the agenda for tomorrow's meeting. Emilien is out so I will be running it. There's not a big agenda so if you have bugs you'd like to go into please bring them. https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150721 See you tomorrow

Re: [openstack-dev] [puppet] weekly meeting Agenda for July 21

, 2015 at 4:17 PM, Matt Fischer wrote: > A late notice but here's the agenda for tomorrow's meeting. Emilien is out > so I will be running it. There's not a big agenda so if you have bugs you'd > like to go into please bring them. > > https://etherpad.openstack.or

Re: [openstack-dev] [keystone] token revocation woes

le. I will be setting up monitoring for the revocation count and alerting me if it crosses probably 500 or so. If the problem gets worse then I think a custom no-op or sql driver is the next step. Thanks. On Wed, Jul 15, 2015 at 4:00 PM, Dolph Mathews wrote: > > > On Wed, Jul 15, 20

Re: [openstack-dev] [keystone] token revocation woes

'd be eager to > hear how it performs for you! > > On Tue, Jul 21, 2015 at 5:58 PM, Matt Fischer > wrote: > >> Dolph, >> >> Excuse the delayed reply, was waiting for a brilliant solution from >> someone. Without one, personally I'd prefer the cronjob

Re: [openstack-dev] [keystone] token revocation woes

t;> >> >> This was the origianal, linear search version of the code. >> >> >> https://review.openstack.org/#/c/55908/50/keystone/contrib/revoke/model.py,cm >> >> >> > What initially landed for Revocation Events was the tree-structure, right? > W

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

AP bind and everything else happens in mysql. > On 24 Jul 2015, at 05:51, Matt Fischer wrote: > > Julian, > > You want this hybrid backend driver. Bind against LDAP for auth, store > everything else in mysql: > > https://github.com/SUSE-Cloud/keystone-hybrid-backend >

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

On Fri, Jul 24, 2015 at 1:01 AM, Julian Edwards wrote: > On 24 July 2015 at 14:51, Matt Fischer wrote: > > Julian, > > > > You want this hybrid backend driver. Bind against LDAP for auth, store > > everything else in mysql: > > > > https://github

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

On Fri, Jul 24, 2015 at 12:02 PM, Adam Young wrote: > On 07/24/2015 12:00 AM, Julian Edwards wrote: > >> Hello, >> >> I am relatively new to Openstack and Keystone so please forgive me any >> crazy misunderstandings here. >> >> One of the problems with the existing LDAP Identity driver that I see

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

+1 On Jul 27, 2015 3:10 PM, "Emilien Macchi" wrote: > Puppet group, > > Yanis has been working in our group for a while now. > He has been involved in a lot of tasks, let me highlight some of them: > > * Many times, involved in improving consistency across our modules. > * Strong focus on data bi

Re: [openstack-dev] [keystone] token revocation woes

> This shouldn't be merged without benchmarking as it's purely a > performance-oriented change. > > > On Thu, Jul 23, 2015 at 11:40 AM, Matt Fischer > wrote: > >> Morgan asked me to post some of my numbers here. From my staging >> environment: >> >

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

Agree that you guys are way over thinking this. You don't need to rotate keys at exactly the same time, we do it in within a one or two hours typically based on how our regions are setup. We do it with puppet, puppet runs on one keystone node at a time and drops the keys into place. The actual rota

Re: [openstack-dev] [Openstack-operators] Gaining access to consoles.

On Sun, Aug 9, 2015 at 11:59 PM, Tony Breeds wrote: > Hi All, > Nova has bug: https://bugs.launchpad.net/nova/+bug/1447679 (service > No-VNC > (port 6080) doesn't require authentication). > > Which explains that if you know the 'token'[1] associated with an instances > console you can get acc

Re: [openstack-dev] [Openstack-operators] Gaining access to consoles.

On Tue, Aug 11, 2015 at 8:16 PM, Tony Breeds wrote: > On Mon, Aug 10, 2015 at 07:16:43PM -0600, Matt Fischer wrote: > > > I'm not excited about making this the default until token revocations > don't > > impact performance the way that they do now. I don't kno

Re: [openstack-dev] [Openstack-operators] Gaining access to consoles.

Oh.. oops. Yeah if that's the case then sorry, you can just ignore me! On Tue, Aug 11, 2015 at 8:39 PM, Tony Breeds wrote: > On Tue, Aug 11, 2015 at 08:24:10PM -0600, Matt Fischer wrote: > > It was covered some here: > > http://lists.openstack.org/pipermail/openstack-dev/2

Re: [openstack-dev] [fuel][puppet] The state of collaboration: 9 weeks

Dmitry, I've appreciated the feedback on my patches from your team and the work they are doing, it's great that everyone is working together better now. I think getting more puppet core reviewers is certainly on the horizon and will happen with continued effort, it just takes time and trust. But i

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

+1 from me as well. On Tue, Aug 25, 2015 at 2:30 PM, Rich Megginson wrote: > This concerns the support of the names of domain scoped Keystone resources > (users, projects, etc.) in puppet. > > At the puppet-openstack meeting today [1] we decided that puppet-openstack > will support Keystone doma

Re: [openstack-dev] [puppet] [tc] applying for vulnerability:managed tag

Some questions: What would constitute a vulnerability for openstack-puppet since we're mainly consuming the upstream code? Would having an insecure default value on a parameter meet the criteria? What if the upstream default is also bad? We certainly also have some examples that should never be

Re: [openstack-dev] [puppet] CI: make heat, Ironic, glance beaker non voting on trusty

+1, I guess we need to watch and see if they pass eventually but that's no guarantee that they won't break again in L or M etc. On Mon, Aug 31, 2015 at 3:48 PM, Emilien Macchi wrote: > So it he has been more than one month Ubuntu doesn't provide fixes for > Heat, Ironic, and Glance. > It's block

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 now, most of our doc

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 a Sprint Retrospective fro

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 cover

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 co

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 the current implement

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 required: stackforge/puppet-

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 at

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 deprecat

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 have some pretty good contributi

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

M, Mark Voelker wrote: > > Mark T. Voelker > > > > > On Sep 29, 2015, at 12:36 PM, Matt Fischer wrote: > > > > > > > > I agree with John Griffith. I don't have any empirical evidences to back > > my "feelings" on that one but it

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 puppet-keystone, there is a proposed

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. O

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 reviews > * 36 disagreeme

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. > > * Problem Description > > W

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 backends which > disapp

Re: [openstack-dev] [puppet] Weekly meeting #36

Emilien, sbadia, and spredzy are out. Given that agenda, should we cancel since its right after the summit and a holiday? My update (the only other thing on the agenda) is that the clean-up is done. On Mon, May 25, 2015 at 4:14 PM, Colleen Murphy wrote: > Hi everyone, > > Here's an initial agend

Re: [openstack-dev] [Openstack-operators] [openstack-operators][chef] OpenStack+Chef is part of the big tent

Congrats and welcome! On May 26, 2015 5:35 PM, "JJ Asghar" wrote: > Hey everyone! > > I’d like to just drop a note to the list saying thank you and > congratulations to our general community. > > As of 2015-05-26 we’ve been merged into the “big tent”[1] sanctioning us > as an official OpenStack p

Re: [openstack-dev] [puppet] OpenStack Puppet modules boilerplate

This is great work guys. Can we add it to the wiki too? Also +2 on the name from Emilien. On Fri, May 22, 2015 at 6:12 PM, Emilien Macchi wrote: > > > On 05/22/2015 04:53 PM, Sebastien Badia wrote: > > Hi, > > > > During the Puppet session (during the Vancouver summit), we talked about > > a bo

Re: [openstack-dev] [Puppet] Proposed Change in Nova Service Defaults

I'd like them to default to enabled as well since it matches the other modules as you said. Was the intent here to allow bringing up new compute hosts without them being enabled? If so there's another flag that could be set to manage that state. As for the patch itself, we need to change it for al

Re: [openstack-dev] [puppet] Renaming the IRC channel to #openstack-puppet

I would love to do this. +2! On Fri, May 29, 2015 at 1:39 PM, Mathieu Gagné wrote: > Hi, > > We recently asked for our IRC channel (#puppet-openstack) to be logged > by the infra team. We happen to be the only channel suffixing the word > "openstack" instead of prefixing it. [1] > > I would like

Re: [openstack-dev] [puppet] [fuel] more collaboration request

We as a community don't do a great job watching bugs, so personally I'd prefer that fuel developers just push patches, filing a bug too if you want. (Note: we do need to improve our bug tracking!) However, I don't think that asking puppet openstack devs to ask in the fuel channel if a given bug is

Re: [openstack-dev] [puppet] (officially) deprecate stable/{grizzly, havana} branches

+1 from me for deprecation. I'd also like to know or have an official policy for future deprecations, such as when will we deprecate Icehouse? On Tue, Jun 16, 2015 at 9:50 AM, Emilien Macchi wrote: > Hi, > > Some of our modules have stable/grizzly and stable/havana branches. Some > of them have

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

I am planning on looking into Murano later this year so I'd be interested in helping review this code. I'm puppet-core so feel free to add me to reviews and I can look as time permits. On Wed, Jun 17, 2015 at 9:49 AM, Serg Melikyan wrote: > Emilien, > > Thank you for your proposal, I completely

Re: [openstack-dev] [puppet] Clarification of 'Puppet Modules' Project Scope

I'm torn on this. Pedantically option A makes the most sense, but option B gives us more control over the supporting modules. I like having OpenStack CI run on vswitch and ceph rather than the typical github merge process. On Mon, Jun 22, 2015 at 11:05 AM, Richard Raseley wrote: > I am currently

Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

I can take a look at these tonight. Maybe also Clayton can review them? Neither of us were involved in the patches to my knowledge. On Jun 29, 2015 5:09 PM, "Andrew Woodward" wrote: > Hi > > Recent changes in the puppet modules infra left stackforge/puppet-ceph CI > broken. We've resolved the iss

  1   2   >