[openstack-dev] [puppet][fuel] stepping down from puppet/fuel core groups

[Denis Egorenko]

Hello puppet'ers!

Now it's time to say "Goodbay" to you, i'm leaving Mirantis and as well
stepping down from Puppet/Fuel core groups.

It was a really cool to work with all of you! I've learn a lot! Thank you
all for all your help and advises.

Also want to especially say "Thank you" to Emilien Macchi, Alex Schultz,
Sergii Golovatiuk, Vladimir Kuklin and other core guys - you're best! :)

If you will need my help, please don't hesitate to add me to review or
reach me: egorenko@gmail.com

Thank you and good luck!

-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

Thank you Matt for all your work and help :) Good luck!

2017-04-05 4:20 GMT+04:00 Emilien Macchi :

> On Tue, Apr 4, 2017 at 5:23 PM, Matt Fischer  wrote:
> > I am stepping down as core in the puppet openstack project. This is the
> > culmination of a long and slow refocus of my work efforts into other
> areas.
> > Additionally I'm not sure what the future holds for me at this point, and
> > although it's possible that I will be doing puppet again but it's not
> fair
> > for me to hold this role when I'm not active.
> >
> > I am very proud of what we, the community, accomplished with these
> modules
> > since I started hacking on them in 2014. The modules went from needing
> lots
> > of work to being very stable and mostly bug free. It took a lot of work
> and
> > some tough decisions from the community to get us to this point and I was
> > honored to be a part of it.
> >
> > Thanks
>
> Thank *you* !
>
> I'll miss the time where you gave strong operator feedback and when we
> got issue / solution / patch merged the same day :-)
> Anyway, enjoy the next things and thanks for your work here.
>
> PS: I remain available on IRC anytime if you want to continue to
> practice your french ;-)
>
> > 
> __
> > 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[Denis Egorenko]

+1

2017-01-20 4:10 GMT+04:00 Emilien Macchi :

> On Thu, Jan 19, 2017 at 5:25 PM, Alex Schultz  wrote:
> > Hey Puppet Cores,
> >
> > I would like to nominate Mykyta Karpin as a Core reviewer for the
> > Puppet OpenStack modules.  He has been providing quality patches and
> > reviews for some time now and I believe he would be a good addition to
> > the team.  His stats for the last 90 days can be viewed here[0]
> >
> > Please response with your +1 or any objections. If there are no
> > objections by Jan 26, I will add him to the core list.
>
> +1, that's well deserved.
> Thanks Mykyta for your contributions! Keep rocking :-)
>
> > Thanks,
> > -Alex
> >
> > [0] http://stackalytics.com/report/contribution/puppet%
> 20openstack-group/90
> >
> > 
> __
> > 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

+1, good job

2016-09-15 17:44 GMT+03:00 Matt Fischer :

> +1 to all. Thanks for your work guys!
>
> On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi 
> wrote:
>
>> While our group keeps moving, it's time to propose again new people
>> part of core team.
>>
>> Dmitry Tantsur / puppet-ironic
>> Dmitry is the guardian of puppet-ironic. He's driving most of the
>> recent features in this module and he now fully deserves being core on
>> it.
>>
>> Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
>> Prad is our Telemetry guru and he never stops to bring attention on
>> these modules! Keep going Prad, we appreciate your help here.
>>
>> Iury Gregory / all modules
>> Iury is our padawan. Still learning, but learning fast, he has been a
>> continuous contributor over the last months. He's always here on IRC
>> and during meetings to help.
>> He always volunteer to help and not for the most fun tasks. (He drove
>> the authtoken work during Newton). I would like to reward his work and
>> show that we trust him to be a good core reviewer.
>> Iury, keep going in your efforts!
>>
>>
>> If your name is not here yet, please keep doing consistent work, help
>> in bug triage, maintain stable CI, doing good reviews, improve our
>> documentation, etc.
>>
>> As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

Hey Emilien,

It was a big pleasure to work with you!

Thank you for all your help! :) And good luck on your next project and
activities!

2016-09-09 19:05 GMT+03:00 Emilien Macchi :

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

[Denis Egorenko]

+1

2016-09-08 13:06 GMT+03:00 Aleksandr Didenko :

> +1
>
> On Thu, Sep 8, 2016 at 11:06 AM, Sergey Vasilenko  > wrote:
>
>> +1
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [fuel] Propose Denis Egorenko for fuel-library core

[Denis Egorenko]

Thank you all! I will do my best! :)

2016-08-29 15:21 GMT+03:00 Maksim Malchuk :

> Although today is not the 31 Aug and we have a lack of core-reviewers in
> the fuel-library I would like to speed up the process a little.
>
> And as there are no objections so, please welcome Denis as he's just
> joined fuel-library Core Team!
>
> On Mon, Aug 29, 2016 at 3:15 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Although I am not a core in fuel-library, I am voting +1.
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Aug 26, 2016 at 1:27 PM, Ivan Berezovskiy <
>> iberezovs...@mirantis.com> wrote:
>>
>>> +1, great job!
>>>
>>> 2016-08-26 10:33 GMT+03:00 Bogdan Dobrelya :
>>>
 +1

 On 25.08.2016 21:08, Stanislaw Bogatkin wrote:
 > +1
 >
 > On Thu, Aug 25, 2016 at 12:08 PM, Aleksandr Didenko
 > > wrote:
 >
 > +1
 >
 > On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko
 > > wrote:
 >
 > +1
 >
 >
 > /sv
 >
 >
 > ___
 ___
 > 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/opensta
 ck-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
 > 
 >
 >
 >
 >
 > --
 > with best regards,
 > Stan.
 >
 >
 > 
 __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >


 --
 Best regards,
 Bogdan Dobrelya,
 Irc #bogdando

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>>
>>> --
>>> Thanks, Ivan Berezovskiy
>>> MOS Puppet Team Lead
>>> at Mirantis 
>>>
>>> slack: iberezovskiy
>>> skype: bouhforever
>>> phone: + 7-960-343-42-46
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> 
>
> __
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

big +1 from me, thanks for work Sofer!

2016-07-28 19:42 GMT+03:00 Rich Megginson :

> +1 - good guy
>
>
> On 07/28/2016 09:58 AM, Ivan Berezovskiy wrote:
>
> +1, good job!
>
> 2016-07-28 18:50 GMT+03:00 Matt Fischer :
>
>> +1 from me!
>>
>> On Jul 28, 2016 9:20 AM, "Emilien Macchi"  wrote:
>>
>>> You might not know who Sofer is but he's actually "chem" on IRC.
>>> He's the guy who will find the root cause of insane bugs, in OpenStack
>>> in general but also in Puppet OpenStack modules.
>>> Sofer has been working on Puppet OpenStack modules for a while now,
>>> and is already core in puppet-keystone. Many times he brought his
>>> expertise to make our modules better.
>>> He's always here on IRC to help folks and has excellent understanding
>>> at how our project works.
>>>
>>> If you want stats:
>>> http://stackalytics.com/?user_id=sofer-athlan-guyot=commits
>>> I'm quite sure Sofer will make more reviews over the time but I have
>>> no doubt he fully deserves to be part of core reviewers now, with his
>>> technical experience and involvement.
>>>
>>> As usual, it's an open decision, please vote +1/-1 about this proposal.
>>>
>>> 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 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
>>
>>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis 
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

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


+1 from me too

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


it's a good start for using puppet4. For first time i agree, that should be
non-voting.
I think our puppet team can also start work fpr making our modules be
compatible
with puppet4. Thank you for bringing up this!

2016-05-25 22:40 GMT+03:00 Matt Fischer :

> On Wed, May 25, 2016 at 1:09 PM, Emilien Macchi 
> wrote:
>
>> Greating folks,
>>
>> In a recent poll [1], we asked to our community to tell which version
>> of Puppet they were running.
>> The motivation is to make sure our Puppet OpenStack CI test the right
>> things, that are really useful.
>>
>> Right now, 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.
>>
>
>
> +1
>
>
>
>> * 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.
>>
>
>
> What's the plan for making Puppet4 jobs voting? I think this is a good
> start but we should more towards voting jobs I think.
>
> __
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

+1 from my side :) well deserved.

2016-05-19 17:17 GMT+03:00 Emilien Macchi :

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



-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

Thank you Yanis for your work on puppets!

Good luck in your next projects!

2016-05-10 16:14 GMT+04:00 Emilien Macchi :

> On Tue, May 10, 2016 at 3:52 AM, Yanis Guenane 
> wrote:
> > Hello all,
> >
> > After the Mitaka summit, my main area of focus at work changed and I
> > couldn't find the necessary time to help anymore on the puppet modules.
> >
> > After a cycle I don't see my situation changing anytime soon, therefor
> > I'd like to step down as a core-reviewer.
> >
> > Reading about the Austin summit it seems like modules have reached a
> > nice level of maturity. This is an excellent news.
> >
> > Thanks to everybody for this adventure, it was an enriching one.
> > I wish you the best for the challenges that comes next,
>
> Thanks for your hard work, you contributed a lot to make our modules
> consistent & compliant each others, it helped a lot to reach this
> maturity and allowed us to scale the number of managed modules.
> Have fun in your next challenges!
> --
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet][horizon] - Add extra plugins config to puppet-horizon

[Denis Egorenko]

>
> Does Murano uses the same local_settings.py file as Horizon? If yes,
> we might stop using puppet-murano to manage this file.


Yes, it uses same file.

And maybe find a mechanism in puppet-horizon with a provider, so we
> can have a plugin architecture like:
> horizon::plugins::murano
> horizon::plugins::foobar
> that would use this provider to configure a common local_settings.py
> and notify service on change, like we do for .conf files.


That's idea for researching, sounds good. We can implement something like
*_config providers for conf files.

Also, another question. If we will move all UI stuff to puppet-horizon, do
we need
add some dependency for changed modules on horizon module?
Right now, modules with UI configuration don't have dependency on horizon.
May be we need to add it?

Depends on horizon version I think. Mitaka gained a local_settings.d magic
> dir that plugins can drop things into.


That's a really good. We can use a separate file for each plugin then and
pass it to provider.

2016-04-14 17:59 GMT+03:00 Fox, Kevin M :

> Depends on horizon version I think. Mitaka gained a local_settings.d magic
> dir that plugins can drop things into.
>
> Thanks,
> Kevin
>
> --
> *From:* Marcos Fermin Lobo
> *Sent:* Thursday, April 14, 2016 5:52:31 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [puppet][horizon] - Add extra plugins config
> to puppet-horizon
>
> Hi all,
>
> I have a question about puppet-horizon module and UI plugins for Horizon.
>
> Some of UI plugins, like murano-dashboard, needs to add extra parameters
> https://github.com/openstack/murano-dashboard/blob/master/muranodashboard/local/local_settings.py.example
> to local_settings file (which comes from Horizon).
>
> My question is: Should puppet-horizon module provide those extra
> parameters coming from each official UI plugins? or this kind of things
> should come from specific a puppet-{ui-plugin}?
>
> Thanks.
>
> Cheers,
> Marcos
>
> __
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet][horizon] - Add extra plugins config to puppet-horizon

[Denis Egorenko]

>
> Some of UI plugins, like murano-dashboard, needs to add extra parameters
> https://github.com/openstack/murano-dashboard/blob/master/muranodashboard/local/local_settings.py.example
> to local_settings file (which comes from Horizon).
> My question is: Should puppet-horizon module provide those extra
> parameters coming from each official UI plugins? or this kind of things
> should come from specific a puppet-{ui-plugin}?


Well, not exactly puppet-{ui-plugin}. For example, we already have murano
module and it has manifests for UI plugin installation.

On a one side, in such way we are keeping all module related configuration
in one place.
On another side, all UI configuration probably should be placed in horizon
module. But in this case, we need to support in horizon module full
configuration for each UI plugin.

So, i think we can keep UI configuration in-place (in separate module) if
we have this module at all. For cases, when we need only support some UI
settings/plugins - we can keep it in puppet-horizon.

Thoughts?

2016-04-14 16:00 GMT+03:00 Emilien Macchi :

> On Thu, Apr 14, 2016 at 8:52 AM, Marcos Fermin Lobo
>  wrote:
> > Hi all,
> >
> > I have a question about puppet-horizon module and UI plugins for Horizon.
> >
> > Some of UI plugins, like murano-dashboard, needs to add extra parameters
> >
> https://github.com/openstack/murano-dashboard/blob/master/muranodashboard/local/local_settings.py.example
> > to local_settings file (which comes from Horizon).
> >
> > My question is: Should puppet-horizon module provide those extra
> parameters
> > coming from each official UI plugins? or this kind of things should come
> > from specific a puppet-{ui-plugin}?
> >
> I don't think having a separated Puppet module for each plugin will
> help us, maintaining a module is a lot of work.
> One thing we could do is to have classes:
> horizon::plugin::murano
> horizon::plugin::foobar etc
>
> What do you think?
> --
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet] weekly meeting #77

[Denis Egorenko]

We did our meeting, and you can read the notes:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-04-05-15.00.html

Thanks!

2016-04-04 15:29 GMT+03:00 Emilien Macchi :

> Hi,
>
> We'll have our weekly meeting tomorrow at 3pm UTC on
> #openstack-meeting4.
>
> https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack
>
> As usual, free free to bring topics in this etherpad:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160405
>
> We'll also have open discussion for bugs & reviews, so anyone is welcome
> to join.
>
> Note: I'll be away this day, Denis will chair the meeting.
>
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet][ec2api] - Official EC2 puppet module repo

[Denis Egorenko]

Hi Marcos,

Are you still working on your initial commit to puppet-ec2api [1] ?

[1] https://review.openstack.org/#/c/276103/

2016-01-29 22:02 GMT+03:00 Emilien Macchi :

>
>
> On 01/29/2016 10:35 AM, Marcos Fermin Lobo wrote:
> > Hi,
> >
> > Since I finished to "apply" for puppet-ec2api module as official puppet
> > module in OpenStack (see https://review.openstack.org/#/c/252959/ and
> > https://review.openstack.org/#/c/251857/), I saw that the puppet module
> > repository is created https://github.com/openstack/puppet-ec2api
> >
> > But the repository is still empty.
>
> Yeah, you have two options:
>
> #1 Import your code
>
> If you do that, please iterate your patches so you'll have reviews more
> quickly. You can look how puppet-mistral was created [1], I like the
> iterative approach (step by step).
>
> #2 Generate a new module with this procedure [2]
>
> Run the procedure, and follow-up with new patches to add the classes
> that you had in our module.
>
> [1] https://review.openstack.org/#/q/project:openstack/puppet-mistral
> [2]
> https://wiki.openstack.org/wiki/Puppet/New_module#On_the_technical_side
>
> > (...)
>
> Both approaches work for us, but please iterate with small chunks, which
> is easier to test and review.
>
>
> Thanks a lot for your efforts, 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

[Denis Egorenko]

>
> The domain, at this stage won't be a problem to be concerned with, we
> will have its value.  The only thing to add, I think, would be some kind
> of caching for keystone_user_role call to avoid repetition.  This
> shouldn't be hard to implement though.


Well yes, we can create method in parent keystone.rb module and global
variable,
for keeping (caching) current roles. Like it done currently for domains:

https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone.rb#L106-L130

Are our solutions same?

I've added this as a meeting point for tomorrow, so that we can take a
> final decision on this and start coding:
>  -
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322


Yep, that have to be discussed.

2016-03-21 18:09 GMT+03:00 Sofer Athlan-Guyot <sathl...@redhat.com>:

> Denis Egorenko <degore...@mirantis.com> writes:
>
> > Hi Athlan,
> >
> > thanks for attention of this problem. We have one more related change
> > [1] and bug [2]
> > for this problem, when we option 'domain_specific_drivers' is used.
> >
> > I would like to vote for 3) case.
> >
> > As I see it there are three ways to approach this:
> > - iterate over all domains and keep the same behavior as now;
> > - detect somehow that the domain-specific configuration is used
> > and
> > hack, both instances methods to add domain options
> > - remove prefetch from keystone_user and keystone_user_role (kinda
> > get
> > my preference, see below)
>
> We agree then :)
>
> > Let me explain why.
> > Using of prefetch and instances methods have a couple of problem, like
> > we can't pass some values to them and can't to set proper options
> > (dynamical of course).
> > Backing to this problem, it means, that we can't specify some domain
> > and hence we can
> > iterate over all domains or check users only for default domain. Both
> > ways are not acceptable to me.
> >
> > As solution for this problem, i see using calling kinda of instances
> > method from exist? method.
> > On this stage we can use all parameters, which are passed to
> > keystone_user{_role}
> > providers and we can choose proper domain if specified. If not -
> > default domain will be used.
>
> The domain, at this stage won't be a problem to be concerned with, we
> will have its value.  The only thing to add, I think, would be some kind
> of caching for keystone_user_role call to avoid repetition.  This
> shouldn't be hard to implement though.
>
> I've added this as a meeting point for tomorrow, so that we can take a
> final decision on this and start coding:
>  -
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322
>
> >
> > [1] https://review.openstack.org/213906
> > [2] https://bugs.launchpad.net/puppet-keystone/+bug/1485508
> >
> > 2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot <sathl...@redhat.com>:
> >
> > Hi,
> >
> > we have a big problem when using domain-specific configuration.
> > The
> > listing of all users is not supported by keystone when it's used
> > [1][2].
> >
> > What this means is that prefetch method in keystone_user won't
> > work, or
> > more specifically, instances method will fail.
> >
> > This poses a problem for the keystone_user_role, as the user
> > instances
> > method is called there too.
> >
> > The missing bit when domain-specific configuration is used is that
> > the
> > operator must precise the domain on the command line option.
> >
> > As I see it there are three ways to approach this:
> >
> > - iterate over all domains and keep the same behavior as now;
> > - detect somehow that the domain-specific configuration is used
> > and
> > hack, both instances methods to add domain options
> > - remove prefetch from keystone_user and keystone_user_role (kinda
> > get
> > my preference, see below)
> >
> > The problem I see with the first two methods depends on the usual
> > use
> > case of the domain specific configuration.
> >
> > For what I understand, this would be mainly used to connect to
> > existing
> > LDAP server, certainly large AD. If that's the case then we will
> > have
> > the same problem that the keystone people have seen, ie very big
> > list of
> > poeple, most of them unrelated to what is happening. We will then
> > have
> > the risk that

Re: [openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

[Denis Egorenko]

Hi Athlan,

thanks for attention of this problem. We have one more related change [1]
and bug [2]
for this problem, when we option 'domain_specific_drivers' is used.

I would like to vote for 3) case.

As I see it there are three ways to approach this:
>  - iterate over all domains and keep the same behavior as now;
>  - detect somehow that the domain-specific configuration is used and
>hack, both instances methods to add domain options
>  - remove prefetch from keystone_user and keystone_user_role (kinda get
>my preference, see below)


Let me explain why.
Using of prefetch and instances methods have a couple of problem, like
we can't pass some values to them and can't to set proper options
(dynamical of course).
Backing to this problem, it means, that we can't specify some domain and
hence we can
iterate over all domains or check users only for default domain. Both ways
are not acceptable to me.

As solution for this problem, i see using calling kinda of instances method
from exist? method.
On this stage we can use all parameters, which are passed to
keystone_user{_role}
providers and we can choose proper domain if specified. If not - default
domain will be used.

[1] https://review.openstack.org/213906
[2] https://bugs.launchpad.net/puppet-keystone/+bug/1485508

2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot :

> Hi,
>
> we have a big problem when using domain-specific configuration.  The
> listing of all users is not supported by keystone when it's used[1][2].
>
> What this means is that prefetch method in keystone_user won't work, or
> more specifically, instances method will fail.
>
> This poses a problem for the keystone_user_role, as the user instances
> method is called there too.
>
> The missing bit when domain-specific configuration is used is that the
> operator must precise the domain on the command line option.
>
> As I see it there are three ways to approach this:
>
>  - iterate over all domains and keep the same behavior as now;
>  - detect somehow that the domain-specific configuration is used and
>hack, both instances methods to add domain options
>  - remove prefetch from keystone_user and keystone_user_role (kinda get
>my preference, see below)
>
> The problem I see with the first two methods depends on the usual use
> case of the domain specific configuration.
>
> For what I understand, this would be mainly used to connect to existing
> LDAP server, certainly large AD.  If that's the case then we will have
> the same problem that the keystone people have seen, ie very big list of
> poeple, most of them unrelated to what is happening.  We will then have
> the risk that:
>  - keystone fails;
>  - the puppet process would be slowed down significantly;
>
> So listing all users in this case seems like a very bad idea.  As I
> don't see a way to disable prefetching dynamically, when domain-specific
> is used (maybe have to be digged into ?), then I tend to favor the
> removal of this from kesytone_user and keystone_user_role.
> Keystone_user_role is the main problem here as it require a lot of call
> to be build and prefetching help here.
>
> So I don't see a best solution to this problem, so I'd like to have more
> inputs about the right course of action.
>
> Note: It was first noticed by Matthew J Black, which has open this bug
> report[3] and started to work on a fix here[4]
>
> [1]
> https://github.com/openstack/keystone/blob/master/doc/source/configuration.rst
> (look for domain-specific)
> [2] https://bugs.launchpad.net/keystone/+bug/1555629
> [3] https://bugs.launchpad.net/puppet-keystone/+bug/1554555
> [4] https://review.openstack.org/#/c/289995/
> --
> Sofer Athlan-Guyot
>
> __
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

+1

2016-03-04 18:40 GMT+03:00 Emilien Macchi :

> Hi,
>
> To scale-up our review process, we created pupept-keystone-core and it
> worked pretty well until now.
>
> I propose that we continue this model and create puppet-neutron-core.
>
> I also propose to add Sergey Kolekonov in this group.
> He's done a great job helping us to bring puppet-neutron rock-solid for
> deploying OpenStack networking.
>
> http://stackalytics.com/?module=puppet-neutron=marks
> http://stackalytics.com/?module=puppet-neutron=commits
> 14 commits and 47 reviews, present on IRC during meetings & bug triage,
> he's always helpful. He has a very good understanding of Neutron &
> Puppet so I'm quite sure he would be a great addition.
>
> As usual, please vote!
> --
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [Fuel][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Denis Egorenko]

Hey Igor,

We are planing to release Murano plugin with Fuel 9.0. So, after plugin
will be ready,
we just disable Murano built in installation. We don't expect to have any
conflicts, because
we will use overridden hiera data for plugin and all old serialized Murano
information will be
useless.


2016-02-25 13:38 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>:

> Hey Denis,
>
> I didn't read the spec yet, but want to raise one important question.
> AFAIU, you plan to release Murano plugin between Fuel 9.0 and Fuel 10,
> so the question is do you plan to support installation of Murano
> plugin on Fuel 9.0? If so, that might be a problem.
>
> Thanks,
> - Igor
>
> On Wed, Feb 24, 2016 at 6:30 PM, Denis Egorenko <degore...@mirantis.com>
> wrote:
> > Hello folks,
> >
> > i would like to notify you, that we are going to remove Murano as built
> in
> > Fuel and move this functionality to fuel-plugin.
> >
> > Transition from Fuel built in to Fuel plugin deployment will follow next
> > way:
> >
> > * Murano deployment in Fuel 9.0 will be deprecated: we leave an ability
> to
> > deploy it,
> >   keeping puppet manifests for Murano in fuel-library, keeping UI
> settings
> >   untill plugin will be prepared and tested;
> >
> > * Once plugin is ready, Fuel 9.0 deployment from built in Murano will
> >   forbidden. All Murano codebase will be removed from Fuel in next
> release.
> >
> > Since Murano will be a plugin, it will have his own development cycle,
> > differ from Fuel releases.
> >
> > There is specification for this activity [1]. Any feedback is welcome.
> >
> > [1] https://review.openstack.org/275124
> >
> > --
> > Best Regards,
> > Egorenko Denis,
> > Senior 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
> >
>
> __
> 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
>



-- 
Best Regards,
Egorenko Denis,
Senior 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

[openstack-dev] [Fuel][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Denis Egorenko]

Hello folks,

i would like to notify you, that we are going to remove Murano as built
in Fuel and move this functionality to fuel-plugin.

Transition from Fuel built in to Fuel plugin deployment will follow next
way:

* Murano deployment in Fuel 9.0 will be deprecated: we leave an ability to
deploy it,
  keeping puppet manifests for Murano in fuel-library, keeping UI settings
  untill plugin will be prepared and tested;

* Once plugin is ready, Fuel 9.0 deployment from built in Murano will
  forbidden. All Murano codebase will be removed from Fuel in next release.

Since Murano will be a plugin, it will have his own development cycle,
differ from Fuel releases.

There is specification for this activity [1]. Any feedback is welcome.

[1] https://review.openstack.org/275124

-- 
Best Regards,
Egorenko Denis,
Senior 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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Denis Egorenko]

I'm not a fuel core member, but i also would like to vote +1 for Matthew.
He's doing great job!

2016-02-24 16:02 GMT+03:00 Aleksandr Didenko :

> +1
>
> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
> wrote:
>
>> Fellow Fuelers
>>
>> I would like to kindly ask you to consider voting for Matthew Mosesohn as
>> a Fuel Library Core
>> reviewer.
>>
>> Matthew has been working with Fuel since its inception, worked on
>> countless amount of features, such as :
>>
>> Master Node Upgrades and Backup
>> Improvements to Fuel Infra
>> Mitaka, Kilo and Juno Support
>> Detachable Services Plugins
>> RHOS Support in Fuel
>> UCA Support
>> Refactoring of Haproxy and Firewall pieces
>>
>> He has also been known as our Fuel Master node and Docker guru and has
>> been continuously working on bugfixing where he scores as a bug squashing
>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
>> throughout FL history).
>>
>> As you can see, there is not a piece of Fuel Library that he has not yet
>> gained experience with.
>>
>> And this can easily be fetched with simple statistics of Matt's
>> contribution. He is the topmost contributor to all Fuel projects among all
>> Fuel Library folks and is the 3rd contributor of Fuel Library.
>> He also reviews a lot and has a fair amount of -1's (he is not as cruel
>> as me, though :-))
>>
>> Having that said, I would like to open the vote to promote Matt to
>> OpenStack Fuel Library core reviewers.
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.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
>
>


-- 
Best Regards,
Egorenko Denis,
Senior 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

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

[Denis Egorenko]

Hi,

Alex is doing great job! +1 from my side!

2016-01-06 16:27 GMT+03:00 Sebastien Badia :

> On Tue, Jan 05, 2016 at 12:55:01PM (-0500), Emilien Macchi wrote:
> > Hi,
> >
> > Alex Schultz (mwhahaha on IRC) has been a very active contributor over
> > the last months in the Puppet OpenStack group:
> > * He's doing a lot of reviews and they are very valuable. He's in my
> > opinion fully aware of our conventions and has nice insights to improve
> > our modules.
> > * He's very helpful to work on bugs or new features when needed.
> > * Always present during meetings and actively participating.
> > * Always on IRC, he never hesitates to give a hand on something or help
> > people.
> >
> > I think we're very lucky to have Alex part of our group and I would like
> > to promote him core reviewer of all our modules.
> >
> > Team, please vote if you like the idea,
>
> Hi,
> A big +1 for me!
>
> Seb
>
> --
> Sebastien Badia
>
> __
> 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
>
>


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

Re: [openstack-dev] [puppet] [neutron] Serious bug in puppet neutron cli json output parsing.

[Denis Egorenko]

>
> Last I checked, which was quite a while ago, openstackclient didn't
> support everything we were using from the neutron client.


That's true. Openstack client doesn't support all features of neutron
client [1].

I would prefer use 3) option, but, unfortunately, i also don't see way, how
to detect stevedore and cliff.

[1]
https://github.com/openstack/python-openstackclient/blob/master/setup.cfg#L329-L339

2015-12-30 19:53 GMT+03:00 Colleen Murphy :

>
>
> On Wed, Dec 30, 2015 at 8:37 AM, Sofer Athlan-Guyot 
> wrote:
>
>> Hi,
>>
>> I have added neutron people as they may help to find a solution.
>>
>> After banging my head against the wall for a whole afternoon I
>> discovered a serious bug in puppet neutron module.
>>
>> I not going to repeat here the detail of the bug report[1].  Basically:
>>  - neutron_port
>>  - neutron_subnet
>>  - neutron_router
>>  - neutron_network
>>
>> may break idempotency randomly and won't work at all when clifftablib is
>> removed from the package dependency of python-openstackclient
>> (Mitaka[2])
>>
>> So the problem is that neutron cli json output on liberty (at least, and
>> maybe before) is not consistent and may come from cliff or clifftablib.
>> I didn't test it but the same may apply to openstack cli. As we don't
>> use the openstack cli json output it's not a issue (for puppet modules)
>>
>> The available solution I can see are:
>>  1. go back to parsing csv, shell output (revert [3])
>>  2. find a way to leverage openstacklib parsing for neutron as well
>>  3. keep json and parse the right output (cliff) and find a way to make
>> sure that it is always used by stevedore
>>  4. ?
>>
>> Last I checked, which was quite a while ago, openstackclient didn't
> support everything we were using from the neutron client. I would like to
> reevaluate that and go with option 2 if we can. Otherwise option 1 seems
> reasonable.
>
>
>> From my point of view 3) is not a option, but other may disagree.
>>
>> The problem is tricky and the fact that the CI cannot detect this is
>> trickier[4].
>>
>> So before Mitaka, the json parsing should go.  I would love to see an
>> interface that all puppet modules would use (solution 2).  The current
>> openstacklib parses openstack client well enough.  The neutron command
>> is not that different and I think there is space for code reuse.  This
>> would be a long term solution.  It would bring the advantage of having
>> only one interface to change if it was decided to use the API directly
>> for instance[5]
>>
>> In the meantime, a quick solution to this bug must be found.
>>
>> Looking forward to your comments.
>>
>> Regards,
>>
>> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
>> [2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
>> [3] https://review.openstack.org/#/c/238156/
>> [4] https://review.openstack.org/#/c/262223/
>> [5]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
>> --
>> Sofer Athlan-Guyot
>>
>> Colleen
>
> __
> 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
>
>


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

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

[Denis Egorenko]

+1

2015-12-09 0:25 GMT+03:00 Clayton O'Neill :

> +1
>
> On Tue, Dec 8, 2015 at 4:15 PM, Matt Fischer  wrote:
>
>> +1
>>
>> On Tue, Dec 8, 2015 at 2:07 PM, Rich Megginson 
>> wrote:
>>
>>> On 12/08/2015 09:49 AM, Emilien Macchi wrote:
>>>
>>> Hi,
>>>
>>> Back in "old days", Cody was already core on the modules, when they were
>>> hosted by Puppetlabs namespace.
>>> His contributions [1] are very valuable to the group:
>>> * strong 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=all_type=all_id=ody-cat
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>>>
>>>
>>
>> __
>> 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
>
>


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

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

[Denis Egorenko]

Hi Mehdi,

Thank you for your reply! It works for us.

2015-12-01 20:40 GMT+03:00 Mehdi Abaakouk :

> Hi,
>
> Current scheme supports only one RabbitMQ node with url parameter.
>>
>
> That's not true, you can pass many hosts via the url like that:
> rabbit://user:pass@host1:port1,user:pass@host2:port2/vhost
>
>
> http://docs.openstack.org/developer/oslo.messaging/transport.html#oslo_messaging.TransportURL
>
> But this is perhaps not enough for your use-case.
>
> Cheers,
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>



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

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

[Denis Egorenko]

>
> Denis, I actually don't think that Swift needs to use oslo.messaging at
> all. The middleware loads the rabbit configuration for the Notifier class
> from the CONF object here:
>
> https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112
> and that conf object should use the config file sections that
> oslo_messaging relies on, right? So, this should really just require a
> change to the swift-proxy conf files to add the [oslo_messaging] sections,
> I think?


Well, yes, it make sense. Current scheme supports only one RabbitMQ node
with url parameter. If there exists possibility use some kind of
oslo_messaging/rabbit_hosts - i'm ok with such approach.

2015-12-01 19:30 GMT+03:00 Jay Pipes <jaypi...@gmail.com>:

> On 12/01/2015 08:17 AM, Richard Hawkins wrote:
>
>> ​Is it possible to write the functionality you desire in your
>> own middleware for Swift that lives outside of the Swift code?  I would
>> favor that approach for the following reasons:
>>
>> * You would have more control over code/changes so your middleware could
>> stabilize and mature faster (don't have to wait for reviews from
>> community for minor tweaks).
>>
>> * Since you are writing it, you get exactly what you want.
>>
>> * Swift would not gain more dependancies that would have to be installed.
>>
>> There have been a few projects in the past that have been successful
>> middleware without being included (swauth, swift3, swift-informant).
>>
>> And in the end, if your middleware becomes wildly successful and
>> everybody uses it, there would be no reason it could not be merged into
>> the Swift code at a later time.​
>>
>
> It's not Denis' middleware. It's the Ceilometer community's middleware for
> Swift to emit notification payloads that Ceilometer understands:
>
> https://github.com/openstack/ceilometermiddleware
>
> Denis, I actually don't think that Swift needs to use oslo.messaging at
> all. The middleware loads the rabbit configuration for the Notifier class
> from the CONF object here:
>
>
> https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L112
>
> and that conf object should use the config file sections that
> oslo_messaging relies on, right? So, this should really just require a
> change to the swift-proxy conf files to add the [oslo_messaging] sections,
> I think?
>
> Best,
> -jay
>
> Thanks,
>> Richard Hawkins
>> Software Developer - Cloud Files (OpenStack Swift)
>> Rackspace
>>
>>
>>
>> 
>> *From:* Denis Egorenko <degore...@mirantis.com>
>> *Sent:* Tuesday, December 1, 2015 3:47 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift
>>
>> going to support oslo.messaging?
>> Hello folks,
>>
>> The issue I want to raise is related to Swift and Oslo.messaging.
>> Currently Swift doesn't support oslo.messaging middleware. There is no
>> possible to setup RabbitMQ HA setup in swift configuration, so we faced
>> the problem [1] in Fuel. If we want to use Ceilometer notifications for
>> Swift, we should use ceilometermiddleware. It provides possibility
>> configure properly transport settings for notifications [2]. The main
>> problem that Fuel uses HA RabbitMQ setup (mirrored queues) with direct
>> connection from clients. The client uses oslo.messaging to establish the
>> connection with one of rabbitmq servers. oslo.messaging uses heartbeats
>> to switch to another RabbitMQ server if/when there are any network
>> issues. However, Swift doesn't use oslo.messaging at all. It's possible
>> to specify only one RabbitMQ server in swift configuration hence there
>> can be problems if specified server is down or has network flapping
>> issues. Alternative solution is to use VIP for RabbitMQ [3]. This setup
>> is not perfect also as timeout and connection restore time is much worse.
>>
>> So, the question is:
>> Is Swift going to support oslo.messaging and particularly rabbit_hosts?
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1510064
>> [2] https://review.openstack.org/#/c/152273
>> [3] https://review.openstack.org/#/c/248147
>>
>> --
>> Best Regards,
>> Egorenko Denis,
>> Deployment Engineer
>> Mirantis
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [puppet] ::db classes

[Denis Egorenko]

Hi Clayton!

I would like to use the same solution for this problem as we have for
::logging class. So, we just leaving those default parameters
without $::os_service_default and putting old values (10, 20, etc) [1] and
also we should to raise warnings, as suggests Alex Schultz (for example,
[2]). For me - it is the best solution of problem.

[1]
https://github.com/openstack/puppet-cinder/blob/master/manifests/logging.pp#L98
[2] https://review.openstack.org/#/c/239800/5/manifests/backend/eqlx.pp

2015-11-11 18:04 GMT+03:00 Clayton O'Neill :

> On Wed, Nov 11, 2015 at 9:50 AM, Clayton O'Neill 
> wrote:
>
>> I discovered this issue last night and opened a bug on it (
>> https://bugs.launchpad.net/puppet-tuskar/+bug/1515273).
>>
>> This effects most of the modules, and the short version of it is that the
>> defaults in all the ::db classes are wrong for max_pool_size
>> and max_overflow.  We’re setting test to 10 and 20, but oslo_db actually
>> has no internal default.
>>
>
> To clarify: The modules following this pattern are setting max_pool_size
> and max_overflow to 10 and 20 respectively, but oslo_db has no internal
> default.
>
> __
> 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
>
>


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

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

[Denis Egorenko]

+1 to Emilien.

If somebody already have uploaded such patches - please, mark them as WIP,
until we finish all work for cinder.

2015-11-03 22:57 GMT+09:00 Emilien Macchi :

> 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
>
>
> __
> 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
>
>


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

Re: [openstack-dev] [puppet][ec2api] - First version of puppet module

[Denis Egorenko]

Hello Marcos,

I've look through on your module and it looks cool. Some code issues
inline. May be just only one nitpick from my side: can you add link to the
documentation in README file? Like it done in puppet-openstack modules.

Also thank you for caring of that and keeping in consistent with
puppet-openstack modules.

2015-10-15 10:49 GMT+03:00 Marcos Fermin Lobo :

> Hi all,
>
> I would like to report to all of you that a first version of OpenStack EC2
> API puppet module is available in order to get your feedback.
>
> This is the link https://github.com/cernops/puppet-ec2api
>
> Please feel free to contribute to this puppet module. All contributions
> and feedback are very welcome.
>
> Regards,
> Marcos.
>
> __
> 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
>
>


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

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

[Denis Egorenko]

Thank you! I will do my best!

2015-10-15 19:27 GMT+03:00 Emilien Macchi <emil...@redhat.com>:

>
>
> On 10/13/2015 04:29 PM, Emilien Macchi wrote:
> > Denis Egorenko (degorenko) is working on Puppet OpenStack modules for
> > quite some time now.
> >
> > Some statistics [1] about his contributions (last 6 months):
> > * 270 reviews
> > * 49 negative reviews
> > * 216 positive reviews
> > * 36 disagreements
> > * 30 commits
> >
> > Beside stats, Denis is always here on IRC participating to meetings,
> > helping our group discussions, and is always helpful with our community.
> >
> > I honestly think Denis is on the right path to become a good core member
> > team, he has strong knowledge in OpenStack deployments, knows enough
> > about our coding style and his involvement in the project is really
> > great. He's also a huge consumer of our modules since he's working on
> Fuel.
> >
> > I would like to open the vote to promote Denis part of Puppet OpenStack
> > core reviewers.
> >
>
> 3 positive feedback from our core reviewers.
> 0 negative feedback.
>
> Welcome Denis, we're happy to have you onboard!
> --
> 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
>
>


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

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

[Denis Egorenko]

+1 to way from paste above.

2015-09-23 16:42 GMT+03:00 Martin Mágr :

>
>
> On 09/23/2015 02:17 AM, Cody Herriges wrote:
>
> Alex Schultz wrote:
>
> Hey puppet folks,
>
> Based on the meeting yesterday[0], I had proposed creating a parser
> function called is_service_default[1] to validate if a variable matched
> our agreed upon value of ''.  This got me thinking
> about how can we maybe not use the arbitrary string throughout the
> puppet that can not easily be validated.  So I tested creating another
> puppet function named service_default[2] to replace the use of ' DEFAULT>' throughout all the puppet modules.  My tests seemed to
> indicate that you can use a parser function as parameter default for
> classes.
>
> I wanted to send a note to gather comments around the second function.
> When we originally discussed what to use to designate for a service's
> default configuration, I really didn't like using an arbitrary string
> since it's hard to parse and validate. I think leveraging a function
> might be better since it is something that can be validated via tests
> and a syntax checker.  Thoughts?
>
>
> Thanks,
> -Alex
>
> [0] 
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
> [1] https://review.openstack.org/#/c/223672
> [2] https://review.openstack.org/#/c/224187
>
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
>
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
> http://paste.openstack.org/show/473655
>
>
> +1 for implementation in pastebin above. Much better solution than running
> function.
>
> Regards,
> Martin
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


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

Re: [openstack-dev] [puppet] [sahara]

[Denis Egorenko]

Sorry, wrong link [3]  https://github.com/openstack/puppet-sahara
<https://github.com/openstack/sahara>

2015-09-08 19:31 GMT+03:00 Denis Egorenko <degore...@mirantis.com>:

> Hello everyone,
>
> Currently Sahara [1] keeps two run mods: stand alone mode (all-in-one) and
> distributed mode. Difference between those modes is that second mode
> creates separation between API and engine processes. Such architecture
> allows the API process to remain relatively free to handle requests while
> offloading intensive tasks to the engine processes. [2] Second mode is more
> appropriate for big and complex environments, but you can also use stand
> alone mode for simple tasks and tests.
>
> So, the main issue is that now puppet-sahara [3] uses only first
> all-in-one run mode. So, I've implemented support for distributed mode in
> puppet-sahara [4], please review this commit and provide feedback.
>
> Also i have some +1 from Sahara team, including Sahara Cores.
>
> [1] https://github.com/openstack/sahara
> [2]
> http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#distributed-mode-configuration
> [3] https://github.com/openstack/sahara
> [4] https://review.openstack.org/#/c/192721/
>
> Thanks.
>
> --
> Best Regards,
> Egorenko Denis,
> Deployment Engineer
> Mirantis
>



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

[openstack-dev] [puppet] [sahara]

[Denis Egorenko]

Hello everyone,

Currently Sahara [1] keeps two run mods: stand alone mode (all-in-one) and
distributed mode. Difference between those modes is that second mode
creates separation between API and engine processes. Such architecture
allows the API process to remain relatively free to handle requests while
offloading intensive tasks to the engine processes. [2] Second mode is more
appropriate for big and complex environments, but you can also use stand
alone mode for simple tasks and tests.

So, the main issue is that now puppet-sahara [3] uses only first all-in-one
run mode. So, I've implemented support for distributed mode in
puppet-sahara [4], please review this commit and provide feedback.

Also i have some +1 from Sahara team, including Sahara Cores.

[1] https://github.com/openstack/sahara
[2]
http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#distributed-mode-configuration
[3] https://github.com/openstack/sahara
[4] https://review.openstack.org/#/c/192721/

Thanks.

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

Re: [openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

[Denis Egorenko]

Hi Andrew!

Sahara already merged. All CI tests were succeeded, also was built custom
iso [1] and ran bvt tests [2], which also were succeeded and we got +1 from
QA team.
For Murano we will do the same: resolve all comments, build custom iso, run
custom bvt and wait +1 from Fuel CI and QA team.

[1]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/

[2]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/

2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com:

 I was looped into reviewing the sync commits for Murano and Sahara. Both
 are in terrible shape and risk feature freeze at this point.

 We need feed back from the authors here. What is actually required for
 Kilo support (if any)from the Murano and Sahara modules? What will happen
 if these slip the release. What can you do to simplify the review scope.
 The most we can reasonably review is 500 LOC in any short time (and that's
 pushing it).

 Synopsis:
 murano [1] is -2, this can't be merged; there is a adapt commit with out
 any sync commit. The only way we will accept the fork method is a sync from
 upstream +adapt as documented in [2] also it's neigh impossible to review
 something this large with out the separation.
 -2 There is no upstream repo with content, so where did this even come
 from? We are/where the authority for murano at present so I'm baffled as to
 where this came from.

 Possible way through: A) Split sync from adapt, hopefully the adapt is
 small enough to to review. B)Make only changes necessary for kilo support.

 Sahara [3][4]
 This is a RED flah here, I'm not even sure to call it -1, -2 or something
 entirely else. I had with Serg M, This is a sync of upstream, plus the code
 on review from fuel that is not merged into puppet-sahara. I'm going to say
 that our fork is in much better shape at this moment, and we should just
 let it be. We shouldn't sync this until the upstream code is landed.

 Possible way through: C) The two outstanding commits inside the adapt
 commit need to be pulled out. They should be proposed right on top of the
 sync commit and should apply cleanly. I would prefer to see them as
 separate commits so they can be compared to the source more accurately.
 This should bring the adapt to something that could be reviewed. D) propose
 only the changes necessary to get kilo support.

 [1] https://review.openstack.org/#/c/203731/
 [2]
 https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library
 [3] https://review.openstack.org/#/c/202045
 [4] https://review.openstack.org/#/c/202195/
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

 __
 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




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

[openstack-dev] Nailgun TypeValue error

[Denis Egorenko]

Hi colleagues!

I want to aware you about error in Nailgun [1]. I catched this in my patch
for Sahara [2] (patchset number 11, after resolving comment in 10). CI
tests were failed with error:

nailgun serializer failed TypeError: Value of settings:sahara.enabled.value
is undefined. Set options.strict to false to allow undefined value

As i described in bug, we have wrong option name for Sahara (and i suppose
for Murano too) in Nailgun. So, we need to rename those options.

[1] https://bugs.launchpad.net/fuel/+bug/1476953
[2] https://review.openstack.org/#/c/202195

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

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

[Denis Egorenko]

Hi guys!

 * Do not merge a patch without at least one review from both groups
 * Collaborate to make the module compliant
I'm strongly agree with it, because it'll help to avoid some mistakes.
Also, someone from puppet-manager-core may to prompt what are we doing
wrong or better way for elaboration of murano module.

Thanks!

2015-06-17 18:49 GMT+03:00 Serg Melikyan smelik...@mirantis.com:

 Emilien,

 Thank you for your proposal, I completely agree with it:

  * Move the module under the big tent
 Proposed change in infra [1] and corresponding change in governance [2]

  * Adding Puppet OpenStack group part of core permissions
 I've added puppet-manager-core to puppet-murano-core

  * Keep Puppet Murano folks part of core permissions for now
 I've added Denis Egorenko to puppet-murano-core (group was empty
 previously).

  * Do not merge a patch without at least one review from both groups
  * Collaborate to make the module compliant
 Denis will be responsible for initial review from Murano side in order
 to not overburden OpenStack Puppet with helping with Puppet basics. We
 will make sure to not merge anything without +2 from someone from
 puppet-manager-core. We will start with basic repository structure and
 will move existing module bit by bit.

  * When the module is compliant, we only keep Puppet OpenStack
group managing the module, like it's done for other modules.
 Sure!

 Once again thank you for your help and concerns!

 References:
 [1] https://review.openstack.org/192730
 [2] https://review.openstack.org/192727

 On Wed, Jun 17, 2015 at 5:03 PM, Emilien Macchi emil...@redhat.com
 wrote:
 
 
  On 06/17/2015 09:50 AM, Serg Melikyan wrote:
  Thank you for sharing link to list of things that new module should
  satisfy to! It will be really helpful even if list will change over
  time. At least we have pointers how to start making our module
  compliant.
 
  Regarding figuring out permissions - I don't mind if we will set
  puppet-core as group responsible for the repository, I believe that
  through contributing Murano module authors will get enough
  creditability to be included to the puppet-core. This will help to
  ensure that module is developed according all rules of Puppet
  OpenStack Community and nothing will be merged that does not satisfy
  adopted way of doing things. Emilien, if you agree with this approach
  I will send appropriate change to review.
 
 
  I like Monty's proposal.
 
  I propose:
  * Move the module under the big tent
  * Adding Puppet OpenStack group part of core permissions
  * Keep Puppet Murano folks part of core permissions for now
  * Do not merge a patch without at least one review from both groups
  * Collaborate to make the module compliant
  * When the module is compliant, we only keep Puppet OpenStack group
  managing the module, like it's done for other modules.
 
 
 
 
 
  On Wed, Jun 17, 2015 at 4:08 PM, Monty Taylor mord...@inaugust.com
 wrote:
  On 06/17/2015 08:53 AM, Emilien Macchi wrote:
  Hi Serg,
 
  On 06/17/2015 05:35 AM, Serg Melikyan wrote:
  Hi Emilien,
 
  I would like to answer your question regarding
  stackforge/puppet-murano repository asked in different thread:
 
  Someone from Fuel team created first the module in Fuel, 6
  months ago [1] and 3 months later someone from Fuel team
  created an empty repository in Stackforge [2]. By the way,
  Puppet OpenStack community does not have core permissions on
  this module and it's own by Murano team.
 
  Murano was included to Fuel around 2 years ago, our first
  official release as part of Fuel was Icehouse - yes, we have
  puppet module for Murano for a long time now. But until recently
  we didn't had a Big Tent in place and that is why we never
  thought that we able to upstream our module.
 
  Once policy regarding upstream puppet modules in Fuel changed and
  Big Tent model was adopted we decided to upstream module for
  Murano. I am really sorry that I didn't contact you for more
  information how to do that properly and just created
  corresponding repository.
 
  Well, in fact, I'm sorry for you; you could not benefit of Puppet
  OpenStack community. Let's fix that.
 
  I didn't give permission to Puppet OpenStack community for this
  repository because it would be strange, given I didn't even
  contact you. We thought that we would upstream what we have now
  and then make sure that this repo will be integrated with Puppet
  OpenStack ecosystem.
 
  We still have big desire to upstream our puppet module. Fuel is
  not only user of this module, there are other projects who would
  like to use Murano as part of they solution and use puppet module
  from Fuel for deployment.
 
  Can you advise how we should proceed further?
 
  The more recent patch to add a module in OpenStack is zaqar:
  https://review.openstack.org/#/c/191942/
 
  Two things we need to solve is the fact if you move your module to
  the big tent: * bring the module compliant (I'm working on a
  blueprint

Re: [openstack-dev] [Fuel] Default templates for Sahara feature in 6.0

[Denis Egorenko]

Hi guys,

I've created spec for this patch: https://review.openstack.org/#/c/134937/

Please, check out it.

2014-11-17 15:41 GMT+04:00 Mike Scherbakov mscherba...@mirantis.com:

 I'm fine with getting this patch in...
 though a few things should be fixed first, in my opinion:

1. I don't see a header in the blueprint, who is responsible for what.
See example in the blueprint:
https://blueprints.launchpad.net/fuel/+spec/send-anon-usage (Feature
Lead, QA, etc.)
2. There is no fuel-spec associated. If this is very minor thing to
address, which doesn't affect anything beyond, then we probably better to
track this as bug.
3. Currently, it's not very clear to me from description what this is
for. Can you please provide more information, ideally what are the use
cases, and acceptance criteria for proposed functionality?

 We have FF deadline not just because features can affect other features
 stability, but also because we will need time to assure they are of
 production quality by themselves. Slipping this to the end of the release
 naturally increases risks for quality.

 Thanks,

 On Sat, Nov 15, 2014 at 3:51 AM, Dmitry Mescheryakov 
 dmescherya...@mirantis.com wrote:

 Oops, the last line should be read as
 On the other side, it is a nice UX feature we really want to have 6.0

 Dmitry

 2014-11-15 3:50 GMT+03:00 Dmitry Mescheryakov dmescherya...@mirantis.com
 :

 Dmitry,

 Lets review the CR from the point of danger to current deployment
 process: in the essence it is 43 lines of change in puppet module. The
 module calls a shell script which always returns 0. So whatever happens
 inside, the deployment will not fail.

 The only changes (non-get requests) the script does, it does to Sahara.
 It tries to upload cluster and node-group templates. That is not dangerous
 operation for Sahara - in the worst case the templates will just not be
 created and that is all. It will not affect Sahara correctness in any way.

 On the other side, it is a nice UX feature we really want to have 5.1.1.

 Thanks,

 Dmitry


 2014-11-15 3:04 GMT+03:00 Dmitry Borodaenko dborodae...@mirantis.com:

 +286 lines a week after Feature Freeze, IMHO it's too late to make an
 exception for this one.

 On Wed, Nov 12, 2014 at 7:37 AM, Dmitry Mescheryakov
 dmescherya...@mirantis.com wrote:
  Hello fuelers,
 
  I would like to request you merging CR [1] which implements blueprint
 [2].
  It is a nice UX feature we really would like to have in 6.0. On the
 other
  side, the implementation is really small: it is a small piece of
 puppet
  which runs a shell script. The script always exits with 0, so the
 change
  should not be dangerous. Other files in the change are used in the
 shell
  script only. Please consider reviewing and merging this though we've
 already
  reached FF.
 
  Thanks,
 
  Dmitry
 
  [1] https://review.openstack.org/#/c/132196/
  [2]
 
 https://blueprints.launchpad.net/mos/+spec/sahara-create-default-templates
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



 --
 Dmitry Borodaenko

 ___
 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




 --
 Mike Scherbakov
 #mihgen


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best Regards,
Egorenko Denis
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev