[openstack-dev] [tripleo] Puppet elements support
Hi TripleO community,
I would be really interested by helping to bring Puppet elements support
in TripleO.
So far I've seen this work:
https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat
which is a very good bootstrap but really outdated.
After some discussion with Greg Haynes on IRC, we came up with the idea
to create a repo (that would be move in Stackforge or OpenStack git) and
push the bits from what has been done by HP folks with updates &
improvements.
I started a basic repo
https://github.com/enovance/tripleo-puppet-elements that could be moved
right now on Stackforge to let the community start the work.
My proposal is:
* move this repo (or create a new one directly on
github/{stackforge,openstack?})
* push some bits from "agroup" original work.
* continue the contributions, updates & improvements.
Any thoughts?
--
Emilien Macchi
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Puppet elements support
So this is the patch to move the repo on Stackforge:
https://review.openstack.org/#/c/120285
Of course, I copy/paste Gerrit permissions from tripleo-image-elements
project, so people core in tripleo-image-elements will obviously be core
on tripleo-puppet-elements.
Emilien Macchi
On 09/08/2014 07:11 PM, Emilien Macchi wrote:
> Hi TripleO community,
>
> I would be really interested by helping to bring Puppet elements support
> in TripleO.
> So far I've seen this work:
> https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat
> which is a very good bootstrap but really outdated.
> After some discussion with Greg Haynes on IRC, we came up with the idea
> to create a repo (that would be move in Stackforge or OpenStack git) and
> push the bits from what has been done by HP folks with updates &
> improvements.
>
> I started a basic repo
> https://github.com/enovance/tripleo-puppet-elements that could be moved
> right now on Stackforge to let the community start the work.
>
> My proposal is:
> * move this repo (or create a new one directly on
> github/{stackforge,openstack?})
> * push some bits from "agroup" original work.
> * continue the contributions, updates & improvements.
>
> Any thoughts?
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer
done, you're now core in TripleO; Thanks Bob for your hard work! On Mon, Oct 22, 2018 at 4:55 PM Jason E. Rist wrote: > On 10/19/2018 06:23 AM, Juan Antonio Osorio Robles wrote: > > Hello! > > > > > > I would like to propose Bob Fournier (bfournie) as a core reviewer in > > TripleO. His patches and reviews have spanned quite a wide range in our > > project, his reviews show great insight and quality and I think he would > > be a addition to the core team. > > > > What do you folks think? > > > > > > Best Regards > > > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > yup. > > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > Freenode: jrist > github/twitter: knowncitizen > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] CI is broken
I updated the bugs, and so far we have one alert left: https://bugs.launchpad.net/tripleo/+bug/1801969 The patch is in gate, be patient and then we'll be able to +A/recheck stuff again. On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles < jaosor...@redhat.com> wrote: > Hello folks, > > > Please do not attempt to merge or recheck patches until we get this > sorted out. > > We are dealing with several issues that have broken all jobs. > > https://bugs.launchpad.net/tripleo/+bug/1801769 > https://bugs.launchpad.net/tripleo/+bug/1801969 > https://bugs.launchpad.net/tripleo/+bug/1802083 > https://bugs.launchpad.net/tripleo/+bug/1802085 > > Best Regards! > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] CI is broken
No alert anymore, gate is green. recheck if needed. On Wed, Nov 7, 2018 at 2:22 PM Emilien Macchi wrote: > I updated the bugs, and so far we have one alert left: > https://bugs.launchpad.net/tripleo/+bug/1801969 > > The patch is in gate, be patient and then we'll be able to +A/recheck > stuff again. > > On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles < > jaosor...@redhat.com> wrote: > >> Hello folks, >> >> >> Please do not attempt to merge or recheck patches until we get this >> sorted out. >> >> We are dealing with several issues that have broken all jobs. >> >> https://bugs.launchpad.net/tripleo/+bug/1801769 >> https://bugs.launchpad.net/tripleo/+bug/1801969 >> https://bugs.launchpad.net/tripleo/+bug/1802083 >> https://bugs.launchpad.net/tripleo/+bug/1802085 >> >> Best Regards! >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] no recheck / no workflow until gate is stable
We have serious issues with the gate at this time, we believe it is a mix of mirrors errors (infra) and tempest timeouts (see https://review.openstack.org/617845). Until the situation is resolved, do not recheck or approve any patch for now. Thanks for your understanding, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
+1 to have him part of TripleO CI core team, thanks for your dedication and hard work. I'm glad to see you're learning fast. Keep your motivation and thanks again! On Thu, Nov 15, 2018 at 11:33 AM Alex Schultz wrote: > +1 > On Thu, Nov 15, 2018 at 8:51 AM Sagi Shnaidman > wrote: > > > > Hi, > > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO and > TripleO CI. He also helps in other projects including but not limited to > Infrastructure. > > He shows a very good understanding how TripleO and CI works and I'd like > suggest him as core reviewer of TripleO in CI related code. > > > > Please vote! > > My +1 is here :) > > > > Thanks > > -- > > Best regards > > Sagi Shnaidman > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches
+1 for me, I haven't seen much interest in keeping these branches for puppet modules. I also would like to hear from our users though. On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin wrote: > Hello, > > We've been talking for a while about the deprecation and removal of the > stable/newton branches. > I think it's time now that we get rid of them, we have no open patches > and Newton is considered EOL. > > Could cores get back with a quick feedback and then the stable team can > get rid of those whenever they have time. > > Best regards > Tobias > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Feedback about our project at Summit
Hi folks, I wasn't at the Summit but I was interested by the feedback people gave about TripleO so I've discussed with a few people who made the trip. I would like to see what actions we can take on short and long term to address it. I collected some thoughts here: https://etherpad.openstack.org/p/BER-tripleo-feedback Which is based on https://etherpad.openstack.org/p/BER-deployment-tools-feedback initially. Feel fee to add more feedback if missing, and also comment what was written. If you're aware of some WIP that address the feedback, adjust some wording if needed or just put some links if something exists and is documented already. I believe it is critical to us to listen this feedback and include some of it into our short term roadmap, so we can reduce some frustration that we can hear sometimes. Thanks for your help, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Workflows Squad changes
On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: [...] > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > [...] Not a member of the squad but +2 to the idea Thanks for proposing, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] resources ID in configuration files
Hi folks, I've been looking at how deploying Neutron Server (on Icehouse release) and I can see we have now to provide the admin tenant ID in neutron.conf to be able to send notifications to Nova about port updates [1] thru Nova API. Working on configuration management for a while, it's a tough task to put ID in configuration files instead of resource names but still doable at least. I understand that Keystone API v3 now requires to use ID because of domains, but we I would like to think at a smarter way in OpenStack components (Neutron in my case) where we could get the resource ID (here the admin tenant) using Keystone API and consume it directly in the code. I sent a first patch [2] which unfortunately won't work when using Keystone API v3, so I would like to discuss here about another approach. Should we continue to that way and add a new parameter to specify which domain (in case of Keystone v3 use)? Am I wrong in all way? [1] https://bugs.launchpad.net/neutron/+bug/1302814 [2] https://review.openstack.org/#/c/85492/ Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] tripleo-puppet-elements is alive!
{Puppet-OpenStack,TripleO} developpers,
For your information
https://github.com/openstack/tripleo-puppet-elements is now alive.
Puppet Group has been assigned core on this project since most of
contribution will be Puppet code. Good news! Dan Prince is both TripleO
& Puppet core member, so he will participate to the review process with
both hats. By the way, if this is an issue for someone, we can create a
new group and change the permissions.
I think the next step is to prepare blueprints/specs in
https://github.com/openstack/tripleo-specs and decide how it goes.
For now, some thoughts have already been written here:
https://etherpad.openstack.org/p/ci7jWq2lRb
This etherpad was built for brainstorming only.
The idea is to bring a new topic for the next summit where we could
discuss together about design:
https://etherpad.openstack.org/p/kilo-tripleo-summit-topics
Maybe we could arrange a first meeting with people interested by
contributing to this, and then decide where we should start.
What do you think?
Thanks for reading so far.
--
Emilien Macchi
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tuskar] Puppet module
Hi, I was looking at deploying Tuskar API with Puppet and I was wondering if you guys have already worked on a Puppet module. If not, I think we could start something in stackforge like we already did for other OpenStack components. Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] Puppet module
Just started a PoC: https://github.com/enovance/puppet-tuskar Once I'll finish unit tests, I'll move it to Stackforge. On 10/29/2014 10:25 AM, Jay Dobies wrote: > Nope, there isn't a puppet module for deploying Tuskar, but starting one > makes sense. > > On 10/28/2014 06:04 PM, Emilien Macchi wrote: >> Hi, >> >> I was looking at deploying Tuskar API with Puppet and I was wondering if >> you guys have already worked on a Puppet module. >> >> If not, I think we could start something in stackforge like we already >> did for other OpenStack components. >> >> Thanks, >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] Puppet module
Sebastien Badia & I finished the code (manifests + unit tests) and now move puppet-tuskar in Stackforge: https://review.openstack.org/#/c/132488/ Would be great to have reviews from Tuskar folks. Thanks! Emilien On 10/29/2014 10:21 PM, Emilien Macchi wrote: > Just started a PoC: https://github.com/enovance/puppet-tuskar > > Once I'll finish unit tests, I'll move it to Stackforge. > > On 10/29/2014 10:25 AM, Jay Dobies wrote: > > Nope, there isn't a puppet module for deploying Tuskar, but starting one > > makes sense. > > > > On 10/28/2014 06:04 PM, Emilien Macchi wrote: > >> Hi, > >> > >> I was looking at deploying Tuskar API with Puppet and I was wondering if > >> you guys have already worked on a Puppet module. > >> > >> If not, I think we could start something in stackforge like we already > >> did for other OpenStack components. > >> > >> Thanks, > >> > >> > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - Evacuate a agent node
At eNovance, we have implemented this feature as a service: https://github.com/enovance/neutron-l3-healthcheck It checks L3 agents status and reschedule routers if an agent is down. It's working for Grizzly and Havana (two different branches). Regards, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 09/12/2013 09:45 AM, Yongsheng Gong wrote: > To implement the 'evacuation' is also possible. > > > On Thu, Sep 12, 2013 at 3:43 PM, Yongsheng Gong > mailto:gong...@unitedstack.com>> wrote: > > set the agent's admin status to False will empty up the agent's > resources. but it will not move the owned resources. > > > On Thu, Sep 12, 2013 at 3:36 PM, Endre Karlson > mailto:endre.karl...@gmail.com>> wrote: > > Is it possible to get a "evacuation" command for a node > running agents ? Say moving all the agents owned resources > from network node a > b? > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] [Docs] Documentation PTL Candidacy
+1 Anne is doing without any doubt an amazing job on OpenStack manuals. Thank you Anne, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 09/22/2013 08:19 PM, Anne Gentle wrote: > Hi all, > I'm writing to declare my intention to run for OpenStack documentation > program technical lead. [1] > > I've been working on OpenStack docs since September 2010, and it has > been an honor and a privilege to serve in this position informally > prior to having documentation declared a program. I've been serving as > the interim PTL as encouraged by my doc peers. > > In Havana we've been hard at work (and continue to do so), refactoring > the openstack-manuals repo to ensure installation, configuration, and > administration info is as complete and accurate as we can, including > the addition of automation tools for gathering configuration options > into one location. > > We've added an End User Guide, an Admin User Guide, and a Cloud > Administration Guide to document OpenStack as a whole, including all > the clients and the things you can do with your OpenStack clouds > through command-line calls. > > We also work on API documentation to bring you a compete reference > listing of all OpenStack APIs including example requests and responses. > > In the last year we've held two successful book sprints in the past > year resulting in the OpenStack Operations Guide and the OpenStack > Security Guide. We're actively recruiting writers for a book sprint to > write an OpenStack Architecture Design Guide. The Operations Guide has > been translated to Chinese and Japanese. > > I believe the documentation PTL role is one of coordination, coaching, > and providing platforms for documentation. This doesn't happen in > isolation and requires constant attention and coordination. I do know > our shortcomings and continue to work through the difficulties we face > trying to document a fast-moving integrated set of projects. In the > future I'd like to recruit more upstream OpenStack writers and have > designated project doc leads. > > I continue to be the top committer to the openstack-manuals repo [2] > and I am an active reviewer of all docs repos. [3] > > I'm proud of the work we've done so far and would be privileged to > continue this most challenging work. > Thanks, > Anne > > 1. Wow, that sounds too formal, but that's what this email is. > 2. https://github.com/openstack/openstack-manuals/graphs/contributors > 3. https://review.openstack.org/#/q/reviewer:anne%2540openstack.org,n,z > > > > ___ > Openstack-docs mailing list > openstack-d...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Configuration file generator
Also for your information, I created a bug : https://bugs.launchpad.net/neutron/+bug/1199963 and a first patchset for generating the new configuration file with Oslo config scripts : https://review.openstack.org/#/c/36546/ Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 07/22/2013 06:34 PM, Julien Danjou wrote: > Hi there, > > I've been working on the changes that would need to be done to make the > default config generator work for Neutron. > > However, the current default config generator doesn't support the > possibility to generate different configuration files (e.g. one per > service/plugin). I can imagine two options: > > a. move every options in oslo.config.cfg.CONF, moving the plugins into >their own section rather than in their own file, register all options >at module-level, avoiding duplicate options. > > b. enhance config.generator to generate a config file from a particular >object (not always olso.config.cfg.CONF like it's done currently). >That means Neutron should evolve to provide a global CONF object per >plugin at least. > > Option a. is how all other OpenStack projects¹ are working so far. > Option b. requires a bit more work on both side. > > Is there any particular way you guys see things? > > > ¹ nova, ceilometer and heat at least for now > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] The way to use one config file with new oslo module
Hi, Since https://review.openstack.org/#/c/36476/ has been merged, heat could use only one configuration file : heat.conf instead of heat-engine.conf, heat-api.conf, etc. I would like your thoughts about deleting old configuration files, since that could break something in the CI. I already made a first patch here : https://review.openstack.org/#/c/40257/ But let's discuss about it before continuing to work on this patch. Cheers, -- Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] The way to use one config file with new oslo module
FYI, I reported a bug about that. https://bugs.launchpad.net/heat/+bug/1209141 Let's start the discussion with Heat developers to see how we could fix that, since it concerns single config file. Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On Wed 07 Aug 2013 09:49:16 AM CEST, Julien Danjou wrote: > On Wed, Aug 07 2013, Clint Byrum wrote: > >> Does oslo.config or anything in oslo-incubator give us some help with >> deprecating old config files? > > No, but as far as I know, it should be compatible anyway since the 3 > files just got merged in to one. No options where moved nor syntax > changed by this, so the transition should be almost pain less. > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Blueprint proposal - Import / Export images with user properties
Hi, I would like to discuss here about two blueprint proposal (maybe could I merge them into one if you prefer) : https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties *Use case* : I would like to set specific properties to an image which could represent a signature, and useful for licensing requirements for example. To do that, I should be able to export an image with user properties included. Then, a user could reuse the exported image in the public cloud, and Glance will be aware about its properties. Obviously, we need the import / export feature. The idea here is to be able to identify an image after cloning or whatever with a property field. Of course, the user could break it in editing the image manually, but I consider he / she won't. Let me know if you have any thoughts and if the blueprint is valuable. Regards, -- Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Blueprint proposal - Import / Export images with user properties
Hi Mark, I was thinking at the OVF container format first since as far I know, it does support metadatas. Thank's, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 08/14/2013 06:34 PM, Mark Washenberger wrote: > Lets dig into this a bit more so that I can understand it. > > Given that we have properties that we want to export with an image, > where would those properties be stored? Somewhere in the image data > itself? I believe some image formats support metadata, but I can't > imagine all of them would. Is there a specific format you're thinking > of using? > > > On Wed, Aug 14, 2013 at 8:36 AM, Emilien Macchi > mailto:emilien.mac...@enovance.com>> wrote: > > Hi, > > > I would like to discuss here about two blueprint proposal (maybe > could I merge them into one if you prefer) : > > https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties > https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties > > *Use case* : > I would like to set specific properties to an image which could > represent a signature, and useful for licensing requirements for > example. > To do that, I should be able to export an image with user > properties included. > > Then, a user could reuse the exported image in the public cloud, > and Glance will be aware about its properties. > Obviously, we need the import / export feature. > > The idea here is to be able to identify an image after cloning or > whatever with a property field. Of course, the user could break it > in editing the image manually, but I consider he / she won't. > > > Let me know if you have any thoughts and if the blueprint is valuable. > > Regards, > > -- > Emilien Macchi > > # OpenStack Engineer > // eNovance Inc. http://enovance.com > // ? emil...@enovance.com <mailto:emil...@enovance.com> ? +33 (0)1 49 > 70 99 80 > // 10 rue de la Victoire 75009 Paris > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Blueprint proposal - Import / Export images with user properties
Thank's Mark, it's exactly this kind of feedback I was looking for. As you suggested, I'm going to make a single blueprint for OVF. Regards, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 08/14/2013 07:39 PM, Mark Washenberger wrote: > I think this could fit alongside a current blueprint we've discussed > (https://blueprints.launchpad.net/glance/+spec/iso-image-metadata) > that does similar things for metadata in isos. > > In general, I think the sane way to add a feature like this is as an > optional container-format-specific plugin for import and export. Since > the import and export features are still in pretty early stages of > development (advanced on design though!), I don't expect such a > feature would land until mid Icehouse, just fyi. > > Can you restructure these blueprints as a single bp feature to > "export/import metadata in ovf"? > > > On Wed, Aug 14, 2013 at 10:09 AM, Emilien Macchi > mailto:emilien.mac...@enovance.com>> wrote: > > Hi Mark, > > > I was thinking at the OVF container format first since as far I > know, it does support metadatas. > > > Thank's, > > > Emilien Macchi > > # OpenStack Engineer > // eNovance Inc. http://enovance.com > // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 (0)1 49 > 70 99 80 > // 10 rue de la Victoire 75009 Paris > > On 08/14/2013 06:34 PM, Mark Washenberger wrote: >> Lets dig into this a bit more so that I can understand it. >> >> Given that we have properties that we want to export with an >> image, where would those properties be stored? Somewhere in the >> image data itself? I believe some image formats support metadata, >> but I can't imagine all of them would. Is there a specific format >> you're thinking of using? >> >> >> On Wed, Aug 14, 2013 at 8:36 AM, Emilien Macchi >> > <mailto:emilien.mac...@enovance.com>> wrote: >> >> Hi, >> >> >> I would like to discuss here about two blueprint proposal >> (maybe could I merge them into one if you prefer) : >> >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties >> >> *Use case* : >> I would like to set specific properties to an image which >> could represent a signature, and useful for licensing >> requirements for example. >> To do that, I should be able to export an image with user >> properties included. >> >> Then, a user could reuse the exported image in the public >> cloud, and Glance will be aware about its properties. >> Obviously, we need the import / export feature. >> >> The idea here is to be able to identify an image after >> cloning or whatever with a property field. Of course, the >> user could break it in editing the image manually, but I >> consider he / she won't. >> >> >> Let me know if you have any thoughts and if the blueprint is >> valuable. >> >> Regards, >> >> -- >> Emilien Macchi >> >> # OpenStack Engineer >> // eNovance Inc. http://enovance.com >> // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 >> (0)1 49 70 99 80 >> // 10 rue de la Victoire 75009 Paris >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Blueprint proposal - Import / Export images with user properties
Mark, As you suggested, I've created a single blueprint : https://blueprints.launchpad.net/glance/+spec/export-import-image-metadata-ovf I don't have any idea about its dependencies, maybe could you fix the blueprint if needed. I think you can also delete : https://blueprints.launchpad.net/glance/+spec/export-import-image-metadata-ovf https://blueprints.launchpad.net/glance/+spec/export-export-image-metadata-ovf ..which are now deprecated. (I'm not able to do it). Let me know if the blueprint looks good or if we need to discuss more. Also, we could be interested by implementing it. Thank you, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 08/14/2013 07:39 PM, Mark Washenberger wrote: > I think this could fit alongside a current blueprint we've discussed > (https://blueprints.launchpad.net/glance/+spec/iso-image-metadata) > that does similar things for metadata in isos. > > In general, I think the sane way to add a feature like this is as an > optional container-format-specific plugin for import and export. Since > the import and export features are still in pretty early stages of > development (advanced on design though!), I don't expect such a > feature would land until mid Icehouse, just fyi. > > Can you restructure these blueprints as a single bp feature to > "export/import metadata in ovf"? > > > On Wed, Aug 14, 2013 at 10:09 AM, Emilien Macchi > mailto:emilien.mac...@enovance.com>> wrote: > > Hi Mark, > > > I was thinking at the OVF container format first since as far I > know, it does support metadatas. > > > Thank's, > > > Emilien Macchi > > # OpenStack Engineer > // eNovance Inc. http://enovance.com > // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 (0)1 49 > 70 99 80 > // 10 rue de la Victoire 75009 Paris > > On 08/14/2013 06:34 PM, Mark Washenberger wrote: >> Lets dig into this a bit more so that I can understand it. >> >> Given that we have properties that we want to export with an >> image, where would those properties be stored? Somewhere in the >> image data itself? I believe some image formats support metadata, >> but I can't imagine all of them would. Is there a specific format >> you're thinking of using? >> >> >> On Wed, Aug 14, 2013 at 8:36 AM, Emilien Macchi >> > <mailto:emilien.mac...@enovance.com>> wrote: >> >> Hi, >> >> >> I would like to discuss here about two blueprint proposal >> (maybe could I merge them into one if you prefer) : >> >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties >> >> *Use case* : >> I would like to set specific properties to an image which >> could represent a signature, and useful for licensing >> requirements for example. >> To do that, I should be able to export an image with user >> properties included. >> >> Then, a user could reuse the exported image in the public >> cloud, and Glance will be aware about its properties. >> Obviously, we need the import / export feature. >> >> The idea here is to be able to identify an image after >> cloning or whatever with a property field. Of course, the >> user could break it in editing the image manually, but I >> consider he / she won't. >> >> >> Let me know if you have any thoughts and if the blueprint is >> valuable. >> >> Regards, >> >> -- >> Emilien Macchi >> >> # OpenStack Engineer >> // eNovance Inc. http://enovance.com >> // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 >> (0)1 49 70 99 80 >> // 10 rue de la Victoire 75009 Paris >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Blueprint proposal - Import / Export images with user properties
Wrong copy paste, sorry. We can delete : https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties Thank's, Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 08/14/2013 07:39 PM, Mark Washenberger wrote: > I think this could fit alongside a current blueprint we've discussed > (https://blueprints.launchpad.net/glance/+spec/iso-image-metadata) > that does similar things for metadata in isos. > > In general, I think the sane way to add a feature like this is as an > optional container-format-specific plugin for import and export. Since > the import and export features are still in pretty early stages of > development (advanced on design though!), I don't expect such a > feature would land until mid Icehouse, just fyi. > > Can you restructure these blueprints as a single bp feature to > "export/import metadata in ovf"? > > > On Wed, Aug 14, 2013 at 10:09 AM, Emilien Macchi > mailto:emilien.mac...@enovance.com>> wrote: > > Hi Mark, > > > I was thinking at the OVF container format first since as far I > know, it does support metadatas. > > > Thank's, > > > Emilien Macchi > > # OpenStack Engineer > // eNovance Inc. http://enovance.com > // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 (0)1 49 > 70 99 80 > // 10 rue de la Victoire 75009 Paris > > On 08/14/2013 06:34 PM, Mark Washenberger wrote: >> Lets dig into this a bit more so that I can understand it. >> >> Given that we have properties that we want to export with an >> image, where would those properties be stored? Somewhere in the >> image data itself? I believe some image formats support metadata, >> but I can't imagine all of them would. Is there a specific format >> you're thinking of using? >> >> >> On Wed, Aug 14, 2013 at 8:36 AM, Emilien Macchi >> > <mailto:emilien.mac...@enovance.com>> wrote: >> >> Hi, >> >> >> I would like to discuss here about two blueprint proposal >> (maybe could I merge them into one if you prefer) : >> >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-export-properties >> >> https://blueprints.launchpad.net/glance/+spec/api-v2-import-properties >> >> *Use case* : >> I would like to set specific properties to an image which >> could represent a signature, and useful for licensing >> requirements for example. >> To do that, I should be able to export an image with user >> properties included. >> >> Then, a user could reuse the exported image in the public >> cloud, and Glance will be aware about its properties. >> Obviously, we need the import / export feature. >> >> The idea here is to be able to identify an image after >> cloning or whatever with a property field. Of course, the >> user could break it in editing the image manually, but I >> consider he / she won't. >> >> >> Let me know if you have any thoughts and if the blueprint is >> valuable. >> >> Regards, >> >> -- >> Emilien Macchi >> >> # OpenStack Engineer >> // eNovance Inc. http://enovance.com >> // ✉ emil...@enovance.com <mailto:emil...@enovance.com> ☎ +33 >> (0)1 49 70 99 80 >> // 10 rue de la Victoire 75009 Paris >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [CI] Blueprint proposal: Add Plot Plugin support into jenkins-job-builder
Hi, I would like to discuss about a new blueprint [1] in openstack-ci project, concerning jenkins-job-builder software. Plop plugin [2] provides generic plotting (or graphing) capabilities in Jenkins. The idea is to bring the plugin support into jenkins-job-builder software. Best regards, [1] https://blueprints.launchpad.net/openstack-ci/+spec/jenkins-job-builder-plot [2] https://wiki.jenkins-ci.org/display/JENKINS/Plot+Plugin -- Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Backup documentation - to which doc it should go?
Hi Ronen, The best place for your documentation is in the OpenStack Bloc Storage guide [1]. If you need help with OpenStack manuals, we have a dedicated wiki page [2]. Please let us know if you need support. Regards, [1] https://github.com/openstack/openstack-manuals/tree/master/doc/src/docbkx/openstack-block-storage-admin [2] https://wiki.openstack.org/wiki/Documentation/HowTo Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 09/03/2013 12:50 PM, Ronen Kat wrote: > > I noticed the complains about code submission without appropriate > documentation submission, so I am ready to do my part for Cinder backup > I have just one little question. > Not being up to date on the current set of OpenStack manuals, and as I > noticed that the block storage admin guide lost a lot of content, to which > document(s) should I add the Cinder backup documentation? > > The documentation includes: > 1. Backup configuration > 2. General description of Cinder backup (commands, features, etc) > 3. Description of the available backup drivers > > Should all three go to the same place? Or different documents? > > Thanks, > > Regards, > __ > Ronen I. Kat > Storage Research > IBM Research - Haifa > Phone: +972.3.7689493 > Email: ronen...@il.ibm.com > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Improving Neutron L3 Agent with High Availability
Hi, The current implementation of Neutron L3 agent allows us to scale virtual routers on multiple agents but does not provide High Availability on : - namespaces, virtual interfaces (both in north and south) - established connections between external & internal network. The idea here is to start a discussion about a new design that we could implement in the next release. Since there exists some conversations on this topic, I want to share my ideas with a public document we wrote [1] with my team. Table of contents: - Abstract about current implementation - Current Architecture - Proposal #1: Health-check (which is not my final solution, but just an existing way). - Proposal #2: VRRP + conntrackd (new backends for improving L3 agent) - Design session proposal for next Summit Feel free to bring your thoughts. After the discussion, maybe could we write new blueprints. Note: the document is public and you are allowed to comment. If you need more access, I can of course grant you write rights. [1] https://docs.google.com/document/d/1DNAqRSOIZPqUxPVicbUMWWuRBJ90qJjVYe7Ox8rVtKE/edit?usp=sharing Regards, -- Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting, Tue Oct 20th, 21:00 UTC
Agenda is empty, meeting is canceled. Next week's meeting is also canceled because of OpenStack Summit. I hope you'll have a safe trip to Tokyo, see you there, On 10/19/2015 08:41 AM, Emilien Macchi wrote: > Dear PTLs, cross-project liaisons, and interested team members, > > We'll have a cross-project meeting tomorrow at 21:00 UTC, with the > following agenda: > > https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda > > Review past action items > Team announcements (horizontal, vertical, diagonal) > Open discussion > > For more details on this meeting, please see: > https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting > > See you there, > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [ceph] puppet-ceph working session
On 10/28/2015 11:09 AM, Andrew Woodward wrote: > For those of you interested at the summit, I'd like to get together at > some point and discuss / resolve issues on CI, and then talk about > release and possible roadmap. > > Let's pick a time so that we can meet together on this. Good idea, I suggest we meet in the Puppet work sessions, so we get attention from the team. Thanks, Emilien __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What's up with functional testing?
As a user[1], I would like to functionally test OpenStack services. I'm using Tempest (which is AFIK [2] the official OpenStack project for functional testing) and am able to validate that Puppet OpenStack module actually deploy services & make them work together which is the goal of Puppet OpenStack Integration testing [3]. Until now I was happy, until this bug [4] (TL;DR: Aodh can't be testing with Tempest which is a bug I'm working on, and not really related to this thread). I realized Aodh [5] (and apparently some other projects like Ceilometer) were using something else (gabbi [6]) for testing. How come some big tent projects do not use Tempest anymore for functional testing? I thought there was/is a move with tempest plugins that will help projects to host their tempest tests in their repos. Am I missing something? Any official decision taken? Is gabbi supported by OpenStack? I feel like there is currently 2 paths that try to do the same thing and as a user, I'm not happy. Please help me to understand, Thank you. [1] a user who deploy Puppet OpenStack modules in OpenStack Infra for CI purposes [2] http://goo.gl/sgI2D8 http://goo.gl/DTR1cL [3] https://github.com/openstack/puppet-openstack-integration#overview [4] https://bugs.launchpad.net/tempest/+bug/1509885 [5] https://github.com/openstack/aodh [6] https://pypi.python.org/pypi/gabbi/ -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What's up with functional testing?
On 10/28/2015 01:12 PM, Chris Dent wrote: > On Wed, 28 Oct 2015, Emilien Macchi wrote: > >> As a user[1], I would like to functionally test OpenStack services. > > Bless you. Let's all be more like that. > >> Until now I was happy, until this bug [4] (TL;DR: Aodh can't be testing >> with Tempest which is a bug I'm working on, and not really related to >> this thread). >> I realized Aodh [5] (and apparently some other projects like Ceilometer) >> were using something else (gabbi [6]) for testing. > > There's a fair amount of history here for which I don't know all the > details so I'll just try to address the gabbi related questions below > after this initial comment: > > aodh is not yet in tempest, but that's simply because it is not yet > done, not because there are not plans to do it. Tomorrow morning at > 9am in the Kiri room we're having a design session about functional > and integration testing in all three of ceilometer, aodh and gnocchi > and one of the primary topics is: getting all three to have tempest > plugins. One of the other primary topics is making new and existing > in-tree functional test as good and useful as possible. A lot of those > tests are not tempest because they've been extracted from pre-existing > so-called unit tests but were determined to not be because they use a > database. A small segment are API tests driven by gabbi as a result of > this spec[1] > > If you or anyone else have time to show up to that session, that would > be great. I was here and I'm happy to see the efforts [1] that are proposed for the next cycle. Having a Tempest plugin is really what I was asking in my initial request, thank you for considering that work. [1] https://etherpad.openstack.org/p/mitaka-telemetry-testing > >> How come some big tent projects do not use Tempest anymore for >> functional testing? I thought there was/is a move with tempest plugins >> that will help projects to host their tempest tests in their repos. > > Ceilometer projects started a migration to more in-tree functional > tests in advance of tempest-lib existing. These manifest as tests that > require a storage backend and have their own non-tempest job > description in project-config. > >> Am I missing something? Any official decision taken? >> Is gabbi supported by OpenStack? > > When I first released gabbi there was talk about it becoming either > part of QA or oslo but after showing it around the world a bit I had > feedback from several non-openstack people that they would be _far_ > more likely to contribute to it if it was not subject to the openstack > development model[0]. So it lives now as a project on github to which > people submit pull requests and travis takes care of CI. To avoid bus > termination errors, there are two other admins in addition to me who > have all the same rights with regard to merging and releasing and > maintaining on python. One of them is another OpenStack contributor > (jasonamyers). > > I'm obviously biased, but I think gabbi is teh ossum and makes writing > API tests easy and perhaps more importantly makes reading them later > fantastic. > > Within gnocchi and aodh, gabbi has been so successful at making it easy > to write API tests that it is now being used for writing integration > tests of aodh+gnocchi+ceilometer+heat. > >> I feel like there is currently 2 paths that try to do the same thing and >> as a user, I'm not happy. > > Yeah, that's perhaps a problem. One thing I'm hoping to explore (or > hoping someone else will explore) is making it easy to do gabbi > tests within a tempest plugin. This ought to be possible but there > are some humps to deal with regard to how gabbi orders and groups > tests. > > Again, I'm biased, but I think that gabbi would be a _huge_ asset for > API tests in tempest because by its very nature it is very close to > HTTP without a notion of a (python) client being involved. I think > this is an excellent guard for ensuring that OpenStack APIs are > sufficiently agnostic about their context. > >> Please help me to understand, > > I hope that adds a bit more info. I know it doesn't actually answer > the real question though. I hope some other voices will come along. Thanks for taking care of this topic, I'm glad you replied during the Summit so we can move forward on this topic and we can make sure our puppet-aodh module will be tested (one day) with Tempest. > > [0] I'm happy to discuss this elsewhere (in person, on another thread, > whatever) but it would be bad to let it distract this current thread. > [1] > http://specs.openstack.org/ope
Re: [openstack-dev] [Fuel][puppet] CI gate for regressions detection in deployment data
Why do you use [puppet] tag? Is there anything related to Puppet OpenStack modules we should take care of? Good luck, On 10/29/2015 11:24 PM, Bogdan Dobrelya wrote: > Hello. > There are few types of a deployment regressions possible. When changing > a module version to be used from upstream (or internal module repo), for > example from Liberty to Mitaka. Or when changing the composition layer > (modular tasks in Fuel). Specifically, adding/removing/changing classes > and a class parameters. > > An example regression for swift deployment data [0]. Something was > changed unnoticed by existing noop tests and as a result > the swift data became being stored in root partition. > > Suggested per-commit based regressions detection [1] for deployment data > assumes to automatically detect if a class in a noop catalog run has > gained or lost a parameter or if it has been updated to another value by > a patch under test. Later, this check could even replace existing noop > tests, everything will be checked automatically, unless every deployment > scenario is covered by a corresponding template, which are represented > as YAML files [2] in Fuel. > Note: The tool [3] can help to get all deployment cases (-Y) and all > deployment tasks (-S) as well. > > I propose to review the patch [1], understand how it works (see tl;dr > section below) and to start using it ASAP. The earlier we commit the > "initial" data layer state, less regressions would pop up. > > (tl;dr) > The check should be done for every modular component (aka deployment > task). Data generated in the noop catalog run for all classes and > defines of a given deployment task should be verified against its > "acknowledged" (committed) state. > And fail the test gate, if changes has been found, like new parameter > with a defined value, removed a parameter, changed a parameter's value. > > In order to remove a regression, a patch author will have to add (and > reviewers should acknowledge) detected changes in the committed state of > the deployment data. This may be done manually, with a tool like [3] or > by a pre-commit hook, or even at the CI side! > The regression check should show the diff between committed state and a > new state proposed in a patch. Changed state should be *reviewed* and > accepted with a patch, to became a committed one. So the deployment data > will evolve with *only* approved changes. And those changes would be > very easy to be discovered for each patch under review process! > No more regressions, everyone happy. > > Examples: > > - A. A patch author removed the mpm_module parameter from the > composition layer (apache modular task). The test should fail with a > > Diff: > @@ -90,7 +90,7 @@ > manage_user=> 'true', > max_keepalive_requests => '100', > mod_dir=> '/etc/httpd/conf.d', > - mpm_module => 'false', > + mpm_module => 'prefork', > name => 'Apache', > package_ensure => 'installed', > ports_file => '/etc/httpd/conf/ports.conf', > > It illustrates that the mpm_module's committed value was "false". > But the new one came as the 'prefork', likely from the apache class > defaults. > The solution: > Follow the failed build link and see for detected changes (a diff). > Acknowledge the changes and include rebuilt templates in the patch as a > new revision. The tool [3] (use -h for help) example command: > ./utils/jenkins/fuel_noop_tests.rb -q -b -s api-proxy/api-proxy_spec.rb > > Or edit the committed templates manually and include data changes in the > patch as well. > > -B. An upstream module author added the new parameter mpm_mode with a > default '123'. The test should fail with a > > Diff: >@@ -90,6 +90,7 @@ > manage_user=> 'true', > max_keepalive_requests => '100', > mod_dir=> '/etc/httpd/conf.d', >+ mpm_mode => '123', > mpm_module => 'false', > name => 'Apache', > package_ensure => 'installed', > > It illustrates that the composition layer is not consistent with the > upstream module data schema, and that could be a potential regression in > deployment (new parameter added upstream and goes with defaults, being > ignored by the composition manifest). > The solution is the same as for the case A. > > [0] https://bugs.launchpad.net/fuel/+bug/1508482 > [1] https://review.openstack.org/240015 > [2] > https://github.com/openstack/fuel-library/tree/master/tests/noop/astute.yaml > [3] > https://review.openstack.org/#/c/240015/7/utils/jenkins/fuel_noop_tests.rb > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-
Re: [openstack-dev] New [puppet] module for Magnum project
On 10/29/2015 11:26 PM, Potter, Nathaniel wrote: > Hi everyone, > > > > I’m interested in starting up a puppet module that will handle the > Magnum containers project. Would this be something the community might > want? Thanks! If this module is about deploying Magnum service(s) and configuration, that's a great idea to create puppet-magnum (we currently don't have it). Please look https://wiki.openstack.org/wiki/Puppet/New_module and come up on IRC if you have any questions, I'm glad someone is taking care of it! Emilien __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] review the core-reviewer members
Hi, At the summit we discussed about updating the core-reviewer members [1]. To continue the OpenStack meritocracy model, I believe we should keep the list consistent with how our group is currently working and who is really active [2]. Puppet OpenStack group would not be here without these people and we really appreciate the work done by our community. If you're not involved anymore in Puppet OpenStack project (following meetings, mailing-list, doing reviews and sending patches), we would appreciate your insight about updating this list. [1] https://review.openstack.org/#/admin/groups/134,members [2] http://stackalytics.com/report/contribution/puppetopenstack-group/180 Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer
At the Summit we discussed about scaling-up our team. We decided to investigate the creation of sub-groups specific to our modules that would have +2 power. I would like to start with puppet-keystone: https://review.openstack.org/240666 And propose Richard Megginson part of this group. Rich is leading puppet-keystone work since our Juno cycle. Without his leadership and skills, I'm not sure we would have Keystone v3 support in our modules. He's a good Puppet reviewer and takes care of backward compatibility. He also has strong knowledge at how Keystone works. He's always willing to lead our roadmap regarding identity deployment in OpenStack. Having him on-board is for us an awesome opportunity to be ahead of other deployments tools and supports many features in Keystone that real deployments actually need. I would like to propose him part of the new puppet-keystone-core group. Thank you Rich for your work, which is very appreciated. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #57
Hello! Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151103 Feel free to add any items you'd like to discuss. If our schedule allows it, we'll make bug triage during the meeting. Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] about $::os_service_default
I'm seeing a lot of patches using the new $::os_service_default. Please stop trying to using it at this time. The feature is not stable yet and we're testing it only for puppet-cinder module. I've heard Yanis found something that is not backward compatible with logging, but he's away this week so I suggest we wait next week. In the meantime, please do not use $::os_service_default outside puppet-cinder. Thanks a lot, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #57
On 11/02/2015 08:02 AM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151103 > > Feel free to add any items you'd like to discuss. > If our schedule allows it, we'll make bug triage during the meeting. > > Thanks, We did our meeting (late, thanks clock changes): http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-03-15.16.html Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer
On 11/03/2015 03:56 PM, Matt Fischer wrote: > 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. 2 positives votes from our core-reviewer team. No negative vote at all. I guess that's a 'yes', welcome Rich, you're the first puppet-keystone-core member! Note: anyone else core-reviewer on Puppet modules is also core on puppet-keystone by the way. Congrats Rich! > On Tue, Nov 3, 2015 at 4:38 AM, Sofer Athlan-Guyot <mailto:sathl...@redhat.com>> wrote: > > He's very good reviewer with a deep knowledge of keystone and puppet. > Thank you Richard for your help. > > +1 > > Emilien Macchi <mailto:emilien.mac...@gmail.com>> writes: > > > At the Summit we discussed about scaling-up our team. > > We decided to investigate the creation of sub-groups specific to our > > modules that would have +2 power. > > > > I would like to start with puppet-keystone: > > https://review.openstack.org/240666 > > > > And propose Richard Megginson part of this group. > > > > Rich is leading puppet-keystone work since our Juno cycle. Without his > > leadership and skills, I'm not sure we would have Keystone v3 support > > in our modules. > > He's a good Puppet reviewer and takes care of backward compatibility. > > He also has strong knowledge at how Keystone works. He's always > > willing to lead our roadmap regarding identity deployment in > > OpenStack. > > > > Having him on-board is for us an awesome opportunity to be ahead of > > other deployments tools and supports many features in Keystone that > > real deployments actually need. > > > > I would like to propose him part of the new puppet-keystone-core > > group. > > > > Thank you Rich for your work, which is very appreciated. > > -- > Sofer Athlan-Guyot > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] New Puppet module for Tacker Project
On 11/07/2015 05:29 AM, Dan Radez wrote: > I've recently become involved in the Tacker project: > https://wiki.openstack.org/wiki/Tacker > > I have been deploying with puppet and collected some puppet code that I > would like to push openstack in a new puppet module puppet-tacker. > > I've begun to collect the code here: > https://github.com/radez/puppet-tacker > > I've just found the page on the openstack puppet wiki about using cookie > cutter and modulesync. I start that process now, was interested to get a > mailing list discussion going. I'll be sure to complete it before I push > any code into openstack repos. > Hey Dan, Thanks for putting this effort in our community! Every new module has to follow this process: https://wiki.openstack.org/wiki/Puppet/New_module So we make sure our modules are consistent and compliant with our way to develop Puppet modules. In your case, I suggest to 1/ move the module to OpenStack namespace 2/ submit the patch in Governance to add the new repo, though I'm not sure this module can be "big tent", since afik Tacker is not big tent. We'll figure out with TC. 3/ Adapt your module with our Wiki page documentation, and the tool we use. I'm off next week, but don't hesitate to come up on #puppet-openstack (freenode) and ask for help. Emilien __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #58 and next week
Hello! Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110 I'm off all next week (holidays without IRC, and rare access to e-mails...), so mfish will be chair. During the week, if you have any problem with Puppet CI, you can ping degorenko on IRC. When I come back, I'll work on 7.0.0 release to create our stable/liberty branch. Thanks and see you soon, Emilien __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #59
Hello! Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC in #openstack-meeting-4: https <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> :// <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> etherpad.openstack.org <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> /p/puppet-openstack-weekly-meeting-2015111 <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>7 I'm back online tomorrow morning. Thanks, --- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #59
The second one. Sorry for confusion, I sent it from my phone. See you tomorrow! --- Emilien Macchi On Nov 16, 2015 1:24 PM, "Iury Gregory" wrote: > Hi Emilien, the link for the agenda is > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-2015111 > or > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117 > ? > Thanks o/ > > > 2015-11-16 14:04 GMT-03:00 Emilien Macchi : > >> Hello! >> >> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC >> in #openstack-meeting-4: >> >> https >> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> >> :// >> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> >> etherpad.openstack.org >> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> >> /p/puppet-openstack-weekly-meeting-2015111 >> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110> >> 7 >> >> I'm back online tomorrow morning. >> >> Thanks, >> --- >> Emilien Macchi >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > ~ > > > *Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science > at UFCG* > *E-mail: iurygreg...@gmail.com * > ~ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #59
We did our meeting: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-17-15.00.html Thanks! Emilien On 11/16/2015 11:39 PM, Emilien Macchi wrote: > The second one. Sorry for confusion, I sent it from my phone. > > See you tomorrow! > --- > Emilien Macchi > > On Nov 16, 2015 1:24 PM, "Iury Gregory" <mailto:iurygreg...@gmail.com>> wrote: > > Hi Emilien, the link for the agenda > is > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-2015111 or > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117 > > <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117> ? > Thanks o/ > > > 2015-11-16 14:04 GMT-03:00 Emilien Macchi <mailto:emilien.mac...@gmail.com>>: > > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https > > <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>:// > > <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>etherpad.openstack.org > > <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>/p/puppet-openstack-weekly-meeting-2015111 > > <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>7 > > I'm back online tomorrow morning. > > Thanks, > --- > Emilien Macchi > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > ~ > /Att[]'s > Iury Gregory Melo Ferreira > //Master student in Computer Science at UFCG/ > /E-mail: iurygreg...@gmail.com <mailto:iurygreg...@gmail.com>/ > ~ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #58 and next week
Just for the record, here are the meeting notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-10-15.00.html Thanks! On 11/08/2015 10:08 PM, Matt Fischer wrote: > 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 > mailto:emilien.mac...@gmail.com>> wrote: > > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110 > > I'm off all next week (holidays without IRC, and rare access to > e-mails...), so mfish will be chair. > > During the week, if you have any problem with Puppet CI, you can ping > degorenko on IRC. > When I come back, I'll work on 7.0.0 release to create our > stable/liberty branch. > > Thanks and see you soon, > Emilien > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] review the core-reviewer members
So here is a status: * François Charlier told me he's not working anymore on Puppet OpenStack, and wants to be dropped from core-reviewer list. I would like to personally thank him, he was the guy who showed me what is Puppet and how to write Puppet code. Thanks a lot for your work in our community, you're welcome anytime if you want to contribute again. * Dan Bode and Michael Chapman are AFIK not contributing to Puppet OpenStack for a while, regarding stats. I think it makes sense to drop them too. Dan created Puppet OpenStack modules some time ago and thanks to his work, we created a community in OpenStack, and reached a maturity. Thank you for all our work in the modules, specially moving them to Stackforge back in 2013, it was a great move for everyone. Michael was working on the Puppet modules for long time too and was huge contributor until some months ago. AFIK he's not working anymore on it. Again, we will always welcome you back if you decide to contribute again. During the Summit, we decided to update the core-reviewer list to give a chance for new people, but also dropping some people that do not work on the project anymore. I'll proceed to this action today: drop François, Dan and Michael from the core-reviewer list [1]. Thanks again for all your contributions, I sincerely hope we will have the chance to work together again later. [1] https://review.openstack.org/#/admin/groups/134,members On 10/31/2015 03:40 PM, Emilien Macchi wrote: > Hi, > > At the summit we discussed about updating the core-reviewer members [1]. > To continue the OpenStack meritocracy model, I believe we should keep > the list consistent with how our group is currently working and who is > really active [2]. > Puppet OpenStack group would not be here without these people and we > really appreciate the work done by our community. > If you're not involved anymore in Puppet OpenStack project (following > meetings, mailing-list, doing reviews and sending patches), we would > appreciate your insight about updating this list. > > [1] https://review.openstack.org/#/admin/groups/134,members > [2] http://stackalytics.com/report/contribution/puppetopenstack-group/180 > > Thanks, > -- > Emilien Macchi > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #60
Hello! Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151124 Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] mime-types-data requires Ruby version >= 2.0
Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are broken. The only one option I see is to pin mime-types in beaker dependencies, because beaker needs frog and frog needs mime-types. Note beaker is currently broken for ubuntu trusty nodes, because of this change. [1] https://github.com/mime-types/mime-types-data/releases/tag/v3.2015.1120 [2] https://github.com/mime-types/mime-types-data/blob/master/Rakefile#L16 [3] fog requires mime-types (>= 0) -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] mime-types-data requires Ruby version >= 2.0
On 11/23/2015 12:45 PM, Iury Gregory wrote: > Move to ruby 2.0 is going to give us more problems? If yes, pin > mime-types =) Ruby 2.0 is not supported & shipped by Ubuntu Trusty (Current LTS). So we have to support Ruby 1.x until Ubuntu 16.01 (next LTS), which should be end of mitaka cycle. > > 2015-11-23 5:20 GMT-03:00 Emilien Macchi <mailto:emil...@redhat.com>>: > > Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are > broken. > > The only one option I see is to pin mime-types in beaker dependencies, > because beaker needs frog and frog needs mime-types. > > Note beaker is currently broken for ubuntu trusty nodes, because of this > change. > > [1] > https://github.com/mime-types/mime-types-data/releases/tag/v3.2015.1120 > [2] > https://github.com/mime-types/mime-types-data/blob/master/Rakefile#L16 > [3] fog requires mime-types (>= 0) > -- > Emilien Macchi > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > ~ > /Att[]'s > Iury Gregory Melo Ferreira > //Master student in Computer Science at UFCG/ > /E-mail: iurygreg...@gmail.com <mailto:iurygreg...@gmail.com>/ > ~ > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Puppet OpenStack Mid-Cycle (Mitaka)
Hello, If you're involved in Puppet OpenStack or if you want to be involved, please look at this poll: http://goo.gl/forms/lsBf55Ru8L Thanks a lot for your time, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #60
On 11/23/2015 08:16 AM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151124 > > Thanks, > We did our meeting: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-24-15.00.html See you next week! Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New [puppet] module for Magnum project
On 11/25/2015 05:08 PM, Ricardo Rocha wrote: > Hi. > > We've started implementing a similar module here, i just pushed it to: > https://github.com/cernops/puppet-magnum > > It already does a working magnum-api/conductor, and we'll add > configuration for additional conf options this week - to allow > alternate heat templates for the bays. > > I've done some work before on puppet-ceph before and i'm happy to > start pushing patches to openstack/puppet-magnum. Is there already > something going on? I couldn't find any in: > https://review.openstack.org/#/q/status:open+project:openstack/puppet-magnum,n,z Like we said on IRC, yes we have a community module, and you're highly welcome to contribute to it. Thanks! > Cheers, > Ricardo > > On Thu, Oct 29, 2015 at 4:58 PM, Potter, Nathaniel > wrote: >> Hi Adrian, >> >> >> >> Basically it would fall under the same umbrella as all of the other >> puppet-openstack projects, which use puppet automation to configure as well >> as manage various OpenStack projects. An example of a mature one is here for >> the Cinder project: https://github.com/openstack/puppet-cinder. Right now >> there are about 35-40 such puppet modules for different projects in >> OpenStack, so one example of people who might make use of this project are >> people who have already used the existing puppet modules to set up their >> cloud and wish to incorporate Magnum into their cloud using the same tool. >> >> >> >> Thanks, >> >> Nate >> >> >> >> From: Adrian Otto [mailto:adrian.o...@rackspace.com] >> Sent: Thursday, October 29, 2015 10:10 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] New [puppet] module for Magnum project >> >> >> >> Nate, >> >> >> >> On Oct 29, 2015, at 11:26 PM, Potter, Nathaniel >> wrote: >> >> >> >> Hi everyone, >> >> >> >> I’m interested in starting up a puppet module that will handle the Magnum >> containers project. Would this be something the community might want? >> Thanks! >> >> >> >> Best, >> >> Nate Potter >> >> >> >> Can you elaborate a bit more about your concept? Who would use this? What >> function would it provide? My guess is that you are suggesting a puppet >> config for adding the Magnum service to an OpenStack cloud. Is that what you >> meant? If so, could you share a reference to an existing one that we could >> see as an example of what you had in mind? >> >> >> >> Thanks, >> >> >> >> Adrian >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] [release] Puppet OpenStack 7.0.0 Liberty (_independent)
Puppet OpenStack community is very proud to announce the release of 22 modules: puppet-aodh 7.0.0 puppet-ceilometer 7.0.0 puppet-cinder 7.0.0 puppet-designate 7.0.0 puppet-glance 7.0.0 puppet-gnocchi 7.0.0 puppet-heat 7.0.0 puppet-horizon 7.0.0 puppet-ironic 7.0.0 puppet-keystone 7.0.0 puppet-manila 7.0.0 puppet-murano 7.0.0 puppet-neutron 7.0.0 puppet-nova 7.0.0 puppet-openstacklib 7.0.0 puppet-openstack_extras 7.0.0 puppet-sahara 7.0.0 puppet-swift 7.0.0 puppet-tempest 7.0.0 puppet-trove 7.0.0 puppet-tuskar 7.0.0 puppet-vswitch 3.0.0 For more details about the release, you can visit: https://wiki.openstack.org/wiki/Puppet/releases https://forge.puppetlabs.com/openstack Here are some interesting numbers [1]: Contributors during Kilo cycle: 91 Contributors during Liberty cycle: 108 Commits during Kilo cycle: 730 Commits during Liberty cycle: 1201 LOC during Kilo cycle: 67104 LOC during Liberty cycle: 93448 [1] Sources: http://stackalytics.openstack.org Thank you to the Puppet OpenStack community to make it happen, Also big kudos to other teams, specially OpenStack Infra, Tempest and Packaging folks who never hesitate to help us. -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #61
Hello! Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151201 Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] drop eventlet support in puppet-keystone
Hello, Keystone team plans [1] to drop evenlet support and already started the work [2]. To make sure we follow the upstream project, I would like to initiate the work in our Puppet module; so we can take time to discuss the way we manage this change in puppet-keystone now, and in other modules that will (eventually later) decide to follow this path. Please review https://review.openstack.org/#/c/250546/ and use Gerrit to give feedback. [1] https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka [2] https://review.openstack.org/#/c/249486/ -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #61
On 11/29/2015 03:35 PM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151201 We did our (short) meeting, you can read notes here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-12-01-15.00.html See you next week! -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar
Hi, I don't find any official statement on the Internet, but I've heard Tuskar is not going to be maintained anymore (tell me if I'm wrong). If I'm not wrong, I suggest we stop maintaining puppet-tuskar, and stable/liberty would be the latest release that we have maintained. I would also drop all the code in master and update the README explaining the module is not maintained anymore. Thanks for your help, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar
I would love TripleO support on this topic On 12/03/2015 11:07 AM, arkady_kanev...@dell.com wrote: > Emilien, > > So what is the statement we (OpenStack) wants to provide about UI for OOO? AFIK, Tuskar won't be continued to be the TripleO UI but I might have misunderstood something. > If we will not provide it people outside our community and compatitors > to OpenStack will fill the void. > > Thanks, > > Arkady > > -Original Message- > From: Emilien Macchi [mailto:emil...@redhat.com] > Sent: Wednesday, December 02, 2015 10:38 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar > > Hi, > > I don't find any official statement on the Internet, but I've heard > Tuskar is not going to be maintained anymore (tell me if I'm wrong). > > If I'm not wrong, I suggest we stop maintaining puppet-tuskar, and > stable/liberty would be the latest release that we have maintained. I > would also drop all the code in master and update the README explaining > the module is not maintained anymore. > > Thanks for your help, > -- > Emilien Macchi > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team
Hi, For some months, Puppet OpenStack group has been very lucky to have Sofer working with us. He became a huge contributor to puppet-keystone, he knows the module perfectly and wrote insane amount of code recently, to bring new features that our community requested (some stats: [1]). He's always here to help on IRC and present during our weekly meetings. Core contributors, please vote if you agree to add him part of puppet-keystone core team. Thanks, [1] http://stackalytics.openstack.org/?user_id=sofer-athlan-guyot&release=all&metric=loc -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] stable/liberty branches are open
On 12/03/2015 09:47 AM, Steven Hardy wrote: > All, > > After quite a long battle, the stable/liberty CI is now working, as of this > patch: > > https://review.openstack.org/#/c/247694/ > > We still need to verify that CI works properly on all other repos, because > we had to go ahead and land what was ahead of that patch in the queue to > reach a working baseline. Let me know if you see any issues. > > There are a couple of outstanding items: > > 1. puppet-tripleo doesn't yet have a stable branch - I'll cut that this > week when we've verified all is working e.g what sha to cut it from. Yes, as a Puppet OpenStack PTL, I do not manage them since we consider this repo part of TripleO tent. Is that ok for you? > > 2. Currently puppet modules are installed from o-p-m, e.g packages not > source, this means Depends-On: won't work for stable > backport. We'll have to fix this soon so we build tripleo-ci packages from > the puppet stable branches like we do for master. ++ > > But, other than those two caveats, stable/liberty branches are open - > please all feel free to propose/review. > > Thanks for your patience while we got this all working, and thanks to those > (particularly derekh) who helped me out. > > Steve > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] bugreporting in puppet-openstack-integration
Hey Michal, Thanks for the bug-report! Let's see inline: On 12/04/2015 10:26 AM, Ptacek, MichalX wrote: > Hello, > > > > I have one general question for bug-reporting in > puppet-openstack-integration project, > > Actually I am having some issues by running all-in-one.sh script, > > > > Issue1) default scenario003 is not executed, as variable SCENARIO is > not exported and visible in run_test.sh > > https://github.com/openstack/puppet-openstack-integration/blob/master/all-in-one.sh#L46 > Here is the fix: https://review.openstack.org/253620 Please review. > > Issue2) when bypassed (issue1) by used correct SCENARIO I reach another > problem, where puppet code failed on finding tempest in /tmp/tempest > > https://github.com/openstack/puppet-openstack-integration/blob/master/fixtures/scenario003.pp#L388 > > tempest code is available inside /tmp/openstack/tempest, cloned by > following code > > https://github.com/openstack/puppet-openstack-integration/blob/master/run_tests.sh#L39 Here is the fix: https://review.openstack.org/253626 Please review too. > > I think these issues has to be already reported somewhere but I was not > able to find that project in Launchpad, You're right, it's time to have a bug tracker for this repo! Here we go: https://launchpad.net/puppet-openstack-integration Thanks a lot for your feedback, very valuable! -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Config support for oslo.config.cfg.MultiStrOpt
On 12/02/2015 10:32 PM, Cody Herriges wrote: > Martin, > > I see no reason this shouldn't just be pushed into puppetlabs-inifile. > I can't actually find a real "spec" for INI file and even the Wiki > link[3] calls out that there is no actual spec. I suggest: 1/ we land https://review.openstack.org/#/c/234727/ 2/ in the meantime, we work on a puppetlabs-inifile patch 3/ once it's done, we switch puppet-openstacklib to use it. What do you think? Martin, are you willing to work on it? > On Fri, Nov 27, 2015 at 5:04 AM, Martin Mágr <mailto:mm...@redhat.com>> wrote: > > Greetings, > > I've submitted patch to puppet-openstacklib [1] which adds > provider for parsing INI files containing duplicated variables > (a.k.a MultiStrOpt [2]). Such parameters are used for example to set > service_providers/service_provider for Neutron LBaaSv2. There has > been a thought raised, that the patch should rather be submitted to > puppetlabs-inifile module instead. The reason I did not submitted > the patch to inifile module is that IMHO duplicate variables are not > in the INI file spec [3]. Thoughts? > > Regards, > Martin > > > [1] https://review.openstack.org/#/c/234727/ > [2] > > https://docs.openstack.org/developer/oslo.config/api/oslo.config.cfg.html#oslo.config.cfg.MultiStrOpt > [3] https://en.wikipedia.org/wiki/INI_file#Duplicate_names > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] puppet-redis broke redis < 3.0.0
Hey, By working on monitoring support in TripleO undercloud, I found a bug that I think is not detected on the overcloud: https://bugs.launchpad.net/tripleo/+bug/1523239 I'm working on it: https://github.com/arioch/puppet-redis/pull/77 RDO folks is about to update Redis to be 3.x.x but in the meantime, we might want to pin puppet-redis. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] puppet-redis broke redis < 3.0.0
Last update: puppet-redis is now fixed (PR is merged). RDO updated Redis to be 3.x.x -- it's in testing repo now, will be stable next week. On Sun, Dec 6, 2015 at 9:55 AM, Emilien Macchi wrote: > Hey, > > By working on monitoring support in TripleO undercloud, I found a bug that > I think is not detected on the overcloud: > https://bugs.launchpad.net/tripleo/+bug/1523239 > > I'm working on it: > https://github.com/arioch/puppet-redis/pull/77 > > RDO folks is about to update Redis to be 3.x.x but in the meantime, we > might want to pin puppet-redis. > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #62
Hello! Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151208 Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team
On 12/03/2015 03:05 PM, Emilien Macchi wrote: > Hi, > > For some months, Puppet OpenStack group has been very lucky to have > Sofer working with us. > He became a huge contributor to puppet-keystone, he knows the module > perfectly and wrote insane amount of code recently, to bring new > features that our community requested (some stats: [1]). > He's always here to help on IRC and present during our weekly meetings. > > Core contributors, please vote if you agree to add him part of > puppet-keystone core team. So far we got 2 positive reviews from core people, and no negative thought. Welcome Sofer and thanks again for your work! -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] [cinder] New blog posts on using Barbican for Cinder Volume encryption
On 12/08/2015 09:43 AM, Ade Lee wrote: > Hi all, > > Just announcing a new blog for Barbican, including .. > - Barbican in RDO > - Barbican and Dogtag/IPA > - Securing Barbican behind haproxy > - Barbican and Volume Encryption > > Hopefully, some of the info here will be helpful to folks trying to set > things up with Barbican. > > https://vakwetu.wordpress.com/ Very nice! We have a Puppet module which is in construction (it's not doing much at this time). Would you be willing to help? The benefits are: * we have a functional testing CI, with tempest and other OpenStack components -- we would be able to give you feedback on Barbican and find some issues that sometimes you don't catch with your gate. * you'll allow people to easily deploy it * if people can easily test it, you'll get more attention & adoption * integration with installers, like Fuel, RDO manager, etc. Let me know on IRC if you're interested, my nick is EmilienM on freenode. Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #62
On 12/07/2015 07:31 AM, Emilien Macchi wrote: > Hello! > > Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC > in #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151208 > > Thanks, > We did our meeting, you can read the notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-12-08-15.00.html Thanks! -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] proposing Cody Herriges part of Puppet OpenStack core
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 knowledge on Puppet and all dependencies in general. * very helpful to debug issues related to Puppet core or dependencies (beaker, etc). * regular attendance to our weekly meeting * pertinent reviews * very understanding of our coding style I would like to propose having him back part of our core team. As usual, we need to vote. Thanks, [1] http://stackalytics.openstack.org/?metric=commits&release=all&project_type=all&user_id=ody-cat -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] using reno for release note management
This morning the Puppet OpenStack had the weekly meeting [1] and we discussed about using reno [2] for release note management. We saw three possibilities: 1/ we use reno and enforce each contributions (bugfix, feature, etc) to also edit a release note YAML file 2/ we use reno and the release note YAML file can be updated later (by the contributor or someone else) 3/ we don't use reno and continue to manually write release notes The solution 3/ is definitely not in our scope and we are willing to use reno. Though we are looking for a way to switch using it. Some people in our group shared some feedback, and ideas. Feel free to comment inline: * Having a YAML file for one feature/bugfix/... sounds heavy. * We have 23 repositories (modules) - we will probably start using reno for one or two modules, and see how it works. * We will apply 2/ with the goal to go 1/ one day. We think directly doing 1/ will have the risk to frustrate our group since not anyone is familiar with releases. Giving -1 to a good patch just because it does not have a release note update is not something we want now. We need to educate people at using it, that's why I think we might go 2/. * Using reno will spread the release note management to our group, instead of one release manager taking care of that. Feel free to have more feedback or comment inline, we are really willing to suggestions. Thanks! [1] https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack#Previous_meetings (2] http://docs.openstack.org/developer/reno/ -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Monitoring support
Hi, I've been spending some time on deploying monitoring in TripleO with Sensu. I recently made good progress. If you are interested by this work, feel free to look an etherpad I started [1]. Feel free to comment, review, and give any feedback, Thank you, [1] https://etherpad.openstack.org/p/tripleo-monitoring-patches -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] proposing Cody Herriges part of Puppet OpenStack core
\o/ I think that's a big +1 from the team :-) Welcome back Cody and thanks for your work! On 12/09/2015 04:06 AM, Denis Egorenko wrote: > +1 > > 2015-12-09 0:25 GMT+03:00 Clayton O'Neill <mailto:clay...@oneill.net>>: > > +1 > > On Tue, Dec 8, 2015 at 4:15 PM, Matt Fischer <mailto:m...@mattfischer.com>> wrote: > > +1 > > On Tue, Dec 8, 2015 at 2:07 PM, Rich Megginson > mailto:rmegg...@redhat.com>> 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 knowledge on Puppet and all dependencies in general. >> * very helpful to debug issues related to Puppet core or >> dependencies >> (beaker, etc). >> * regular attendance to our weekly meeting >> * pertinent reviews >> * very understanding of our coding style >> >> I would like to propose having him back part of our core team. >> As usual, we need to vote. > > +1 > >> Thanks, >> >> [1] >> >> http://stackalytics.openstack.org/?metric=commits&release=all&project_type=all&user_id=ody-cat >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best Regards, > Egorenko Denis, > Deployment Engineer > Mirantis > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #81
Hi Puppeteers! We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting4. Here's a first agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160517 Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #81
On Mon, May 16, 2016 at 9:43 AM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting4. Sorry for the typo, it was #openstack-meeting-4. > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160517 > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! Here are the notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-05-17-15.00.html Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Proposing Ivan Berezovskiy for puppet-openstack-core
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: * Fantastic work on puppet-oslo! I really mean it... Thanks to you and others, we have now consistency for Oslo parameters in our modules. * Excellent quality of code in general and in reviews. * Full understanding of our process (code style, release notes, CI, doc, etc). * Very often, he helps with CI things (Fuel or Puppet OpenStack CI). * Constant presence on IRC meetings and in our channel where he never hesitate to give support. I would like to propose him part of our Puppet OpenStack core team, as usual please -1/+1. Thanks Ivan for your hard work, keep going! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #82
Hi Puppeteers! We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4. Here's a first agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160524 Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #82
On Mon, May 23, 2016 at 1:24 PM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting-4. > > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160524 > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! Our notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-05-24-15.00.html Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] proposal about puppet versions testing coverage
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, we run unit test jobs on puppet on 3.3, 3.4, 3.6, 3.8, 4.0 and latest (current is 4.5). We also have functional jobs (non-voting, in periodic pipeline), that run puppet 4.5. Those ones break very often because nobody (except me?) regularly checks puppet4 periodic jobs. So here's my proposal, feel fee to comment: * Reduce puppet versions testing to 3.6, 3.8, 4.5 and latest (keep the last one non-voting). It seems that 3.6 and 3.8 are widely used by our consumers (default in centos7 & ubuntu LTS), and 4.5 is the latest release in the 4.x series. * Move functional puppet4 jobs from experimental to check pipeline (non-voting). They'll bring very useful feedback. It will add 6 more jobs in the check queue, but since we will drop 2 unit tests jobs (in both check & gate pipelines), it will add 2 jobs at total (in term of time, unit tests jobs take 15 min and functional jobs take ~30 min) so the impact of node consumption is IMHO not relevant here. [1] https://docs.google.com/forms/d/1rJZxP52LyrFhFTy8w4J_5tnA7-A5g32YVhHSaCd7-F8/edit#responses Thanks for your feedback, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] 7.1.0 released (Liberty)
Hi, We're happy to announce the release of 7.1.0 (Liberty). All you need to know is documented here: http://releases.openstack.org/teams/puppet_openstack.html You'll also find tarballs and release notes. Feedback about this release: For the first time we used openstack/releases tools, and it's really cool. It makes release management much simpler for us and more consistent with other projects. We still have an issue with e-mails announcements but I'm working on it this week. Thanks Tony & Doug for your help on this one! Regards, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Why do we disable the firewall by default?
On Thu, May 26, 2016 at 4:16 PM, Ben Nemec wrote: > Pretty much what the subject says. I've recently gotten several > questions from the field about why their deployments had no firewall > enabled, and discovered that although we have support built-in to enable > the firewall, we turn it off by default. This seems like a bad default > to me, but I wanted to send something out in case there was a good > historical reason we chose to do this. > > I'm also wondering about the upgrade implications of changing defaults > in Heat templates. If we did this, would it cause the firewall to be > enabled on existing deployments when they upgraded to the new version? > That seems like a significant concern since it's quite possible users > are managing their own firewall rules (especially because we don't by > default), and they may have customizations that they won't want us > stepping on. > > I've pushed a review to flip the bit on this: > https://review.openstack.org/#/c/321833 but I've set it WIP until we > have answers to the topics above. > > -Ben When Yanis and I wrote the feature back in times, we wanted the feature experimental because it's very intrusive. Now our CI is a good shape and has good coverage, I think we can give a try to enable it. If you enable, just make sure tripleo::firewall::post::debug is set at False, otherwise traffic won't be dropped :-) I don't see any issue on the upgrade thing, we just to iptables commands. I like your idea and I'm in favor of enabling it by default, and iterate on errors that we might encounter in CI. Thanks! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Watcher module for Puppet
On Tue, May 10, 2016 at 10:25 AM, Daniel Pawlik wrote: > Hello, > I'm working on implementation of a new puppet module for Openstack Watcher > (https://launchpad.net/watcher). > I'm already creating this module and I would like to share it when it will > be done. > > Could someone tell me how can I proceed to join puppet team's workflow ? > > > By the way, Watcher team plans to be into big tent by neutron-1 milestone. > > Regards, > Daniel Pawlik Now the repository is in place [1], who is going to work on the module? We have some documentation here: http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html#in-practice /join #puppet-openstack if you need help, as usual. [1] https://github.com/openstack/puppet-watcher -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][infra][deployment] Adding multinode CI jobs for TripleO in nodepool
On Fri, May 27, 2016 at 2:03 PM, James Slagle wrote: > I've been working on various patches to TripleO to make it possible > for the baremetal provisioning part of the workflow to be optional. In > such a scenario, TripleO wouldn't use Nova or Ironic to boot any > baremetal nodes. Instead it would rely on the nodes to be already > installed with an OS and powered on. We then use Heat to drive the > deployment of OpenStack on those nodes...that part of the process is > largely unchanged. > > One of the things this would allow TripleO to do is make use of CI > jobs using nodes just from the regular cloud providers in nodepool > instead of having to use our own TripleO cloud > (tripleo-test-cloud-rh1) to run all our jobs. > > I'm at a point where I can start working on patches to try and set > this up, but I wanted to provide this context so folks were aware of > the background. > > We'd probably start with our simplest configuration of a job with at > least 3 nodes (undercloud/controller/compute), and using CentOS > images. It looks like right now all multinode jobs are 2 nodes only > and use Ubuntu. My hope is that I/we can make some progress in > different multinode configurations and collaborate on any setup > scripts or ansible playbooks in a generally useful way. I know there > was interest in different multinode setups from the various deployment > teams at the cross project session in Austin. > > If there are any pitfalls or if there are any concerns about TripleO > going in this direction, I thought we could discuss those here. Thanks > for any feedback. It is more a question than a concern: are we still going to test baremetal introspection with Ironic somewhere in OpenStack? I like the way it goes but I'm wondering if the things that we're not going to test anymore will still be tested somewhere else (maybe in Ironic / Nova CI jobs) or maybe it's already the case and then stop me here. > -- > -- James Slagle > -- -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][infra][deployment] Adding multinode CI jobs for TripleO in nodepool
On Fri, May 27, 2016 at 3:08 PM, James Slagle wrote: > On Fri, May 27, 2016 at 2:37 PM, Emilien Macchi wrote: >> On Fri, May 27, 2016 at 2:03 PM, James Slagle wrote: >>> I've been working on various patches to TripleO to make it possible >>> for the baremetal provisioning part of the workflow to be optional. In >>> such a scenario, TripleO wouldn't use Nova or Ironic to boot any >>> baremetal nodes. Instead it would rely on the nodes to be already >>> installed with an OS and powered on. We then use Heat to drive the >>> deployment of OpenStack on those nodes...that part of the process is >>> largely unchanged. >>> >>> One of the things this would allow TripleO to do is make use of CI >>> jobs using nodes just from the regular cloud providers in nodepool >>> instead of having to use our own TripleO cloud >>> (tripleo-test-cloud-rh1) to run all our jobs. >>> >>> I'm at a point where I can start working on patches to try and set >>> this up, but I wanted to provide this context so folks were aware of >>> the background. >>> >>> We'd probably start with our simplest configuration of a job with at >>> least 3 nodes (undercloud/controller/compute), and using CentOS >>> images. It looks like right now all multinode jobs are 2 nodes only >>> and use Ubuntu. My hope is that I/we can make some progress in >>> different multinode configurations and collaborate on any setup >>> scripts or ansible playbooks in a generally useful way. I know there >>> was interest in different multinode setups from the various deployment >>> teams at the cross project session in Austin. >>> >>> If there are any pitfalls or if there are any concerns about TripleO >>> going in this direction, I thought we could discuss those here. Thanks >>> for any feedback. >> >> It is more a question than a concern: >> are we still going to test baremetal introspection with Ironic >> somewhere in OpenStack? >> >> I like the way it goes but I'm wondering if the things that we're not >> going to test anymore will still be tested somewhere else (maybe in >> Ironic / Nova CI jobs) or maybe it's already the case and then stop me >> here. >> > > I should have clarified: we're not moving away from still having our > own cloud running the TripleO jobs we have today. Thanks for this clarification! > This is about adding new jobs to test a different way of deploying via > TripleO Since we'd be able to use nodepool nodes directly to do that, > I'm proposing to do it that way. > > If it pans out, I'd expect us to have a variety of jobs running with > different permutations so that we can have as much coverage as > possible. I like it, I see different use-cases where we don't need to test baremetal provisioning. One of them is openstack/puppet-* testing (except for puppet-nova and puppet-ironic maybe) where we just want to run puppet on a undercloud / overcloud and see if services are working. With the new jobs, I would propose to think at removing old jobs and use new multi-node jobs, it will help us to save time, resources and test what we actually need to test. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #83
Hi Puppeteers! We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4. Here's a first agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160531 Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] weekly meeting
Hi! We'll have our weekly meeting tomorrow at 2pm UTC on #openstack-meeting-alt. Here's a first agenda: https://wiki.openstack.org/wiki/Meetings/TripleO#Agenda_for_next_meeting Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] weekly meeting
On Mon, May 30, 2016 at 8:45 AM, Emilien Macchi wrote: > Hi! > > We'll have our weekly meeting tomorrow at 2pm UTC on > #openstack-meeting-alt. > > Here's a first agenda: > https://wiki.openstack.org/wiki/Meetings/TripleO#Agenda_for_next_meeting > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! We did our meeting, you can read notes: http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-05-31-14.00.html See you on #tripleo, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #83
On Mon, May 30, 2016 at 8:34 AM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting-4. > > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160531 > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! We did our meeting and here are the notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-05-31-15.00.html Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] 8.1.0 released (Mitaka)
Hi, We're happy to announce the release of 8.1.0 (Mitaka). All you need to know is documented here: http://releases.openstack.org/teams/puppet_openstack.html You'll also find tarballs and release notes. Thanks to our group for the hard work! Regards, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"
On Thu, Jun 2, 2016 at 6:31 AM, Tony Breeds wrote: > Hi all, > In early May we tagged/EOL'd several (13) projects. We'd like to do a > final round for a more complete set. We looked for projects meet one or more > of the following criteria: > - The project is openstack-dev/devstack, openstack-dev/grenade or > openstack/requirements > - The project has the 'check-requirements' job listed as a template in > project-config:zuul/layout.yaml > - The project is listed in governance:reference/projects.yaml and is tagged > with 'release:managed' or 'stable:follows-policy' (or both). > > The list of 171 projects that match above is at [1]. There are another 68 > projects at [2] that have kilo branches but do NOT match the criteria above. > > Please look over both lists by 2016-06-09 00:00 UTC and let me know if: > - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing > and > why. > - A project is in list 2 that would like to opt *IN* to tagging/EOLing I think that all openstack/puppet-* projects that have stable/kilo can be kilo-EOLed. Let me know if it's ok and I'll abandon all open reviews. Thanks, > Any projects that will be EOL'd will need all open reviews abandoned before it > can be processed. I'm very happy to do this. > > I'd like to hand over the list of ready to EOL repos to the infra team on > 2016-09-10 (UTC) > > Yours Tony. > [1] http://paste.openstack.org/show/507233/ > [2] http://paste.openstack.org/show/507232/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"
On Thu, Jun 2, 2016 at 7:32 PM, Tony Breeds wrote: > On Thu, Jun 02, 2016 at 07:10:23PM -0400, Emilien Macchi wrote: > >> I think that all openstack/puppet-* projects that have stable/kilo can >> be kilo-EOLed. >> Let me know if it's ok and I'll abandon all open reviews. > > Totally fine with me. > > I've added them. Feel free to abanond the reviews. Any you don't get to by > 2016-06-09 00:00 UTC I'll take care of. Done. https://review.openstack.org/#/q/branch:stable/kilo+project:%22%255Eopenstack/puppet-.*%2524%22+status:open,n,z Thanks, > Yours Tony. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #84
Hi Puppeteers! We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4. Here's a first agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160607 Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] weekly meeting #84
We did our meeting, you can read notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-06-07-15.00.html Thanks, On Mon, Jun 6, 2016 at 9:12 AM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting-4. > > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160607 > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! > Thanks, > -- > Emilien Macchi -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Request to create puppet-congress
On Tue, Jun 7, 2016 at 3:52 PM, Dan Radez wrote: > I'd like to get puppet-congress started. > > I've written some code based on the cookie cutter structure but I've not > gone through proper channels yet to get it into openstack-puppet. > > I'd like to get the project establish so that the code can be run > through the review process. > That's a good news! Thanks for collaborating. We need to move https://github.com/opnfv/puppet-congress to OpenStack: https://review.openstack.org/#/c/326720/ And add it to our governance: https://review.openstack.org/#/c/326721/ One thing about the module, we'll need to make it compliant and tested like we do for other modules. Please make sure we can at least deploy congress with Ubuntu or RDO packaging out of the box. I noticed some workarounds in the code. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Request to create puppet-tacker
Yeah, super good news! Please do the same as I did in https://review.openstack.org/326720 and https://review.openstack.org/326721 Add me as reviewer because I need to sign-off the 2 patches (I'm current PTL). Once it's done & merged, you'll be able to deprecate the old repository on your github with a nice README giving the link of the new module. I haven't looked at the code yet but we'll probably have to adjust some bits, add some testing (beaker [1], etc). Please make sure that we have some packaging available in RDO (I checked on Ubuntu and they don't provide it) so we can download it during our beaker tests. Also a last thing, in order to help us to make the module compliant & consistent, please read how we wrote the recent modules. For example you can look puppet-gnocchi or puppet-aodh that are clean modules. We recently had a lot of new modules: vitrage, watcher, tacker, congress, (I'm working now on octavia) - which means reviews might take more time than usual because our team will review the new modules carefuly to make sure the code is clean & consistent from beginning (and avoid the puppet-monasca story). Please be patient and help us by reading how we did other modules. Thanks a ton for your collaboration and we're looking forward for this new challenge, [1] https://github.com/puppetlabs/beaker On Wed, Jun 8, 2016 at 8:11 AM, Iury Gregory wrote: > Awesome! > > You just need to follow the same process that Emilien pointed for > puppet-congress. If you need any help please let us know. > > 1- Move https://github.com/radez/puppet-tacker to OpenStack > 2- Add it to our governance > 3- Follow > http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html > > > > 2016-06-08 8:56 GMT-03:00 Dan Radez : >> >> I also have puppet-tacker module that has existed before the project was >> part of big tent. >> >> It was based on cookie cutter originally but will probably need some >> adjustments to adhere to standards. >> >> I'd like to get the project establish so that the code can be run >> through the proper review process. >> >> exiting repo is here: https://github.com/radez/puppet-tacker >> >> Dan Radez >> freenode: radez >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > ~ > Att[]'s > Iury Gregory Melo Ferreira > Master student in Computer Science at UFCG > E-mail: iurygreg...@gmail.com > ~ > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] newton virtual midcycle?
Hi Puppeteers, We would like to poll our community and know who would be interested by a virtual midcycle during Newton. I created: https://etherpad.openstack.org/p/newton-puppet-midcycle-meetup Please add your name and propose topics that you're willing to work on. During the next meeting, we'll review the output and decide if whether or not we do a midcycle or not. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] vision on new modules
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, vitrage, ec2api, tacker, watcher, congress, magnum, mistral, zaqar, etc. [2] by the end of Newton, we'll have ~ 33 Puppet modules ! Announce your work As a reminder, we have defined a process when adding new modules: http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html This process is really helpful to scale our project and easily add modules. If you're about to start a new module, I suggest you to start this process and avoid to start it on your personal github, because you'll loose the valuable community review on your work. Iterate I've noticed some folks pushing 3000 LOC in Gerrit when adding the bits for new Puppet modules (after the first cookiecutter init). That's IMHO bad, because it makes reviews harder, slower and expose the risk of missing something during the review process. Please write modules bits by bits. Example: start with init.pp for common bits, then api.pp, etc. For each bit, add its unit tests & functional tests (beaker). It will allow us to write modules with good design, good tests and good code in general. Write tests A good Puppet module is one that we can use to successfully deploy an OpenStack service. For that, please add beaker tests when you're initiating a module. Not at the end of your work, but for every new class or feature. It helps to easily detect issues that we'll have when running Puppet catalog and quickly fix it. It also helps community to report feedback on packaging, Tempest or detect issues in our libraries. If you're not familiar with beaker, you'll see in existing modules that there is nothing complicated, we basically write a manifest that will deploy the service. If you're new in this process, please join our IRC channel on freenode #puppet-openstack and don't hesitate to poke us. Any feedback / comment is highly welcome, Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Proposed TripleO core changes
On Thu, Jun 9, 2016 at 10:03 AM, Steven Hardy wrote: > Hi all, > > I've been in discussion with Martin André and Tomas Sedovic, who are > involved with the creation of the new tripleo-validations repo[1] > > We've agreed that rather than create another gerrit group, they can be > added to tripleo-core and agree to restrict +A to this repo for the time > being (hopefully they'll both continue to review more widely, and obviously > Tomas is a former TripleO core anyway, so welcome back! :) > > If folks feel strongly we should create another group we can, but this > seems like a low-overhead approach, and well aligned with the scope of the > repo, let me know if you disagree. +1 on my side too. I think in this case it's a good choice. > Also, while reviewing the core group[2] I noticed the following members who > are no longer active and should probably be removed: > > - Radomir Dopieralski > - Martyn Taylor > - Clint Byrum > > I know Clint is still involved with DiB (which has a separate core group), > but he's indicated he's no longer going to be directly involved in other > tripleo development, and AFAIK neither Martyn or Radomir are actively > involved in TripleO reviews - thanks to them all for their contribution, > we'll gladly add you back in the future should you wish to return :) > > Please let me know if there are any concerns or objections, if there are > none I will make these changes next week. > > Thanks, > > Steve > > [1] https://github.com/openstack/tripleo-validations > [2] https://review.openstack.org/#/admin/groups/190,members > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] weekly meeting #85
Hi Puppeteers! We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4. Here's a first agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160614 Feel free to add more topics, and any outstanding bug and patch. See you tomorrow! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Re: weekly meeting #85
On Mon, Jun 13, 2016 at 8:57 AM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting-4. > > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160614 > > Feel free to add more topics, and any outstanding bug and patch. > > See you tomorrow! > Thanks, > -- > Emilien Macchi Notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-06-14-15.00.html Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
