Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

[Scott Brimhall]

Hi Dmitry,

We have reached design agreement on this feature as of this morning, March 
10th.  The spec has been accepted and the test/merge plan presented for 
remaining patches by March 24 was agreed upon.  Can the conditional status of 
the FFE request be removed, please?

Thanks,
Scott Brimhall

> On Mar 3, 2016, at 5:22 PM, Dmitry Borodaenko  
> wrote:
> 
> Granted conditionally, design consensus deadline March 10, merge
> deadline March 16 for patches that do not conflict with
> fuel-openstack-tasks and fuel-remove-conflict-openstack, March 24 for
> remaining patches.
> 
> If design consensus is not reached by March 10, the exception will be
> revoked.
> 
> -- 
> Dmitry Borodaenko
> 
> 
> On Wed, Mar 02, 2016 at 07:01:02AM -0700, Scott Brimhall wrote:
>> This is not possible to move to 10. This is a critical feature that
>> our 2 largest customers are dependent on for deployment at the end of
>> May. Puppet Master flat out will not work with a Fuel deployed
>> environment without doing this unless we were to create our own
>> composition layer, which would leave us with two separate code bases
>> to maintain.  That isn't an option and this pretty much has to happen
>> in 9.
>> 
>> ---
>> Scott Brimhall, Cloud Architect
>> Mirantis - Pure Play Openstack
>> 
>>> On Mar 2, 2016, at 02:01, Aleksandr Didenko  wrote:
>>> 
>>> Hi,
>>> 
 Merging this code is relatively non-intrusive to core Fuel Library code
 as it is merely re-organizing the file structure of the osnailyfacter
 module to be compatible with Puppet Master. 
>>> 
>>> It looks like super-intrusive to me. Modular manifests are,
>>> actually, the core of Fuel Library. And the majority of changes we
>>> introduce in Fuel Library are proposed for those manifests. So if
>>> you're going to move those manifests into "osnailyfacter::*" classes
>>> then it will basically conflict with the 90% of other patches for
>>> Fuel Library. This may slow down development of other features as
>>> well as bug fixing.
>>> 
>>> Also I see no patches on review and spec is not yet accepted. I
>>> think starting such an intrusive feature after FF is too risky,
>>> let's move it to 10.0.
>>> 
>>> Regards,
>>> Alex
>>> 
 On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall  
 wrote:
 Greetings,
 
 As you might know, we are working on integrating a 3rd party
 configuration management platform (Puppet Master) with Fuel.
 This integration will provide the capability for state enforcement
 and will further enable "day 2" operations of a Fuel-deployed site.
 We must refactor the 'osnailyfacter' module in Fuel Library to be
 compatible with both a masterful and masterless Puppet approach.
 
 This change is required to enable a Puppet Master based LCM
 solution.
 
 We request a FFE for this feature for 3 weeks, until Mar 24.  By that
 time, we will provide a tested solution in accordance with the following
 specifications [1].
 
 The feature includes the following components:
 
 1. Refactor 'osnailyfacter' Fuel Library module to be compatible with
 Puppet Master by becoming a valid and compliant Puppet module.
 This involves moving manifests into the proper manifests directory
 and moving the contents into classes that can be included by Puppet
 Master.
 2. Update deployment tasks to update their manifest path to the new
 location.
 
 Merging this code is relatively non-intrusive to core Fuel Library code
 as it is merely re-organizing the file structure of the osnailyfacter
 module to be compatible with Puppet Master.  Upon updating the
 deployment tasks to reflect the new location of manifests, this feature
 remains compatible with the masterless puppet apply approach that
 Fuel uses while providing the ability to integrate a Puppet Master
 based LCM solution.
 
 Overall, I consider this change as low risk for integrity and timeline of
 the release and it is a critical feature for the ability to integrate an 
 LCM
 solution using Puppet Master.
 
 Please consider our request and share concerns so we can properly
 resolve them.
 
 [1] 
 https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility
 
 ---
 Best Regards,
 
 Scott Brimhall
 Systems Architect
 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
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Igor Kalnitsky]

Well, what about tomorrow? On SCF we create stable branches and master
is open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata. Because it's something that we usually don't want
to release, and FPB lifecycle is untied from Fuel's.

The only way to avoid that problem is to teach tests to prepare
plugins themselves. They are like test fixtures, it's not very good
that your rely on something that you don't maintain.

On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L  wrote:
> Mike,
>
> # 2 don't agree, we already generate from templates required information for
> a plugin developer to start development, purpose of plugin examples is
> different, it's used as integration tests for plugins, also QA team uses
> them as Functional tests, they overloaded with tasks and designed to have
> good coverage, so it will only confuse plugin developer.
> # 3 adding real deployment test for fuel-plugins will not help here, since
> change in openstack.yaml caused this problem.
>
> Thanks,
>
> On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn 
> wrote:
>>
>> Mike,
>>
>> #1 - If you truly agree with that, you should weigh in here:
>> https://review.openstack.org/#/c/287286/
>> #2 - Requires a blueprint and new docs, but okay.
>> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is
>> ensure it makes a plugin, not that it can be installed and deployed.
>>
>> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
>>  wrote:
>> > Folks,
>> > here is what I think:
>> > 1) I suggest to fix what is broken now. So that people who come across
>> > examples would not have to deal with issues. We may debate for other few
>> > days (hopefully not more), and all plugin devs will be suffering during
>> > this
>> > time. Also, according to Matt,
>> >
>> >> I should add that this is the only automated daily test that will
>> >> verify
>> > that our plugin framework actually works.
>> > simply means that we must fix it in order to catch any possible
>> > regressions
>> > we may introduce later (if not already).
>> >
>> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
>> > into it and get feedback), we may not need to have example plugins.
>> > However,
>> > we can have fpb generating template plugin, with commented code in
>> > there. If
>> > you uncomment, you a get a comprehensive example of a working plugin.
>> > To ensure that uncommented code would actually work, we must have a test
>> > for
>> > it (which would uncomment - run - ensure everything deploys).
>> >
>> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest
>> > to
>> > think if there is a way to have tests, which would run such examples
>> > against
>> > pluggable framework for every change to the framework, so that we can
>> > have
>> > -1 right away if something goes wrong.
>> >
>> > I've started separate thread on general thoughts about backward
>> > compatibility and multiple releases support, which actually affects
>> > examples: [1]
>> >
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
>> >
>> > Thanks,
>> >
>> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
>> >>
>> >> Because it doesn't make much sense for a plugin developer to have
>> >> scripts
>> >> to build packages for installation on slave nodes. For default template
>> >> it's
>> >> better to have something minimalistic and the rest of the tasks
>> >> commented,
>> >> otherwise it may create a lot of confusion.
>> >>
>> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
>> >> wrote:
>> >>>
>> >>> Talking about templates I mean plugins generated by FBP from the
>> >>> `templates` folder using command you mentioned above.
>> >>>
>> >>> Why not to extend (not replace) template-generated plugins with
>> >>> additional data to provide right coverage?
>> >>>
>> >>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>> 
>>  Ilya,
>> 
>>  What do you mean by "templates" the plugin which is create by just
>>  "fpb
>>  --create plugin-name"?
>>  It doesn't cover enough, package installation and all range of tasks
>>  executions.
>> 
>>  Thanks,
>> 
>>  On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>>  wrote:
>> >
>> > Igor, i completely agree, actually plugin examples is almost a
>> > copy-paste.
>> >
>> > The only thing i see useful in the built plugins example is the
>> > ability
>> > to point some code lines, discussing plugin design and writing
>> > documentation. Why not to generate this examples automatically from
>> > templates?
>> >
>> > Also, as developer and administrator i love to use
>> > examples/templates
>> > where all essential settings and options are persist but commented
>> > (e.g.
>> > ProFTPD or Apache) and i could uncomment and copy-paste them not
>> > being
>> > afraid of typos. Also it allows to keep do

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Aleksandr Didenko]

> Good idea. That should be done despite on any decision we will take.

Currently you have to specify which releases your plugin supports [0]. So I
can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually
did it and it worked just fine). But I won't be able to enable this plugin
for "mitaka-9.0" release because plugin was not developed and tested for
it, so it does not have "miraka-9.0" in "releases" list [0]. So I don't
quite understand how new "validated_against" parameter will differ from
existing "releases" list.

Regards,
Alex

[0]
https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21


On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya 
wrote:

> On 10.03.2016 08:30, Mike Scherbakov wrote:
> > Hi folks,
> > in order to make a decision whether we need to support example plugins,
> > and if actually need them [1], I'd suggest to discuss more common things
> > about plugins.
> >
> > My thoughts:
> > 1) This is not good, that our plugins created for Fuel 8 won't even
> > install on Fuel 9. By default, we should assume that plugin will work at
> > newer version of Fuel. However, for proper user experience, I suggest to
> > create meta-field "validated_against", where plugin dev would provide
> > versions of Fuel this plugin has been tested with. Let's say, it was
> > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest
> > to show a warning saying about risks and the fact that the plugin has
> > not been tested against 9. We should not restrict intsallation against
> > 9, though.
>
> Good idea. That should be done despite on any decision we will take.
>
> >
> > 2) We need to keep backward compatibility of pluggable interface for a
> > few releases. So that plugin developer can use pluggable interface of
> > version x, which was supported in Fuel 6.1. If we still support it, it
> > would mean (see next point) compatibility of this plugin with 6.1, 7.0,
> > 8.0, 9.0. If we want to deprecate pluggable interface version, we should
> > announce it, and basically follow standard process of deprecation.
> >
> > 3) Plugin's ability to work against multiple releases of Fuel
> > (multi-release support). If if..else clauses to support multiple
> > releases are fairly minimal, let's say take less that 10% of LOC, I'd
> > suggest to have this supported. Just because it will be easier for
> > plugin devs to support their plugin code (no code duplication, single
> > repo for multiple releases).
> >
> > Thoughts?
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> >
> __
> > 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,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> 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] [fuel][Fuel-web] : make html command not working

[Igor Kalnitsky]

Hey Prameswar,

That't because dependencies weren't installed. I can't remember which
ones are required for building docs so my suggestion is to install
them all.

$ virtualenv venv
$ . venv/bin/activate
$ pip install -r ../nailgun/test-requirements.txt
$ make html

Let me know if you need some help.

- Igor

On Thu, Mar 10, 2016 at 10:01 AM, Prameswar Lal  wrote:
> i have cloned fuel repo and follow
> https://docs.fuel-infra.org/fuel-dev/develop/env.html steps : in section 5.7
> building Documentaion . when i run command  " make html " it gives follow
> error.
>
>
> (fuel-web-venv)pramesh@pramesh:~/Documents/fuel-web/docs$ make html
> sphinx-build -b html -W -d _build/doctrees   . _build/html
> Traceback (most recent call last):
>   File "/usr/local/bin/sphinx-build", line 5, in 
> from pkg_resources import load_entry_point
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2749, in
> 
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 446, in
> _build_master
> return cls._build_from_requirements(__requires__)
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 459, in
> _build_from_requirements
> dists = ws.resolve(reqs, Environment())
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 628, in
> resolve
> raise DistributionNotFound(req)
> pkg_resources.DistributionNotFound: Sphinx==1.4b1
> make: *** [html] Error 1
>
>
> __
> 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] [Fuel] UI code freeze

[Vladimir Kozhukalov]

​Evge​niy,

Right. There is only nailgun python project, development documentation [1]
and some minor scripts [2] which are outdated. Our further plan is to move
nailgun itself to a separate repo fuel-nailgun, remove outdated code, and
then move development doc pages to corresponding git repos.

[1] https://github.com/openstack/fuel-web/tree/master/docs
[2] https://github.com/openstack/fuel-web/tree/master/bin
__
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] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Maksim Malchuk]

Hi All,

I'm very appreciate being a part of the Fuel project as core reviewers team!
Thank you all for nomination and for +1s!


On Thu, Mar 10, 2016 at 12:40 PM, Sergey Kulanov 
wrote:

> Voting period is over and there's no objections from cores.
> So Maksim, welcome to fuel-virtualbox-core group.
>
> Congrats!
>
> 2016-03-09 13:33 GMT+02:00 Sergii Golovatiuk :
>
>> +1
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Wed, Mar 9, 2016 at 8:07 AM, Bulat Gaifullin 
>> wrote:
>>
>>> +1
>>>
>>> Regards,
>>> Bulat Gaifullin
>>> Mirantis Inc.
>>>
>>>
>>>
>>> On 03 Mar 2016, at 17:03, Dmitry Klenov  wrote:
>>>
>>> Maksim, good job! +1 from my side though I am not a core.
>>>
>>> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev <
>>> azvyagint...@mirantis.com> wrote:
>>>
 +1

 On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> +1
>
> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov  > wrote:
>
>> +1
>>
>> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov 
>> wrote:
>>
>>> +1
>>>
>>> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov <
>>> skula...@mirantis.com> wrote:
>>>
 Hey Fuelers,

 Since we've successfully moved [1] virtual-box scripts from
 fuel-main [2] to
 separate fuel-virtualbox [3] git repo, I propose to update
 fuel-virtualbox-core
 team [4] by adding Maksim Malchuk. Maksim is the main contributor
 to these
 scripts during Mitaka release cycle [5]

 Fuel Cores, please vote.

 [1].
 http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
 [2]. https://github.com/openstack/fuel-main
 [3]. https://github.com/openstack/fuel-virtualbox
 [4]. https://review.openstack.org/#/admin/groups/1299,members
 [5]. https://github.com/openstack/fuel-virtualbox/commits/master

 --
 Sergey
 DevOps Engineer
 IRC: SergK
 Skype: Sergey_kul


 __
 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
>>
>>
>
>
> __
> 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,
Aleksey Zvyagintsev


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

Re: [openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Sergey Kulanov]

Voting period is over and there's no objections from cores.
So Maksim, welcome to fuel-virtualbox-core group.

Congrats!

2016-03-09 13:33 GMT+02:00 Sergii Golovatiuk :

> +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Mar 9, 2016 at 8:07 AM, Bulat Gaifullin 
> wrote:
>
>> +1
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> On 03 Mar 2016, at 17:03, Dmitry Klenov  wrote:
>>
>> Maksim, good job! +1 from my side though I am not a core.
>>
>> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev <
>> azvyagint...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 +1

 On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov 
 wrote:

> +1
>
> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov 
> wrote:
>
>> +1
>>
>> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov > > wrote:
>>
>>> Hey Fuelers,
>>>
>>> Since we've successfully moved [1] virtual-box scripts from
>>> fuel-main [2] to
>>> separate fuel-virtualbox [3] git repo, I propose to update
>>> fuel-virtualbox-core
>>> team [4] by adding Maksim Malchuk. Maksim is the main contributor to
>>> these
>>> scripts during Mitaka release cycle [5]
>>>
>>> Fuel Cores, please vote.
>>>
>>> [1].
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
>>> [2]. https://github.com/openstack/fuel-main
>>> [3]. https://github.com/openstack/fuel-virtualbox
>>> [4]. https://review.openstack.org/#/admin/groups/1299,members
>>> [5]. https://github.com/openstack/fuel-virtualbox/commits/master
>>>
>>> --
>>> Sergey
>>> DevOps Engineer
>>> IRC: SergK
>>> Skype: Sergey_kul
>>>
>>>
>>> __
>>> 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
>
>


 __
 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,
>>>Aleksey Zvyagintsev
>>>
>>>
>>> __
>>> 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
>>
>>
>
> __
> 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
>
>


-- 
Sergey
DevOps Engineer
IRC: SergK
Skype: Sergey_kul
__
OpenStack Development Mailing List (n

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Bogdan Dobrelya]

On 10.03.2016 08:30, Mike Scherbakov wrote:
> Hi folks,
> in order to make a decision whether we need to support example plugins,
> and if actually need them [1], I'd suggest to discuss more common things
> about plugins.
> 
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even
> install on Fuel 9. By default, we should assume that plugin will work at
> newer version of Fuel. However, for proper user experience, I suggest to
> create meta-field "validated_against", where plugin dev would provide
> versions of Fuel this plugin has been tested with. Let's say, it was
> tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest
> to show a warning saying about risks and the fact that the plugin has
> not been tested against 9. We should not restrict intsallation against
> 9, though.

Good idea. That should be done despite on any decision we will take.

> 
> 2) We need to keep backward compatibility of pluggable interface for a
> few releases. So that plugin developer can use pluggable interface of
> version x, which was supported in Fuel 6.1. If we still support it, it
> would mean (see next point) compatibility of this plugin with 6.1, 7.0,
> 8.0, 9.0. If we want to deprecate pluggable interface version, we should
> announce it, and basically follow standard process of deprecation.
> 
> 3) Plugin's ability to work against multiple releases of Fuel
> (multi-release support). If if..else clauses to support multiple
> releases are fairly minimal, let's say take less that 10% of LOC, I'd
> suggest to have this supported. Just because it will be easier for
> plugin devs to support their plugin code (no code duplication, single
> repo for multiple releases).
> 
> Thoughts?
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> -- 
> Mike Scherbakov
> #mihgen
> 
> 
> __
> 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,
Bogdan Dobrelya,
Irc #bogdando

__
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][plugins] Should we maintain example plugins?

[Evgeniy L]

Mike,

# 2 don't agree, we already generate from templates required information
for a plugin developer to start development, purpose of plugin examples is
different, it's used as integration tests for plugins, also QA team uses
them as Functional tests, they overloaded with tasks and designed to have
good coverage, so it will only confuse plugin developer.
# 3 adding real deployment test for fuel-plugins will not help here, since
change in openstack.yaml caused this problem.

Thanks,

On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn 
wrote:

> Mike,
>
> #1 - If you truly agree with that, you should weigh in here:
> https://review.openstack.org/#/c/287286/
> #2 - Requires a blueprint and new docs, but okay.
> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is
> ensure it makes a plugin, not that it can be installed and deployed.
>
> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
>  wrote:
> > Folks,
> > here is what I think:
> > 1) I suggest to fix what is broken now. So that people who come across
> > examples would not have to deal with issues. We may debate for other few
> > days (hopefully not more), and all plugin devs will be suffering during
> this
> > time. Also, according to Matt,
> >
> >> I should add that this is the only automated daily test that will verify
> > that our plugin framework actually works.
> > simply means that we must fix it in order to catch any possible
> regressions
> > we may introduce later (if not already).
> >
> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
> > into it and get feedback), we may not need to have example plugins.
> However,
> > we can have fpb generating template plugin, with commented code in
> there. If
> > you uncomment, you a get a comprehensive example of a working plugin.
> > To ensure that uncommented code would actually work, we must have a test
> for
> > it (which would uncomment - run - ensure everything deploys).
> >
> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest
> to
> > think if there is a way to have tests, which would run such examples
> against
> > pluggable framework for every change to the framework, so that we can
> have
> > -1 right away if something goes wrong.
> >
> > I've started separate thread on general thoughts about backward
> > compatibility and multiple releases support, which actually affects
> > examples: [1]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
> >
> > Thanks,
> >
> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
> >>
> >> Because it doesn't make much sense for a plugin developer to have
> scripts
> >> to build packages for installation on slave nodes. For default template
> it's
> >> better to have something minimalistic and the rest of the tasks
> commented,
> >> otherwise it may create a lot of confusion.
> >>
> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
> >> wrote:
> >>>
> >>> Talking about templates I mean plugins generated by FBP from the
> >>> `templates` folder using command you mentioned above.
> >>>
> >>> Why not to extend (not replace) template-generated plugins with
> >>> additional data to provide right coverage?
> >>>
> >>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
> 
>  Ilya,
> 
>  What do you mean by "templates" the plugin which is create by just
> "fpb
>  --create plugin-name"?
>  It doesn't cover enough, package installation and all range of tasks
>  executions.
> 
>  Thanks,
> 
>  On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>  wrote:
> >
> > Igor, i completely agree, actually plugin examples is almost a
> > copy-paste.
> >
> > The only thing i see useful in the built plugins example is the
> ability
> > to point some code lines, discussing plugin design and writing
> > documentation. Why not to generate this examples automatically from
> > templates?
> >
> > Also, as developer and administrator i love to use examples/templates
> > where all essential settings and options are persist but commented
> (e.g.
> > ProFTPD or Apache) and i could uncomment and copy-paste them not
> being
> > afraid of typos. Also it allows to keep documentation actual and head
> > documentation small. Duplication of inline documentation between
> examples
> > and templates making things more weird and overshadows idea of inline
> > documentation itself.
> >
> > Eugeny, why not to run integration tests against plugins generated
> from
> > templates? It's will be even better integration tests.
> >
> >
> >
> > On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
> >  wrote:
> >>
> >> > and really lowering barriers for people who just begin create
> >> > plugins.
> >>
> >> Nonsense. First, people usually create them via running `fpb
> --create
> >> plugin-name` that generates plugin boilerplate. And that boilerplate
> >> won't cont

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Evgeniy L]

Hi Mike, comments are inline.

On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov 
wrote:

> Hi folks,
> in order to make a decision whether we need to support example plugins,
> and if actually need them [1], I'd suggest to discuss more common things
> about plugins.
>
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even
> install on Fuel 9. By default, we should assume that plugin will work at
> newer version of Fuel. However, for proper user experience, I suggest to
> create meta-field "validated_against", where plugin dev would provide
> versions of Fuel this plugin has been tested with. Let's say, it was tested
> against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest to show a
> warning saying about risks and the fact that the plugin has not been tested
> against 9. We should not restrict intsallation against 9, though.
>

User can install all previous version of plugins on Fuel 9, but those
plugins are not going to be shown for Mitaka-9.0 release (for old release
only). It should be added into compatibility list in order to make it
compatible with OpenStack release. If you want to allow to enable plugin
for specific release, it's going to be tricky since the format of DSL for
different releases can be different, and you may get not only broken
deployment, but 500 error from Nailgun since it will get unexpected format
of data.


>
> 2) We need to keep backward compatibility of pluggable interface for a few
> releases. So that plugin developer can use pluggable interface of version
> x, which was supported in Fuel 6.1. If we still support it, it would mean
> (see next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If
> we want to deprecate pluggable interface version, we should announce it,
> and basically follow standard process of deprecation.
>

It requires clarification, in fact we support backward compatibility for
previous release, this requirement is a result of Fuel upgradability
requirement (after upgrade to new Fuel plugins won't get broken for old
releases).
If we are talking about plugin format improvement/changes, then yes, we are
thinking about deprecation, but it should be improved by sending
announcement/writing document/providing appropriate messages during build.


> 3) Plugin's ability to work against multiple releases of Fuel
> (multi-release support). If if..else clauses to support multiple releases
> are fairly minimal, let's say take less that 10% of LOC, I'd suggest to
> have this supported. Just because it will be easier for plugin devs to
> support their plugin code (no code duplication, single repo for multiple
> releases).
>
> If you are referring to compatibility with master node, it's being
supported.
If it's about multi-release (OpenStack) support, it will take more time
(and problems afterwards) to drop support of multi-release plugins. Hope
that our tech debt will be fixed in the next release, since FFE was not
granted for the current release [1]. Also we've had a huge discussion about
it in a separate thread [2].

[1] https://review.openstack.org/#/c/271417/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086381.html

Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> --
> Mike Scherbakov
> #mihgen
>
> __
> 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] [Fuel][Fuel-Library] Fuel CI issues

[Thomas Goirand]

On 03/01/2016 12:21 PM, Vladimir Kuklin wrote:
> Moreover, having such git ref as a source in our Puppetfile will lead to
> the situation when we have UNREPRODUCIBLE build of Fuel project. Each
> build may and will result in different code and you will not be able to
> tell which one without actually looking into the build logs.

Which is exactly why we should move away from commit, and start
building, and maybe automatically updating, puppet-module-* Debian (or
CentOS) packages. Such package update could be done the way you
suggested: based on nightly builds with a CI job that check if they work
properly. I do agree with you that a 1 day delay is acceptable, but we
should try to reduce it as much as possible. It'd be easy to keep a copy
of the built package (for a few days?), and make a reference of what was
the used top level commit sha256 hash, so we have a reference point of
what worked, and what didn't.

I'd love to have the Debian package for puppet modules automatically
built in upstream infra (on each commit, and for every CR), though
unfortunately, we're not there yet. Hopefully, we'll see the light at
the end of this tunnel, and it will eventually happen.

BTW, IMO, this discussion is completely orthogonal to having a fully
working check job within puppet-openstack. Mixing both conversations is
a dangerous slope which we should avoid.

> Additionally, we do not have:
> 
> 1) depends-on support
> 2) any process instantiated for monitoring of the Puppet-Openstack FUEL
> CI job
> 3) any person responsible for monitoring of that job

If we do nightly builds of puppet modules, then we *also* need someone
to take the responsibility, don't we? The same way as you wrote, this
may lead to a full one day of work, no? What would be the difference?

Cheers,

Thomas Goirand (zigo)


__
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][Fuel-web] : make html command not working

[Prameswar Lal]

i have cloned fuel repo and follow
https://docs.fuel-infra.org/fuel-dev/develop/env.html steps : in section
5.7 building Documentaion . when i run command  " make html " it gives
follow error.


(fuel-web-venv)pramesh@pramesh:~/Documents/fuel-web/docs$ make html
sphinx-build -b html -W -d _build/doctrees   . _build/html
Traceback (most recent call last):
  File "/usr/local/bin/sphinx-build", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2749, in

working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 446, in
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 459, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 628, in
resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: Sphinx==1.4b1
make: *** [html] Error 1
__
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][plugins] Should we maintain example plugins?

[Matthew Mosesohn]

Mike,

#1 - If you truly agree with that, you should weigh in here:
https://review.openstack.org/#/c/287286/
#2 - Requires a blueprint and new docs, but okay.
#3 - Yes! We have very poor CI for fuel plugin builder. All it does is
ensure it makes a plugin, not that it can be installed and deployed.

On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
 wrote:
> Folks,
> here is what I think:
> 1) I suggest to fix what is broken now. So that people who come across
> examples would not have to deal with issues. We may debate for other few
> days (hopefully not more), and all plugin devs will be suffering during this
> time. Also, according to Matt,
>
>> I should add that this is the only automated daily test that will verify
> that our plugin framework actually works.
> simply means that we must fix it in order to catch any possible regressions
> we may introduce later (if not already).
>
> 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
> into it and get feedback), we may not need to have example plugins. However,
> we can have fpb generating template plugin, with commented code in there. If
> you uncomment, you a get a comprehensive example of a working plugin.
> To ensure that uncommented code would actually work, we must have a test for
> it (which would uncomment - run - ensure everything deploys).
>
> 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest to
> think if there is a way to have tests, which would run such examples against
> pluggable framework for every change to the framework, so that we can have
> -1 right away if something goes wrong.
>
> I've started separate thread on general thoughts about backward
> compatibility and multiple releases support, which actually affects
> examples: [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
>
> Thanks,
>
> On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
>>
>> Because it doesn't make much sense for a plugin developer to have scripts
>> to build packages for installation on slave nodes. For default template it's
>> better to have something minimalistic and the rest of the tasks commented,
>> otherwise it may create a lot of confusion.
>>
>> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
>> wrote:
>>>
>>> Talking about templates I mean plugins generated by FBP from the
>>> `templates` folder using command you mentioned above.
>>>
>>> Why not to extend (not replace) template-generated plugins with
>>> additional data to provide right coverage?
>>>
>>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:

 Ilya,

 What do you mean by "templates" the plugin which is create by just "fpb
 --create plugin-name"?
 It doesn't cover enough, package installation and all range of tasks
 executions.

 Thanks,

 On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
 wrote:
>
> Igor, i completely agree, actually plugin examples is almost a
> copy-paste.
>
> The only thing i see useful in the built plugins example is the ability
> to point some code lines, discussing plugin design and writing
> documentation. Why not to generate this examples automatically from
> templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
>  wrote:
>>
>> > and really lowering barriers for people who just begin create
>> > plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really
>> > lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
>> > 
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it.
>> >> We
>> >> maintained

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Matthew Mosesohn]

Hi Mike,

Normally I would support your idea, but the reality is any plugin from
7.0 that defines a plugin role isn't going to work in 8.0 or 9.0. We
changed too many task names and you just can't make a plugin support
both versions not without something incredibly clever that I
haven't thought of already. If I'm a plugin developer, I'm not going
to advertise support for versions that won't work or expect it to
work when I haven't stated it explicitly.

The example plugins are quite simple and have no real tasks, so
enabling this for plugins is ok.  For real plugins that do more then
install 1 package and enable 1 service, version limiting is the only
thing to keep your users from losing their hair trying to figure out
why it doesn't work.

Best Regards,
Matthew Mosesohn

On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov
 wrote:
> Hi folks,
> in order to make a decision whether we need to support example plugins, and
> if actually need them [1], I'd suggest to discuss more common things about
> plugins.
>
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even install
> on Fuel 9. By default, we should assume that plugin will work at newer
> version of Fuel. However, for proper user experience, I suggest to create
> meta-field "validated_against", where plugin dev would provide versions of
> Fuel this plugin has been tested with. Let's say, it was tested against 7.0,
> 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning saying
> about risks and the fact that the plugin has not been tested against 9. We
> should not restrict intsallation against 9, though.
>
> 2) We need to keep backward compatibility of pluggable interface for a few
> releases. So that plugin developer can use pluggable interface of version x,
> which was supported in Fuel 6.1. If we still support it, it would mean (see
> next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If we want
> to deprecate pluggable interface version, we should announce it, and
> basically follow standard process of deprecation.
>
> 3) Plugin's ability to work against multiple releases of Fuel (multi-release
> support). If if..else clauses to support multiple releases are fairly
> minimal, let's say take less that 10% of LOC, I'd suggest to have this
> supported. Just because it will be easier for plugin devs to support their
> plugin code (no code duplication, single repo for multiple releases).
>
> Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> --
> Mike Scherbakov
> #mihgen
>
> __
> 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] [fuel][plugins] Should we maintain example plugins?

[Mike Scherbakov]

Folks,
here is what I think:
1) I suggest to fix what is broken now. So that people who come across
examples would not have to deal with issues. We may debate for other few
days (hopefully not more), and all plugin devs will be suffering during
this time. Also, according to Matt,

> I should add that this is the only automated daily test that will verify
that our plugin framework actually works.
simply means that we must fix it in order to catch any possible regressions
we may introduce later (if not already).

2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
into it and get feedback), we may not need to have example plugins.
However, we can have fpb generating template plugin, with commented code in
there. If you uncomment, you a get a comprehensive example of a working
plugin.
To ensure that uncommented code would actually work, we must have a test
for it (which would uncomment - run - ensure everything deploys).

3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest to
think if there is a way to have tests, which would run such examples
against pluggable framework for every change to the framework, so that we
can have -1 right away if something goes wrong.

I've started separate thread on general thoughts about backward
compatibility and multiple releases support, which actually affects
examples: [1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html

Thanks,

On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:

> Because it doesn't make much sense for a plugin developer to have scripts
> to build packages for installation on slave nodes. For default template
> it's better to have something minimalistic and the rest of the tasks
> commented, otherwise it may create a lot of confusion.
>
> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
> wrote:
>
>> Talking about templates I mean plugins generated by FBP from the
>> `templates` folder using command you mentioned above.
>>
>> Why not to extend (not replace) template-generated plugins with
>> additional data to provide right coverage?
>>
>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>>
>>> Ilya,
>>>
>>> What do you mean by "templates" the plugin which is create by just "fpb
>>> --create plugin-name"?
>>> It doesn't cover enough, package installation and all range of tasks
>>> executions.
>>>
>>> Thanks,
>>>
>>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>>> wrote:
>>>
 Igor, i completely agree, actually plugin examples is almost a
 copy-paste.

 The only thing i see useful in the built plugins example is the ability
 to point some code lines, discussing plugin design and writing
 documentation. Why not to generate this examples automatically from
 templates?

 Also, as developer and administrator i love to use examples/templates
 where all essential settings and options are persist but commented (e.g.
 ProFTPD or Apache) and i could uncomment and copy-paste them not being
 afraid of typos. Also it allows to keep documentation actual and head
 documentation small. Duplication of inline documentation between examples
 and templates making things more weird and overshadows idea of inline
 documentation itself.

 Eugeny, why not to run integration tests against plugins generated from
 templates? It's will be even better integration tests.



 On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky >>> > wrote:

> > and really lowering barriers for people who just begin create
> plugins.
>
> Nonsense. First, people usually create them via running `fpb --create
> plugin-name` that generates plugin boilerplate. And that boilerplate
> won't contain that changes.
>
> Second, if people ain't smart enough to change few lines in
> `metadata.yaml` of generated boilerplate to make it work with latest
> Fuel, maybe it's better for them to do not develop plugins at all?
>
> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>  wrote:
> > +1 to maintain example plugins. It is easy enough and really lowering
> > barriers for people who just begin create plugins.
> >
> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> > wrote:
> >>
> >> Igor,
> >>
> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> >> example plugin, add in the current Fuel release, and then build it.
> We
> >> maintained these plugins in the past, but now it should a manual
> step
> >> to test it out on the current release.
> >>
> >> What would be a more ideal situation that meets the needs of users
> and
> >> QA? Right now we have failed tests until we can decide on a solution
> >> that works for everybody.
> >>
> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >> > No, this is a wrong road to go.
> >> >

[openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Mike Scherbakov]

Hi folks,
in order to make a decision whether we need to support example plugins, and
if actually need them [1], I'd suggest to discuss more common things about
plugins.

My thoughts:
1) This is not good, that our plugins created for Fuel 8 won't even install
on Fuel 9. By default, we should assume that plugin will work at newer
version of Fuel. However, for proper user experience, I suggest to create
meta-field "validated_against", where plugin dev would provide versions of
Fuel this plugin has been tested with. Let's say, it was tested against
7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning
saying about risks and the fact that the plugin has not been tested against
9. We should not restrict intsallation against 9, though.

2) We need to keep backward compatibility of pluggable interface for a few
releases. So that plugin developer can use pluggable interface of version
x, which was supported in Fuel 6.1. If we still support it, it would mean
(see next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If
we want to deprecate pluggable interface version, we should announce it,
and basically follow standard process of deprecation.

3) Plugin's ability to work against multiple releases of Fuel
(multi-release support). If if..else clauses to support multiple releases
are fairly minimal, let's say take less that 10% of LOC, I'd suggest to
have this supported. Just because it will be easier for plugin devs to
support their plugin code (no code duplication, single repo for multiple
releases).

Thoughts?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
-- 
Mike Scherbakov
#mihgen
__
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] Fuel CI issues

[Dmitry Borodaenko]

On Wed, Mar 09, 2016 at 10:56:04PM +, Andrew Woodward wrote:
> Issue: moving to puppet-openstack on master has exposed fuel-library
> to breakage and there are many concerns about changes landing that can
> break it.
> 
> Alex S. Proposed that we continue the course, and finish setting up
> Check voting on the relevant puppet-openstack modules - The
> participants agreed with this

Since many people came up with different assumptions about how the CI
duty for Fuel CI for Puppet OpenStack is supposed to work, I've created
a wiki page with a proposed definition of the process:
https://wiki.openstack.org/wiki/Fuel/CI/Puppet_OpenStack_CI_duty

Please read, comment, and add more details as needed.

Please also review and comment on the spec from Igor Belikov:
https://review.openstack.org/286731

> Action: Sergii G & Aleksandra Fedorova will propose needed changes to
> project-config to add tests
> 
> Issue: closing the regressions gap until fuel-ci votes on
> puppet-openstack check
> 
> It was proposed that we invent a system that holds back the versions
> nightly, and after completion of automated testing; It can
> automatically move it forward.
> 
> Action: There was no consensus on this and should be discussed here
> further on this thread.

In the meanwhile, Alex has proposed a fuel-library change that would
record the commit ids of the Puppet OpenStack modules it was built with:
https://review.openstack.org/288768

Merging this would enable us to implement Aleksandra's proposal of using
the versions of Puppet OpenStack modules that have most recently passed
BVT to verify commits to fuel-library and other Fuel components covered
with deploy tests.

-- 
Dmitry Borodaenko

__
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] Fuel CI issues

[Andrew Woodward]

Today we had a sync up call and discussed this. To summarize

Attendees:
Aleksandr Didenko
Alex Schultz
Andrew Woodward
Alexey Shtokolov
Bartek Kupidura
Bogdan Dobrelya
Denis Egorenko
Ivan Berezovskiy
Kyrylo Galanov
Maksim Malchuk
Matthew Mosesohn
Max Yatsenko
Oleg Gelbukh
Oleksiy Molchanov
Petr Zhurba
Sergey Kolekonov
Sergey Vasilenko
Sergii Golovatiuk
Stanislav Makar
Stanislaw Bogatkin
Vladimir Eremin
Vladimir Kuklin

Issue: moving to puppet-openstack on master has exposed fuel-library to
breakage and there are many concerns about changes landing that can break
it.

Alex S. Proposed that we continue the course, and finish setting up Check
voting on the relevant puppet-openstack modules - The participants agreed
with this

Action: Sergii G & Aleksandra Fedorova will propose needed changes to
project-config to add tests

Issue: closing the regressions gap until fuel-ci votes on puppet-openstack
check

It was proposed that we invent a system that holds back the versions
nightly, and after completion of automated testing; It can automatically
move it forward.

Action: There was no consensus on this and should be discussed here further
on this thread.



On Sun, Mar 6, 2016 at 11:33 PM Dmitry Borodaenko 
wrote:

> Aleksandra,
>
> Very good point on separating the concerns about integration tests for
> Fuel as a whole and verifying commits to a single component such as
> fuel-library. In theory, it could support the right balance between
> stable CI and up-to-date code, but only if we resolve the two remaining
> problems: one small and technical and the other large and social.
>
> You've already pointed out the first problem: update of fuel-library CI
> environment is not yet fully automated, and so the environment is liable
> to lag behind all involved components for days if not weeks.
>
> This by itself is simple enough, if labourous, to work around (update it
> manually every day, or after every successful BVT), but still leaves us
> with the problem of motivation.
>
> We've been discussing the CI duty for fuel-library integration with
> puppet-openstack since more than a month ago [0], and it has
> continuously failed to materialize. Within days of getting an action
> item in that IRC meeting to arrange it, Andrew Maksimov has responded
> privately that nobody in his team has time for this. And we all know
> what "I don't have time" actually means [1]. Two weeks later, we were
> ready to launch the integration and the question of CI duty came up
> again [2], with the same result.
>
> [0]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66
> [1]
> http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
> [2]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190
>
> Here we are two more weeks later, the integration is on, and the first
> reaction from fuel-library core reviewers is "we don't have time to deal
> with this, turn it back off right now". And I'm not just summarizing
> Vladimir's email, on Friday we had a long thread on an internal mailing
> list with exactly this in the subject line (my apologies, but my disgust
> at the fact that it was started behind closed doors drowns any qualms
> about dragging it back into the open).
>
> After we change Fuel CI to use fixed, most recent to have passed BVT,
> revisions of puppet-openstack modules, first thing that will happen is
> that BVT on Fuel ISO will start failing again, while fuel-library CI
> will continue to work. Without the pressure of failing commit
> verification CI, fuel-library developers will have even less incentive
> to keep fuel-library up to date with puppet-openstack (not to mention
> pro-actively reviewing puppet-openstack commits to catch potential
> regressions before they happen), and very soon Fuel QA team will get fed
> up with not having a stable ISO for the swarm test, and will demand that
> we go back to using fixed puppet-openstack revisions for the ISO, too.
>
> Both here and on the internal thread, many technical and organizational
> concerns were raised, and I'll get to them in a bit, but a concern
> without the will to resolve it is only an excuse, we won't get far if we
> don't want to make it work.
>
> So why don't fuel-library developers want to spend time on
> puppet-openstack integration?
>
> I see two dimensions to this problem. On one axis, there's the
> cost/benefit balance: how much work does it take, and what do we gain
> from doing it? On the other is the question of who benefits and who
> carries the costs?
>
> Without tracking HEAD of puppet-openstack in fuel-library, the primary
> cost is carried by puppet-openstack developers who maintain the upstream
> modules in the first place, and a small fraction of fuel-library
> contributors (5+ out of 50+ [3][4]) who periodically have to spend
> significant amount of effort to bring fuel-library up to date with the
> current state of puppet-openstack. Even though th

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

[Thomas Goirand]

On 02/29/2016 11:19 AM, Vladimir Kuklin wrote:
> Hi Ivan
> 
> Thanks for bringing this up. Frankly, I think that we hurried a little
> bit by making our integration with upstream puppet manifests too
> continuous. I would suppose that we used a little bit different technique.
> 
> First of all, we need to have a set of stable Fuel commits against which
> the changes to upstream manifests should be tested. Could you please
> elaborate on whether we are doing this already?
> 
> Secondly, we need to have FUEL CI working with a set of stable commits
> of puppet openstack manifests which passed those upstream tests as we
> should not have too much moving parts or we will get into situation
> similar to requirements.txt updates when we have pypi updated with new
> library, e.g. oslo-serialization.
> 
> In this case, we will be able to do proper testing against frozen
> code-base for each piece thus avoiding such issues while retaining fair
> amount of integration with upstream puppet manifests for OpenStack.
> 
> So what do you think?

IMO, what needs to happen, is Fuel to use a packaged version of these
puppet scripts. This has numerous advantages:

- the openstack.yaml repository would also point to the corresponding
puppet stuff

- the version of puppet-openstack would automatically match the one of
the target installation, because it would be stored in the corresponding
packaging repository

- we wouldn't need to hack symlinks in /etc/puppet/modules

- there would be no need to use rsync from the master node to the slave
nodes, as the correct version of fuel-library would be installed in the
IBP image by fuel-agent, making it automatically available

What we shouldn't do though, is loose the continuous testing of upstream
puppet-openstack modules, so we make sure they never break Fuel,
otherwise we would discover issues too late.

FYI, I have just finished uploading all of puppet-openstack Mitaka b1
tag (which in fact corresponds to b3, somehow) to Debian Experimental.
This could be reused by Fuel.

Cheers,

Thomas Goirand (zigo)


__
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][plugins] Should we maintain example plugins?

[Evgeniy L]

Because it doesn't make much sense for a plugin developer to have scripts
to build packages for installation on slave nodes. For default template
it's better to have something minimalistic and the rest of the tasks
commented, otherwise it may create a lot of confusion.

On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov  wrote:

> Talking about templates I mean plugins generated by FBP from the
> `templates` folder using command you mentioned above.
>
> Why not to extend (not replace) template-generated plugins with additional
> data to provide right coverage?
>
> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>
>> Ilya,
>>
>> What do you mean by "templates" the plugin which is create by just "fpb
>> --create plugin-name"?
>> It doesn't cover enough, package installation and all range of tasks
>> executions.
>>
>> Thanks,
>>
>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>> wrote:
>>
>>> Igor, i completely agree, actually plugin examples is almost a
>>> copy-paste.
>>>
>>> The only thing i see useful in the built plugins example is the ability
>>> to point some code lines, discussing plugin design and writing
>>> documentation. Why not to generate this examples automatically from
>>> templates?
>>>
>>> Also, as developer and administrator i love to use examples/templates
>>> where all essential settings and options are persist but commented (e.g.
>>> ProFTPD or Apache) and i could uncomment and copy-paste them not being
>>> afraid of typos. Also it allows to keep documentation actual and head
>>> documentation small. Duplication of inline documentation between examples
>>> and templates making things more weird and overshadows idea of inline
>>> documentation itself.
>>>
>>> Eugeny, why not to run integration tests against plugins generated from
>>> templates? It's will be even better integration tests.
>>>
>>>
>>>
>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
>>> wrote:
>>>
 > and really lowering barriers for people who just begin create plugins.

 Nonsense. First, people usually create them via running `fpb --create
 plugin-name` that generates plugin boilerplate. And that boilerplate
 won't contain that changes.

 Second, if people ain't smart enough to change few lines in
 `metadata.yaml` of generated boilerplate to make it work with latest
 Fuel, maybe it's better for them to do not develop plugins at all?

 On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
  wrote:
 > +1 to maintain example plugins. It is easy enough and really lowering
 > barriers for people who just begin create plugins.
 >
 > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
 mmoses...@mirantis.com>
 > wrote:
 >>
 >> Igor,
 >>
 >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
 >> example plugin, add in the current Fuel release, and then build it.
 We
 >> maintained these plugins in the past, but now it should a manual step
 >> to test it out on the current release.
 >>
 >> What would be a more ideal situation that meets the needs of users
 and
 >> QA? Right now we have failed tests until we can decide on a solution
 >> that works for everybody.
 >>
 >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
 ikalnit...@mirantis.com>
 >> wrote:
 >> > No, this is a wrong road to go.
 >> >
 >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
 >> > Remove v1 example from source tree? That doesn't seem good to me.
 >> >
 >> > Example plugins are only examples. The list of supported releases
 must
 >> > be maintained on system test side, and system tests must inject
 that
 >> > information into plugin's metadata.yaml and test it.
 >> >
 >> > Again, I don't say we shouldn't test plugins. I say, tests should
 be
 >> > responsible for preparing plugins. I can say even more: tests
 should
 >> > not rely on what is produced by plugins, since it's something that
 >> > could be changed and tests start failing.
 >> >
 >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
 scroi...@mirantis.com>
 >> > wrote:
 >> >> IMHO it is important to keep plugin examples and keep testing
 them,
 >> >> very
 >> >> valuable for plugin developers.
 >> >>
 >> >> For example, I've encountered [0] the case where "plugin as role"
 >> >> feature
 >> >> wasn't easily testable with fuel-qa because not compliant with
 the last
 >> >> plugin data structure,
 >> >> and more recently we've spotted a regression [1] with
 "vip-reservation"
 >> >> feature introduced by a change in nailgun.
 >> >> These kind of issues are time consuming for plugin developers and
 >> >> can/must
 >> >> be avoided by testing them.
 >> >>
 >> >> I don't even understand why the question is raised while fuel
 plugins
 >> >> are
 >> >> supposed to be suppo

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

Talking about templates I mean plugins generated by FBP from the
`templates` folder using command you mentioned above.

Why not to extend (not replace) template-generated plugins with additional
data to provide right coverage?

On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:

> Ilya,
>
> What do you mean by "templates" the plugin which is create by just "fpb
> --create plugin-name"?
> It doesn't cover enough, package installation and all range of tasks
> executions.
>
> Thanks,
>
> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
> wrote:
>
>> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>>
>> The only thing i see useful in the built plugins example is the ability
>> to point some code lines, discussing plugin design and writing
>> documentation. Why not to generate this examples automatically from
>> templates?
>>
>> Also, as developer and administrator i love to use examples/templates
>> where all essential settings and options are persist but commented (e.g.
>> ProFTPD or Apache) and i could uncomment and copy-paste them not being
>> afraid of typos. Also it allows to keep documentation actual and head
>> documentation small. Duplication of inline documentation between examples
>> and templates making things more weird and overshadows idea of inline
>> documentation itself.
>>
>> Eugeny, why not to run integration tests against plugins generated from
>> templates? It's will be even better integration tests.
>>
>>
>>
>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
>> wrote:
>>
>>> > and really lowering barriers for people who just begin create plugins.
>>>
>>> Nonsense. First, people usually create them via running `fpb --create
>>> plugin-name` that generates plugin boilerplate. And that boilerplate
>>> won't contain that changes.
>>>
>>> Second, if people ain't smart enough to change few lines in
>>> `metadata.yaml` of generated boilerplate to make it work with latest
>>> Fuel, maybe it's better for them to do not develop plugins at all?
>>>
>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>>  wrote:
>>> > +1 to maintain example plugins. It is easy enough and really lowering
>>> > barriers for people who just begin create plugins.
>>> >
>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>>> mmoses...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> Igor,
>>> >>
>>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>>> >> example plugin, add in the current Fuel release, and then build it. We
>>> >> maintained these plugins in the past, but now it should a manual step
>>> >> to test it out on the current release.
>>> >>
>>> >> What would be a more ideal situation that meets the needs of users and
>>> >> QA? Right now we have failed tests until we can decide on a solution
>>> >> that works for everybody.
>>> >>
>>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com>
>>> >> wrote:
>>> >> > No, this is a wrong road to go.
>>> >> >
>>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>>> >> >
>>> >> > Example plugins are only examples. The list of supported releases
>>> must
>>> >> > be maintained on system test side, and system tests must inject that
>>> >> > information into plugin's metadata.yaml and test it.
>>> >> >
>>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>>> >> > responsible for preparing plugins. I can say even more: tests should
>>> >> > not rely on what is produced by plugins, since it's something that
>>> >> > could be changed and tests start failing.
>>> >> >
>>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
>>> scroi...@mirantis.com>
>>> >> > wrote:
>>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>>> >> >> very
>>> >> >> valuable for plugin developers.
>>> >> >>
>>> >> >> For example, I've encountered [0] the case where "plugin as role"
>>> >> >> feature
>>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>>> last
>>> >> >> plugin data structure,
>>> >> >> and more recently we've spotted a regression [1] with
>>> "vip-reservation"
>>> >> >> feature introduced by a change in nailgun.
>>> >> >> These kind of issues are time consuming for plugin developers and
>>> >> >> can/must
>>> >> >> be avoided by testing them.
>>> >> >>
>>> >> >> I don't even understand why the question is raised while fuel
>>> plugins
>>> >> >> are
>>> >> >> supposed to be supported and more and more used [3], even by
>>> murano [4]
>>> >> >> ...
>>> >> >>
>>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>>> >> >> [3]
>>> >> >>
>>> >> >>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>>> >> >> [4] https://review.openstack.org/#/c/286310/
>>> >> >>
>>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>>> >> >> 
>>> >> >> wrote:
>>> >> >>>
>>

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

r/is almost a copy-paste/is almost a copy-paste from plugins templates

On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov  wrote:

> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>
> The only thing i see useful in the built plugins example is the ability to
> point some code lines, discussing plugin design and writing documentation.
> Why not to generate this examples automatically from templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
> wrote:
>
>> > and really lowering barriers for people who just begin create plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>> mmoses...@mirantis.com>
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it. We
>> >> maintained these plugins in the past, but now it should a manual step
>> >> to test it out on the current release.
>> >>
>> >> What would be a more ideal situation that meets the needs of users and
>> >> QA? Right now we have failed tests until we can decide on a solution
>> >> that works for everybody.
>> >>
>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >> > No, this is a wrong road to go.
>> >> >
>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>> >> >
>> >> > Example plugins are only examples. The list of supported releases
>> must
>> >> > be maintained on system test side, and system tests must inject that
>> >> > information into plugin's metadata.yaml and test it.
>> >> >
>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> >> > responsible for preparing plugins. I can say even more: tests should
>> >> > not rely on what is produced by plugins, since it's something that
>> >> > could be changed and tests start failing.
>> >> >
>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset > >
>> >> > wrote:
>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> >> very
>> >> >> valuable for plugin developers.
>> >> >>
>> >> >> For example, I've encountered [0] the case where "plugin as role"
>> >> >> feature
>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>> last
>> >> >> plugin data structure,
>> >> >> and more recently we've spotted a regression [1] with
>> "vip-reservation"
>> >> >> feature introduced by a change in nailgun.
>> >> >> These kind of issues are time consuming for plugin developers and
>> >> >> can/must
>> >> >> be avoided by testing them.
>> >> >>
>> >> >> I don't even understand why the question is raised while fuel
>> plugins
>> >> >> are
>> >> >> supposed to be supported and more and more used [3], even by murano
>> [4]
>> >> >> ...
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> >> [3]
>> >> >>
>> >> >>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> >> [4] https://review.openstack.org/#/c/286310/
>> >> >>
>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Fuelers,
>> >> >>>
>> >> >>> I would like to bring your attention a dilemma we have here. It
>> seems
>> >> >>> that there is a dispute as to whether we should maintain the
>> releases
>> >> >>> list for example plugins[0]. In this case, this is for adding
>> version
>> >> >>> 9.0 to the list.
>> >> >>>
>> >> >>> Right now, we run a swarm test that tries to install the example
>> >> >>> plugin and do a deployment, but it's failing only for this reason.
>> I
>> >> >>> should add that this is the only automated daily test that will
>> verif

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Evgeniy L]

Ilya,

What do you mean by "templates" the plugin which is create by just "fpb
--create plugin-name"?
It doesn't cover enough, package installation and all range of tasks
executions.

Thanks,

On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov  wrote:

> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>
> The only thing i see useful in the built plugins example is the ability to
> point some code lines, discussing plugin design and writing documentation.
> Why not to generate this examples automatically from templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
> wrote:
>
>> > and really lowering barriers for people who just begin create plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>> mmoses...@mirantis.com>
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it. We
>> >> maintained these plugins in the past, but now it should a manual step
>> >> to test it out on the current release.
>> >>
>> >> What would be a more ideal situation that meets the needs of users and
>> >> QA? Right now we have failed tests until we can decide on a solution
>> >> that works for everybody.
>> >>
>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >> > No, this is a wrong road to go.
>> >> >
>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>> >> >
>> >> > Example plugins are only examples. The list of supported releases
>> must
>> >> > be maintained on system test side, and system tests must inject that
>> >> > information into plugin's metadata.yaml and test it.
>> >> >
>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> >> > responsible for preparing plugins. I can say even more: tests should
>> >> > not rely on what is produced by plugins, since it's something that
>> >> > could be changed and tests start failing.
>> >> >
>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset > >
>> >> > wrote:
>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> >> very
>> >> >> valuable for plugin developers.
>> >> >>
>> >> >> For example, I've encountered [0] the case where "plugin as role"
>> >> >> feature
>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>> last
>> >> >> plugin data structure,
>> >> >> and more recently we've spotted a regression [1] with
>> "vip-reservation"
>> >> >> feature introduced by a change in nailgun.
>> >> >> These kind of issues are time consuming for plugin developers and
>> >> >> can/must
>> >> >> be avoided by testing them.
>> >> >>
>> >> >> I don't even understand why the question is raised while fuel
>> plugins
>> >> >> are
>> >> >> supposed to be supported and more and more used [3], even by murano
>> [4]
>> >> >> ...
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> >> [3]
>> >> >>
>> >> >>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> >> [4] https://review.openstack.org/#/c/286310/
>> >> >>
>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Fuelers,
>> >> >>>
>> >> >>> I would like to bring your attention a dilemma we have here. It
>> seems
>> >> >>> that there is a dispute as to whether we should maintain the
>> releases
>> >> >>> list for example plugins[0]. In this case, this is for adding
>> version
>> >> >>> 9.0 to the list.
>> >> >>>
>> >> >>> Right now, we run a swarm test that tries to install the example
>> >> >>> plugin and do a deployment, but i

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

Igor, i completely agree, actually plugin examples is almost a copy-paste.

The only thing i see useful in the built plugins example is the ability to
point some code lines, discussing plugin design and writing documentation.
Why not to generate this examples automatically from templates?

Also, as developer and administrator i love to use examples/templates where
all essential settings and options are persist but commented (e.g. ProFTPD
or Apache) and i could uncomment and copy-paste them not being afraid of
typos. Also it allows to keep documentation actual and head documentation
small. Duplication of inline documentation between examples and templates
making things more weird and overshadows idea of inline documentation
itself.

Eugeny, why not to run integration tests against plugins generated from
templates? It's will be even better integration tests.



On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
wrote:

> > and really lowering barriers for people who just begin create plugins.
>
> Nonsense. First, people usually create them via running `fpb --create
> plugin-name` that generates plugin boilerplate. And that boilerplate
> won't contain that changes.
>
> Second, if people ain't smart enough to change few lines in
> `metadata.yaml` of generated boilerplate to make it work with latest
> Fuel, maybe it's better for them to do not develop plugins at all?
>
> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>  wrote:
> > +1 to maintain example plugins. It is easy enough and really lowering
> > barriers for people who just begin create plugins.
> >
> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn  >
> > wrote:
> >>
> >> Igor,
> >>
> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> >> example plugin, add in the current Fuel release, and then build it. We
> >> maintained these plugins in the past, but now it should a manual step
> >> to test it out on the current release.
> >>
> >> What would be a more ideal situation that meets the needs of users and
> >> QA? Right now we have failed tests until we can decide on a solution
> >> that works for everybody.
> >>
> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky  >
> >> wrote:
> >> > No, this is a wrong road to go.
> >> >
> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
> >> > Remove v1 example from source tree? That doesn't seem good to me.
> >> >
> >> > Example plugins are only examples. The list of supported releases must
> >> > be maintained on system test side, and system tests must inject that
> >> > information into plugin's metadata.yaml and test it.
> >> >
> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
> >> > responsible for preparing plugins. I can say even more: tests should
> >> > not rely on what is produced by plugins, since it's something that
> >> > could be changed and tests start failing.
> >> >
> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
> >> > wrote:
> >> >> IMHO it is important to keep plugin examples and keep testing them,
> >> >> very
> >> >> valuable for plugin developers.
> >> >>
> >> >> For example, I've encountered [0] the case where "plugin as role"
> >> >> feature
> >> >> wasn't easily testable with fuel-qa because not compliant with the
> last
> >> >> plugin data structure,
> >> >> and more recently we've spotted a regression [1] with
> "vip-reservation"
> >> >> feature introduced by a change in nailgun.
> >> >> These kind of issues are time consuming for plugin developers and
> >> >> can/must
> >> >> be avoided by testing them.
> >> >>
> >> >> I don't even understand why the question is raised while fuel plugins
> >> >> are
> >> >> supposed to be supported and more and more used [3], even by murano
> [4]
> >> >> ...
> >> >>
> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> >> [3]
> >> >>
> >> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> >> [4] https://review.openstack.org/#/c/286310/
> >> >>
> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> Hi Fuelers,
> >> >>>
> >> >>> I would like to bring your attention a dilemma we have here. It
> seems
> >> >>> that there is a dispute as to whether we should maintain the
> releases
> >> >>> list for example plugins[0]. In this case, this is for adding
> version
> >> >>> 9.0 to the list.
> >> >>>
> >> >>> Right now, we run a swarm test that tries to install the example
> >> >>> plugin and do a deployment, but it's failing only for this reason. I
> >> >>> should add that this is the only automated daily test that will
> verify
> >> >>> that our plugin framework actually works. During the Mitaka
> >> >>> development  cycle, we already had an extended period where plugins
> >> >>> were broken[1]. Removing this test (or leaving it permanently red,
> >> >>> which is effectively the same), would raise the risk to any member
> of
> >> >>> the Fuel 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksandr Didenko]

Guys,

I suppose that any solution for the plugins merge ordering issue (either
alerting about error or allowing user to manually set order) would be very
helpful and much better then no solution at all (like we currently have).
Maybe we should create a blueprint to not miss/forget about it?

Regards,
Alex

On Mon, Feb 1, 2016 at 6:10 PM, Roman Prykhodchenko  wrote:

> This is basically why I proposed to allow users to set per cluster
> priority for every enabled plugin. That would allow users to select results
> they need. Putting too many logic into checks whether two plugins are
> incompatible is error-prone and won’t stop anyone from shooting their feet.
>
>
> > 29 січ. 2016 р. о 16:10 Igor Kalnitsky 
> написав(ла):
> >
> > Roman P. wrote:
> >> Putting extra checks will create a more fool-proof but less configurable
> >> software. I’d vote for letting users shoot their feet using their
> plugins
> >> but making Fuel more flexible.
> >
> > I won't agree here. You see, what if two plugins wants to override the
> > core network role? Consider that plugin A wants to extend VIPs:
> >
> >id: "mgmt/vip"
> >default_mapping: "management"
> >properties:
> >  vip:
> >- name: "management"
> >  namespace: "haproxy"
> ># new VIP we want to add
> >- name: "myvip"
> >  namespace: "haproxy"
> >
> > while plugin B wants to remove them:
> >
> >id: "mgmt/vip"
> >default_mapping: "management"
> >properties:
> >  vip: []
> >
> > How do you suppose to resolve this action? We don't know in which
> > order they will be resolved, and I'm strongly against unpredictable
> > situation (especiall it may be different time-to-time and depends on
> > which order plugins will be selected).
> >
> > Moreover, it makes a little sense to try to resolve this situation. If
> > two plugins change something in core, they are probably incompatible.
> > Manual actions are required.
> >
> > So that's, basically, why I think we should warn user about
> > incompatible changes to core stuff. Just like we do for deployment
> > tasks.
> >
> > - igor
> >
> > On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko 
> wrote:
> >> I would not check that. We are not talking about installing browser
> plugins
> >> when users may not know what they want. Putting extra checks will
> create a
> >> more fool-proof but less configurable software. I’d vote for letting
> users
> >> shoot their feet using their plugins but making Fuel more flexible.
> >>
> >>
> >> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
> >> написав(ла):
> >>
> >>> jsonpatch
> >>
> >> There were +1's regarding overriding VIPs above. I'd stick with that.
> It is
> >> done for tasks now. But we will need to check conflicts between plugins
> >> there (as for tasks).
> >>
> >>
> >> Aleksey Kasatkin
> >>
> >>
> >> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko 
> wrote:
> >>>
> >>> Frankly, I have not though about how to deal with multiple plugins yet.
> >>> However, what I think is that we must not restrict this too much and
> let
> >>> users configure it more flexibly even if it allows to shoot one’s foot.
> >>> Perhaps we can add a per-cluster priority for enabled plugins which
> users
> >>> can configure via UI, CLI or API. My other thought is that we should
> not
> >>> invent our own mechanics for changing a configuration and use an
> existing
> >>> one, say, jsonpatch. What do you guys think?
> >>>
> >>> P. S. [0] is really needed for 8.0 for implementing an important epic,
> so
> >>> please check it out. If it does not break anything, lets merge it ASAP.
> >>>
> >>> - romcheg
> >>>
> >>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
> >>> написав(ла):
> >>>
> >>> AFAIC, it is better to remove by name then. Otherwise, you do not know
> >>> what VIPs you are removing.
> >>> Another option - remove "built-in" VIPs using some specific expression.
> >>> Anyway, you do not know where other VIPs (VIPs of other plugins) live
> so
> >>> you cannot remove them this way.
> >>>
> >>> And the order of plugins processing is not defined so there is no
> warranty
> >>> you will remove all VIPs on those network roles.
> >>> Seems, checking for such conflict between plugins is needed.
> >>>
> >>> The original goal, actually, was to remove VIPs for controllers (or for
> >>> some particular node role, maybe),
> >>> so we should maybe find a way to do exactly this.
> >>>
> >>>
> >>>
> >>> Aleksey Kasatkin
> >>>
> >>>
> >>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko <
> adide...@mirantis.com>
> >>> wrote:
> 
> > How are we handling this now for multiple plugins?
> 
>  OK, so right now we can only add VIPs to array, we can't remove them.
> So
>  overriding would disable such possibility of adding VIPs from
> different
>  plugins. But with [0] patch it will be still possible to add and to
> remove
>  by providing empty array. But we'll have the problem with multiple
> plugins
>  in such case.
>  I've chan

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Evgeniy L]

Hi,

Plugin examples mustn't be removed, those plugins are part of integration
tests for fuel plugin builder, which should be able to build any version of
plugin.

So there are two ways to solve the problem:
1. Before test run update compatibility matrix for plugins automatically.
2. Continue fixing plugin examples.

We may try to do 2nd automatically (proposing a patch with fixed version)
on version change in openstack.yaml.

Thanks,

On Tue, Mar 8, 2016 at 3:50 PM, Anastasia Urlapova 
wrote:

> Igor,
> I agree with folks, that we have to fix plugin. You didn't mention any
> real reasons, why we should change workflow with example-plugin right now
> in the middle of release. If we are keeping support of the example plugin
> in 9.0 it should work from box w/o any black magic in other places.
>
>
> Nastya.
>
> On Mon, Mar 7, 2016 at 6:33 PM, Simon Pasquier 
> wrote:
>
>> Yet another example [1] of why a dummy/example plugin should be
>> integrated in the Fuel CI process: the current version of Fuel is broken
>> for (almost) all plugins since a week at least and no one noticed.
>> Regards,
>> Simon
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1554095
>>
>> On Mon, Mar 7, 2016 at 3:16 PM, Simon Pasquier 
>> wrote:
>>
>>> What about maintaining a dummy plugin (eg running only one or two very
>>> simple tasks) as a standalone project for the purpose of QA?
>>> IMO it would make more sense than having those example plugins in the
>>> fuel-plugins project...
>>> Regards,
>>> Simon
>>>
>>> On Mon, Mar 7, 2016 at 2:49 PM, Igor Kalnitsky 
>>> wrote:
>>>
 > and really lowering barriers for people who just begin create plugins.

 Nonsense. First, people usually create them via running `fpb --create
 plugin-name` that generates plugin boilerplate. And that boilerplate
 won't contain that changes.

 Second, if people ain't smart enough to change few lines in
 `metadata.yaml` of generated boilerplate to make it work with latest
 Fuel, maybe it's better for them to do not develop plugins at all?

 On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
  wrote:
 > +1 to maintain example plugins. It is easy enough and really lowering
 > barriers for people who just begin create plugins.
 >
 > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
 mmoses...@mirantis.com>
 > wrote:
 >>
 >> Igor,
 >>
 >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
 >> example plugin, add in the current Fuel release, and then build it.
 We
 >> maintained these plugins in the past, but now it should a manual step
 >> to test it out on the current release.
 >>
 >> What would be a more ideal situation that meets the needs of users
 and
 >> QA? Right now we have failed tests until we can decide on a solution
 >> that works for everybody.
 >>
 >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
 ikalnit...@mirantis.com>
 >> wrote:
 >> > No, this is a wrong road to go.
 >> >
 >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
 >> > Remove v1 example from source tree? That doesn't seem good to me.
 >> >
 >> > Example plugins are only examples. The list of supported releases
 must
 >> > be maintained on system test side, and system tests must inject
 that
 >> > information into plugin's metadata.yaml and test it.
 >> >
 >> > Again, I don't say we shouldn't test plugins. I say, tests should
 be
 >> > responsible for preparing plugins. I can say even more: tests
 should
 >> > not rely on what is produced by plugins, since it's something that
 >> > could be changed and tests start failing.
 >> >
 >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
 scroi...@mirantis.com>
 >> > wrote:
 >> >> IMHO it is important to keep plugin examples and keep testing
 them,
 >> >> very
 >> >> valuable for plugin developers.
 >> >>
 >> >> For example, I've encountered [0] the case where "plugin as role"
 >> >> feature
 >> >> wasn't easily testable with fuel-qa because not compliant with
 the last
 >> >> plugin data structure,
 >> >> and more recently we've spotted a regression [1] with
 "vip-reservation"
 >> >> feature introduced by a change in nailgun.
 >> >> These kind of issues are time consuming for plugin developers and
 >> >> can/must
 >> >> be avoided by testing them.
 >> >>
 >> >> I don't even understand why the question is raised while fuel
 plugins
 >> >> are
 >> >> supposed to be supported and more and more used [3], even by
 murano [4]
 >> >> ...
 >> >>
 >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
 >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
 >> >> [3]
 >> >>
 >> >>
 http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
 >> >> [4] http

[openstack-dev] [Fuel] [Openstack] Instalation Problem: Inside VM "fuel-master"

[Samer Machara]

Hi, 
 I already have VirtualBox 5.0; I run the script again, and now everything is 
working well.
 I finish the setup. Hurrah! finally, I'm going to work.

Thanks

--

Message: 15
Date: Wed, 9 Mar 2016 11:16:33 +0100 (CET)
From: Samer Machara 
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: [openstack-dev] [Fuel] [Openstack] Instalation Problem:
Inside VM "fuel-master"
Message-ID:
<56040978.58779783.1457518593738.javamail.zim...@telecom-sudparis.eu>
Content-Type: text/plain; charset="utf-8"

Hello, 
Someone can tell me what is this problem about? And how to solve it? 
Thanks. 
Samer Machara 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 
config.sh 
# Section for custom configuration 
vm_slave_memory_default=512 
vm_slave_memory_mb[1]=512 
vm_slave_memory_mb[2]=512 
vm_slave_memory_mb[3]=512 


- Original Message -

From: "Igor Marnat"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Friday, March 4, 2016 3:12:21 PM 
Subject: Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: 
error: Guest not running [ubuntu14.04] 

Samer, Maksim, 
I'd rather say that script started fuel-master already (VM "fuel-master" has 
been successfully started.), didn't find running guests, (VBoxManage: error: 
Guest not running) but it can try to start them afterwards. 

Samer, 
- how many VMs are there running besides fuel-master? 
- is it still showing "Waiting for product VM to download files. Please do NOT 
abort the script..." ? 
- for how long did you wait since the message above? 


Regards, 
Igor Marnat 

On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com > wrote: 



Hi Sames, 

VBoxManage: error: Guest not running 

looks line the problem with VirtualBox itself or settings for the 'fuel-master' 
VM, it can't boot it. 
Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it 
manually - it should show you what is exactly happens. 


On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < 
samer.mach...@telecom-sudparis.eu > wrote: 





Hello, everyone. 
I'm new with Fuel. I'm trying to follow the QuickStart Guide ( 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), 
but I have the following Error: 


Waiting for VM "fuel-master" to power on... 
VM "fuel-master" has been successfully started. 
VBoxManage: error: Guest not running 
VBoxManage: error: Guest not running 
... 
VBoxManage: error: Guest not running 
Waiting for product VM to download files. Please do NOT abort the script... 


I hope you can help me. 

Thanks in advance 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel? Core?2 Quad CPU Q9550 @ 2.83GHz ? 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 





I modify the config.sh to adapt my hardware configuration 
... 
# Master node settings 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_master_memory_mb=1024 
vm_master_disk_mb=2 
... 
# The number of nodes for installing OpenStack on 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
cluster_size=3 
... 
# Slave node settings. This section allows you to define CPU count for each 
slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_cpu_default=1 
vm_slave_cpu[1]=1 
vm_slave_cpu[2]=1 
vm_slave_cpu[3]=1 
... 
# This section allows you to define RAM size in MB for each slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_memory_default=1024 


vm_slave_memory_mb[1]=512 
vm_slave_memory_mb[2]=512 
vm_slave_memory_mb[3]=512 
... 
# Nodes with combined roles may require more disk space. 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_first_disk_mb=2 
vm_slave_second_disk_mb=2 
vm_slave_third_disk_mb=2 
... 


I found someone that had a similar problem ( 
https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html ), he 
had a corrupted iso file, he solved the problem downloaded it again. I 
downloaded the .iso file from 
http://seed.fuel-infr

Re: [openstack-dev] [Fuel] Disable observing modifications of nested fields for MutableDict and MutableList

[Bulat Gaifullin]

Fuelers, please notice that the patch [1]  changes behaviour of MutableDict and 
MutableList.
observing of changes in nested objects has been disabled, because it is not 
trivial to handle this case properly.
It is much easier to notify about changes in nester fields  explicitly when it 
is needed.
Example:

# instance.roles_metadata is instance of MutableDict.
instance.roles_metadata[role['name']] = role['meta']
instance.volumes_metadata['volumes_roles_mapping'][role['name']] = 
role.get('volumes_roles_mapping', [])
# notify about changes
instance.volumes_metadata.changed()

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

PS:
  Added missing link

Regards,
Bulat Gaifullin
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

[openstack-dev] [Fuel] Disable observing modifications of nested fields for MutableDict and MutableList

[Bulat Gaifullin]

Fuelers, please notice that the patch [1]  changes behaviour of MutableDict and 
MutableList.
observing of changes in nested objects has been disabled, because it is not 
trivial to handle this case properly.
It is much easier to notify about changes in nester fields  explicitly when it 
is needed.
Example:

# instance.roles_metadata is instance of MutableDict.
instance.roles_metadata[role['name']] = role['meta']
instance.volumes_metadata['volumes_roles_mapping'][role['name']] = 
role.get('volumes_roles_mapping', [])
# notify about changes
instance.volumes_metadata.changed()


Regards,
Bulat Gaifullin
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

Re: [openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Sergii Golovatiuk]

+1

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Wed, Mar 9, 2016 at 8:07 AM, Bulat Gaifullin 
wrote:

> +1
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 03 Mar 2016, at 17:03, Dmitry Klenov  wrote:
>
> Maksim, good job! +1 from my side though I am not a core.
>
> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev <
> azvyagint...@mirantis.com> wrote:
>
>> +1
>>
>> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko > > wrote:
>>
>>> +1
>>>
>>> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov 
>>> wrote:
>>>
 +1

 On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov 
 wrote:

> +1
>
> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov 
> wrote:
>
>> Hey Fuelers,
>>
>> Since we've successfully moved [1] virtual-box scripts from fuel-main
>> [2] to
>> separate fuel-virtualbox [3] git repo, I propose to update
>> fuel-virtualbox-core
>> team [4] by adding Maksim Malchuk. Maksim is the main contributor to
>> these
>> scripts during Mitaka release cycle [5]
>>
>> Fuel Cores, please vote.
>>
>> [1].
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
>> [2]. https://github.com/openstack/fuel-main
>> [3]. https://github.com/openstack/fuel-virtualbox
>> [4]. https://review.openstack.org/#/admin/groups/1299,members
>> [5]. https://github.com/openstack/fuel-virtualbox/commits/master
>>
>> --
>> Sergey
>> DevOps Engineer
>> IRC: SergK
>> Skype: Sergey_kul
>>
>>
>> __
>> 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


>>>
>>>
>>> __
>>> 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,
>>Aleksey Zvyagintsev
>>
>> __
>> 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
>
>
__
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] UI code freeze

[Evgeniy L]

Hi,

Thank you for your work, really happy to see it done. So as far as I can
see from now on in fuel-web repository we have only Nailgun project. Is it
correct?

On Fri, Feb 26, 2016 at 3:53 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> We are ready for moving UI javascript code to a separate git repository.
> Since now all review requests for fuel-web@master that are related to UI
> must be marked -2 and later abandoned. Once new project fuel-ui is created
> those changes should be backported to this new repository.
>
> Checklist:
>
>
>- Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
>- openstack-infra
>   - project-config https://review.openstack.org/#/c/260455 (ON REVIEW)
>   - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
>- fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
>- label jenkins slaves for the new job (ci team)
>- UI directory freeze (DONE)
>- prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
>- waiting for openstack-infra patches to be merged
>- .gitreview .gitignore MAINTAINERS (TODO)
>- rpm spec (TODO)
>- custom ci jobs (TODO)
>- fuel-main (TODO)
>- packaging ci (TODO)
>- remove old files (TODO)
>
>
> Vladimir Kozhukalov
>
> __
> 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] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Bulat Gaifullin]

+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 03 Mar 2016, at 17:03, Dmitry Klenov  wrote:
> 
> Maksim, good job! +1 from my side though I am not a core.
> 
> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev 
> mailto:azvyagint...@mirantis.com>> wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko  > wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov  > wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov  > wrote:
> +1
> 
> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov  > wrote:
> Hey Fuelers,
> 
> Since we've successfully moved [1] virtual-box scripts from fuel-main [2] to
> separate fuel-virtualbox [3] git repo, I propose to update 
> fuel-virtualbox-core
> team [4] by adding Maksim Malchuk. Maksim is the main contributor to these
> scripts during Mitaka release cycle [5]
> 
> Fuel Cores, please vote.
> 
> [1]. 
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html 
> 
> [2]. https://github.com/openstack/fuel-main 
> 
> [3]. https://github.com/openstack/fuel-virtualbox 
> 
> [4]. https://review.openstack.org/#/admin/groups/1299,members 
> 
> [5]. https://github.com/openstack/fuel-virtualbox/commits/master 
> 
> 
> -- 
> Sergey
> DevOps Engineer 
> IRC: SergK
> Skype: Sergey_kul
> 
> __
> 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 
> 
> 
> 
> 
> __
> 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,
>Aleksey Zvyagintsev
> 
> __
> 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

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Anastasia Urlapova]

Igor,
I agree with folks, that we have to fix plugin. You didn't mention any real
reasons, why we should change workflow with example-plugin right now in the
middle of release. If we are keeping support of the example plugin in 9.0
it should work from box w/o any black magic in other places.


Nastya.

On Mon, Mar 7, 2016 at 6:33 PM, Simon Pasquier 
wrote:

> Yet another example [1] of why a dummy/example plugin should be integrated
> in the Fuel CI process: the current version of Fuel is broken for (almost)
> all plugins since a week at least and no one noticed.
> Regards,
> Simon
>
> [1] https://bugs.launchpad.net/fuel/+bug/1554095
>
> On Mon, Mar 7, 2016 at 3:16 PM, Simon Pasquier 
> wrote:
>
>> What about maintaining a dummy plugin (eg running only one or two very
>> simple tasks) as a standalone project for the purpose of QA?
>> IMO it would make more sense than having those example plugins in the
>> fuel-plugins project...
>> Regards,
>> Simon
>>
>> On Mon, Mar 7, 2016 at 2:49 PM, Igor Kalnitsky 
>> wrote:
>>
>>> > and really lowering barriers for people who just begin create plugins.
>>>
>>> Nonsense. First, people usually create them via running `fpb --create
>>> plugin-name` that generates plugin boilerplate. And that boilerplate
>>> won't contain that changes.
>>>
>>> Second, if people ain't smart enough to change few lines in
>>> `metadata.yaml` of generated boilerplate to make it work with latest
>>> Fuel, maybe it's better for them to do not develop plugins at all?
>>>
>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>>  wrote:
>>> > +1 to maintain example plugins. It is easy enough and really lowering
>>> > barriers for people who just begin create plugins.
>>> >
>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>>> mmoses...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> Igor,
>>> >>
>>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>>> >> example plugin, add in the current Fuel release, and then build it. We
>>> >> maintained these plugins in the past, but now it should a manual step
>>> >> to test it out on the current release.
>>> >>
>>> >> What would be a more ideal situation that meets the needs of users and
>>> >> QA? Right now we have failed tests until we can decide on a solution
>>> >> that works for everybody.
>>> >>
>>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com>
>>> >> wrote:
>>> >> > No, this is a wrong road to go.
>>> >> >
>>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>>> >> >
>>> >> > Example plugins are only examples. The list of supported releases
>>> must
>>> >> > be maintained on system test side, and system tests must inject that
>>> >> > information into plugin's metadata.yaml and test it.
>>> >> >
>>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>>> >> > responsible for preparing plugins. I can say even more: tests should
>>> >> > not rely on what is produced by plugins, since it's something that
>>> >> > could be changed and tests start failing.
>>> >> >
>>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
>>> scroi...@mirantis.com>
>>> >> > wrote:
>>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>>> >> >> very
>>> >> >> valuable for plugin developers.
>>> >> >>
>>> >> >> For example, I've encountered [0] the case where "plugin as role"
>>> >> >> feature
>>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>>> last
>>> >> >> plugin data structure,
>>> >> >> and more recently we've spotted a regression [1] with
>>> "vip-reservation"
>>> >> >> feature introduced by a change in nailgun.
>>> >> >> These kind of issues are time consuming for plugin developers and
>>> >> >> can/must
>>> >> >> be avoided by testing them.
>>> >> >>
>>> >> >> I don't even understand why the question is raised while fuel
>>> plugins
>>> >> >> are
>>> >> >> supposed to be supported and more and more used [3], even by
>>> murano [4]
>>> >> >> ...
>>> >> >>
>>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>>> >> >> [3]
>>> >> >>
>>> >> >>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>>> >> >> [4] https://review.openstack.org/#/c/286310/
>>> >> >>
>>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>>> >> >> 
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Hi Fuelers,
>>> >> >>>
>>> >> >>> I would like to bring your attention a dilemma we have here. It
>>> seems
>>> >> >>> that there is a dispute as to whether we should maintain the
>>> releases
>>> >> >>> list for example plugins[0]. In this case, this is for adding
>>> version
>>> >> >>> 9.0 to the list.
>>> >> >>>
>>> >> >>> Right now, we run a swarm test that tries to install the example
>>> >> >>> plugin and do a deployment, but it's failing only for this
>>> reason. I
>>> >> >>> should a

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Maksim Malchuk]

Guys,

Samer has shown error messages... two lines:

*VM "fuel-master" has been successfully started.*
*VBoxManage: error: Guest not running*

which exactly means that first command "VBoxManage startvm" has
successfully executed but next one "VBoxManage " failed due to error.
Which means the problem with the VM itself. Need to execute Manager (GUI),
start VM manually and look at the error.


On Mon, Mar 7, 2016 at 6:48 PM, Aleksey Zvyagintsev <
azvyagint...@mirantis.com> wrote:

> Hello,
> that definitely about HDD. Create disk with at least 50Gb +
>
> On Mon, Mar 7, 2016 at 5:32 PM, Samer Machara <
> samer.mach...@telecom-sudparis.eu> wrote:
>
>> Hello,
>>YES, I just find the solution, the Virtualization Option on the BIOS
>> was Disable by default, I turn it on and It's working now.
>> Now my problem are the resources, But  that's another story. JEJEJE
>>
>> I'm not sure if I need RAM or HD.
>>
>>
>>
>> Thanks for your help.
>>
>> --
>> *De: *"Igor Marnat" 
>> *À: *"Maksim Malchuk" 
>> *Cc: *"Samer Machara" , "OpenStack
>> Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Envoyé: *Lundi 7 Mars 2016 11:21:42
>>
>> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
>> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>>
>> Samer,
>> did you make any progress?
>>
>> If not yet, I have couple of questions:
>> - Did you download MOS image and VBox scripts from
>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html#downloading-the-mirantis-openstack-image
>> ?
>>
>> - Can you login to your just deployed master node?
>>
>> If you can, could you please send last 50-70 strings of the file
>> /var/log/puppet/bootstrap_admin_node.log from your master node?
>>
>> Regards,
>> Igor Marnat
>>
>> On Fri, Mar 4, 2016 at 11:20 PM, Maksim Malchuk 
>> wrote:
>>
>>> Samer, please address my recommendations.
>>>
>>>
>>> On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara <
>>> samer.mach...@telecom-sudparis.eu> wrote:
>>>
>>>> Hi, Igor
>>>>   Thanks for answer so quickly.
>>>>
>>>> I wait until the following message appears
>>>> Installation timed out! (3000 seconds)
>>>> I don't have any virtual machines created.
>>>>
>>>> I update to 5.0 VirtualBox version, Now I got the following message
>>>>
>>>> VBoxManage: error: Machine 'fuel-master' is not currently running
>>>>  Waiting for product VM to download files. Please do NOT abort the
>>>> script...
>>>>
>>>> I'm still waiting
>>>>
>>>> --
>>>> *De: *"Maksim Malchuk" 
>>>> *À: *"OpenStack Development Mailing List (not for usage questions)" <
>>>> openstack-dev@lists.openstack.org>
>>>> *Envoyé: *Vendredi 4 Mars 2016 15:19:54
>>>> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
>>>> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>>>>
>>>>
>>>> Igor,
>>>>
>>>> Some information about my system:
>>>> OS: ubuntu 14.04 LTS
>>>> Memory: 3,8GiB
>>>>
>>>> Samer can't run many guests I think.
>>>>
>>>>
>>>> On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat 
>>>> wrote:
>>>>
>>>>> Samer, Maksim,
>>>>> I'd rather say that script started fuel-master already (VM
>>>>> "fuel-master" has been successfully started.), didn't find running guests,
>>>>> (VBoxManage: error: Guest not running) but it can try to start them
>>>>> afterwards.
>>>>>
>>>>> Samer,
>>>>> - how many VMs are there running besides fuel-master?
>>>>> - is it still showing "Waiting for product VM to download files.
>>>>> Please do NOT abort the script..." ?
>>>>> - for how long did you wait since the message above?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Igor Marnat
>>>>>
>>>>> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
>>>>> wrote:
>>>>>
>>>>>>

Re: [openstack-dev] [fuel] Newton PTL and CL elections

[Jeremy Stanley]

On 2016-03-07 09:49:02 -0800 (-0800), Dmitry Borodaenko wrote:
> Then that's what we will do, thanks.

Also, our official electorate roll generation aggregates potential
voter pools on a per-team basis according to definitions in
openstack/governance, so may not be fine-grained enough if you
intend to have separate rolls for your different subsystem
deliverables anyway.
-- 
Jeremy Stanley

__
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] Newton PTL and CL elections

[Dmitry Borodaenko]

On Mon, Mar 07, 2016 at 09:37:57AM +0100, Thierry Carrez wrote:
> Dmitry Borodaenko wrote:
> >Updated dates based on openstack/election events.yaml:
> >
> >PTL self-nomination: March 11-17
> >PTL election: March 18-24
> >CL self-nomination: March 25-31
> >CL election: April 1-7
> >
> >Can we fit the component leads election into the same process (i.e.
> >component lead candidates would self-nominate by submitting
> >candidates///.txt files to
> >openstack/election)?
> 
> I think the election officials already have their hands full with the
> elections required by our governance, they probably can't handle specific
> elections for custom subroles in project teams (like the component leads
> that Fuel seems to want).
> 
> I'd recommend that you run that part yourselves once the PTL is elected.

Then that's what we will do, thanks.

-- 
Dmitry Borodaenko

__
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-web] Jenkins failing, tox -e py27 error

[Jeremy Stanley]

On 2016-03-07 16:50:00 +0200 (+0200), Igor Kalnitsky wrote:
> I got it and I'm working on patch [1] that must solve it. I simply
> stop doing postre setup since it seems is already setup.
[...]

Great! I'd still like to figure out why the job suddenly started
assuming the role was missing on the new workers (or why it started
failing to be able to recreate it). It's possible we're now granting
more generous permissions to the openstack_citest user than in the
past, but skimming your job it doesn't look like that should be the
cause. Updating env.sh to set -x might make this easier to debug.
I'll move followup comments to your
https://review.openstack.org/289278 review.
-- 
Jeremy Stanley

__
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] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Aleksey Zvyagintsev]

Hello,
that definitely about HDD. Create disk with at least 50Gb +

On Mon, Mar 7, 2016 at 5:32 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Hello,
>YES, I just find the solution, the Virtualization Option on the BIOS
> was Disable by default, I turn it on and It's working now.
> Now my problem are the resources, But  that's another story. JEJEJE
>
> I'm not sure if I need RAM or HD.
>
>
>
> Thanks for your help.
>
> --
> *De: *"Igor Marnat" 
> *À: *"Maksim Malchuk" 
> *Cc: *"Samer Machara" , "OpenStack
> Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Envoyé: *Lundi 7 Mars 2016 11:21:42
>
> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>
> Samer,
> did you make any progress?
>
> If not yet, I have couple of questions:
> - Did you download MOS image and VBox scripts from
> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html#downloading-the-mirantis-openstack-image
> ?
>
> - Can you login to your just deployed master node?
>
> If you can, could you please send last 50-70 strings of the file
> /var/log/puppet/bootstrap_admin_node.log from your master node?
>
> Regards,
> Igor Marnat
>
> On Fri, Mar 4, 2016 at 11:20 PM, Maksim Malchuk 
> wrote:
>
>> Samer, please address my recommendations.
>>
>>
>> On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara <
>> samer.mach...@telecom-sudparis.eu> wrote:
>>
>>> Hi, Igor
>>>   Thanks for answer so quickly.
>>>
>>> I wait until the following message appears
>>> Installation timed out! (3000 seconds)
>>> I don't have any virtual machines created.
>>>
>>> I update to 5.0 VirtualBox version, Now I got the following message
>>>
>>> VBoxManage: error: Machine 'fuel-master' is not currently running
>>>  Waiting for product VM to download files. Please do NOT abort the
>>> script...
>>>
>>> I'm still waiting
>>>
>>> --
>>> *De: *"Maksim Malchuk" 
>>> *À: *"OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> *Envoyé: *Vendredi 4 Mars 2016 15:19:54
>>> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
>>> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>>>
>>>
>>> Igor,
>>>
>>> Some information about my system:
>>> OS: ubuntu 14.04 LTS
>>> Memory: 3,8GiB
>>>
>>> Samer can't run many guests I think.
>>>
>>>
>>> On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat 
>>> wrote:
>>>
>>>> Samer, Maksim,
>>>> I'd rather say that script started fuel-master already (VM
>>>> "fuel-master" has been successfully started.), didn't find running guests,
>>>> (VBoxManage: error: Guest not running) but it can try to start them
>>>> afterwards.
>>>>
>>>> Samer,
>>>> - how many VMs are there running besides fuel-master?
>>>> - is it still showing "Waiting for product VM to download files. Please
>>>> do NOT abort the script..." ?
>>>> - for how long did you wait since the message above?
>>>>
>>>>
>>>> Regards,
>>>> Igor Marnat
>>>>
>>>> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
>>>> wrote:
>>>>
>>>>> Hi Sames,
>>>>>
>>>>> *VBoxManage: error: Guest not running*
>>>>>
>>>>> looks line the problem with VirtualBox itself or settings for the
>>>>> 'fuel-master' VM, it can't boot it.
>>>>> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and
>>>>> start it manually - it should show you what is exactly happens.
>>>>>
>>>>>
>>>>> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
>>>>> samer.mach...@telecom-sudparis.eu> wrote:
>>>>>
>>>>>> Hello, everyone.
>>>>>> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
>>>>>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
>>>>>> but I have the following Error:
>>&g

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Samer Machara]

Hello, 
YES, I just find the solution, the Virtualization Option on the BIOS was 
Disable by default, I turn it on and It's working now. 
Now my problem are the resources, But that's another story. JEJEJE 

I'm not sure if I need RAM or HD. 



Thanks for your help. 

- Mail original -

De: "Igor Marnat"  
À: "Maksim Malchuk"  
Cc: "Samer Machara" , "OpenStack Development 
Mailing List (not for usage questions)"  
Envoyé: Lundi 7 Mars 2016 11:21:42 
Objet: Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: 
error: Guest not running [ubuntu14.04] 

Samer, 
did you make any progress? 

If not yet, I have couple of questions: 
- Did you download MOS image and VBox scripts from 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html#downloading-the-mirantis-openstack-image
 ? 

- Can you login to your just deployed master node? 

If you can, could you please send last 50-70 strings of the file 
/var/log/puppet/bootstrap_admin_node.log from your master node? 

Regards, 
Igor Marnat 

On Fri, Mar 4, 2016 at 11:20 PM, Maksim Malchuk < mmalc...@mirantis.com > 
wrote: 



Samer, please address my recommendations. 


On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara < 
samer.mach...@telecom-sudparis.eu > wrote: 



Hi, Igor 
Thanks for answer so quickly. 

I wait until the following message appears 
Installation timed out! (3000 seconds) 
I don't have any virtual machines created. 

I update to 5.0 VirtualBox version, Now I got the following message 

VBoxManage: error: Machine 'fuel-master' is not currently running 
Waiting for product VM to download files. Please do NOT abort the script... 

I'm still waiting 


De: "Maksim Malchuk" < mmalc...@mirantis.com > 
À: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Envoyé: Vendredi 4 Mars 2016 15:19:54 
Objet: Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: 
error: Guest not running [ubuntu14.04] 


Igor, 



Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 

Samer can't run many guests I think. 


On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat < imar...@mirantis.com > wrote: 



Samer, Maksim, 
I'd rather say that script started fuel-master already (VM "fuel-master" has 
been successfully started.), didn't find running guests, (VBoxManage: error: 
Guest not running) but it can try to start them afterwards. 

Samer, 
- how many VMs are there running besides fuel-master? 
- is it still showing "Waiting for product VM to download files. Please do NOT 
abort the script..." ? 
- for how long did you wait since the message above? 


Regards, 
Igor Marnat 

On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com > wrote: 



Hi Sames, 

VBoxManage: error: Guest not running 

looks line the problem with VirtualBox itself or settings for the 'fuel-master' 
VM, it can't boot it. 
Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it 
manually - it should show you what is exactly happens. 


On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < 
samer.mach...@telecom-sudparis.eu > wrote: 





Hello, everyone. 
I'm new with Fuel. I'm trying to follow the QuickStart Guide ( 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), 
but I have the following Error: 


Waiting for VM "fuel-master" to power on... 
VM "fuel-master" has been successfully started. 
VBoxManage: error: Guest not running 
VBoxManage: error: Guest not running 
... 
VBoxManage: error: Guest not running 
Waiting for product VM to download files. Please do NOT abort the script... 


I hope you can help me. 

Thanks in advance 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 





I modify the config.sh to adapt my hardware configuration 
... 
# Master node settings 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_master_memory_mb=1024 
vm_master_disk_mb=2 
... 
# The number of nodes for installing OpenStack on 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
cluster_size=3 
... 
# Slave node settings. This section allows you to define CPU count for each 
slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_cpu_default=1 
vm_slave_cpu[1]=1 
vm_slave_cpu[2]=1 
vm_slave_cpu[3]=1 
... 
# This section allows you to define RAM size in MB for each slave

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Simon Pasquier]

Yet another example [1] of why a dummy/example plugin should be integrated
in the Fuel CI process: the current version of Fuel is broken for (almost)
all plugins since a week at least and no one noticed.
Regards,
Simon

[1] https://bugs.launchpad.net/fuel/+bug/1554095

On Mon, Mar 7, 2016 at 3:16 PM, Simon Pasquier 
wrote:

> What about maintaining a dummy plugin (eg running only one or two very
> simple tasks) as a standalone project for the purpose of QA?
> IMO it would make more sense than having those example plugins in the
> fuel-plugins project...
> Regards,
> Simon
>
> On Mon, Mar 7, 2016 at 2:49 PM, Igor Kalnitsky 
> wrote:
>
>> > and really lowering barriers for people who just begin create plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>> mmoses...@mirantis.com>
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it. We
>> >> maintained these plugins in the past, but now it should a manual step
>> >> to test it out on the current release.
>> >>
>> >> What would be a more ideal situation that meets the needs of users and
>> >> QA? Right now we have failed tests until we can decide on a solution
>> >> that works for everybody.
>> >>
>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >> > No, this is a wrong road to go.
>> >> >
>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>> >> >
>> >> > Example plugins are only examples. The list of supported releases
>> must
>> >> > be maintained on system test side, and system tests must inject that
>> >> > information into plugin's metadata.yaml and test it.
>> >> >
>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> >> > responsible for preparing plugins. I can say even more: tests should
>> >> > not rely on what is produced by plugins, since it's something that
>> >> > could be changed and tests start failing.
>> >> >
>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset > >
>> >> > wrote:
>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> >> very
>> >> >> valuable for plugin developers.
>> >> >>
>> >> >> For example, I've encountered [0] the case where "plugin as role"
>> >> >> feature
>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>> last
>> >> >> plugin data structure,
>> >> >> and more recently we've spotted a regression [1] with
>> "vip-reservation"
>> >> >> feature introduced by a change in nailgun.
>> >> >> These kind of issues are time consuming for plugin developers and
>> >> >> can/must
>> >> >> be avoided by testing them.
>> >> >>
>> >> >> I don't even understand why the question is raised while fuel
>> plugins
>> >> >> are
>> >> >> supposed to be supported and more and more used [3], even by murano
>> [4]
>> >> >> ...
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> >> [3]
>> >> >>
>> >> >>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> >> [4] https://review.openstack.org/#/c/286310/
>> >> >>
>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Fuelers,
>> >> >>>
>> >> >>> I would like to bring your attention a dilemma we have here. It
>> seems
>> >> >>> that there is a dispute as to whether we should maintain the
>> releases
>> >> >>> list for example plugins[0]. In this case, this is for adding
>> version
>> >> >>> 9.0 to the list.
>> >> >>>
>> >> >>> Right now, we run a swarm test that tries to install the example
>> >> >>> plugin and do a deployment, but it's failing only for this reason.
>> I
>> >> >>> should add that this is the only automated daily test that will
>> verify
>> >> >>> that our plugin framework actually works. During the Mitaka
>> >> >>> development  cycle, we already had an extended period where plugins
>> >> >>> were broken[1]. Removing this test (or leaving it permanently red,
>> >> >>> which is effectively the same), would raise the risk to any member
>> of
>> >> >>> the Fuel community who depends on plugins actually working.
>> >> >>>
>> >> >>> The other impact of abandoning maintenance of exa

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Igor Kalnitsky]

Hey Jeremy,

I got it and I'm working on patch [1] that must solve it. I simply
stop doing postre setup since it seems is already setup.

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

On Mon, Mar 7, 2016 at 4:38 PM, Jeremy Stanley  wrote:
> On 2016-03-07 16:02:40 +0530 (+0530), Prameswar Lal wrote:
>> I recently started exploring Fuel. Found a small error in documentation but
>> when i am trying to push the fix, jenkins is throwing following errors:
> [...]
>> | Creating role openstack_citest with password
>> openstack_citest2016-03-07 10:05:18.684
>> 
>> | psql: FATAL:  password authentication failed for user
>> "postgres"2016-03-07 10:05:18.684
>> 
> [...]
>
> Late last week we moved unit test jobs to a new minimal worker type
> which requires installation of distro packages and database
> configuration during job runtime. I tried to recreate (as closely as
> possible) with shell scripts the setup previously performed by
> corresponding Puppet modules which took place during image creation
> for the prior worker type. You can see at
> http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_04_22_654
> that the job successfully logs into postgres with a root password of
> "insecure_slave" and creates an openstack_citest role with password
> "openstack_citest".
>
> Any help from those more familiar with the database use in Fuel's
> unit tests in narrowing down what's different about this postgrest
> setup vs the old one would be most appreciated.
> --
> Jeremy Stanley
>
> __
> 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] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Jeremy Stanley]

On 2016-03-07 16:02:40 +0530 (+0530), Prameswar Lal wrote:
> I recently started exploring Fuel. Found a small error in documentation but
> when i am trying to push the fix, jenkins is throwing following errors:
[...]
> | Creating role openstack_citest with password
> openstack_citest2016-03-07 10:05:18.684
> 
> | psql: FATAL:  password authentication failed for user
> "postgres"2016-03-07 10:05:18.684
> 
[...]

Late last week we moved unit test jobs to a new minimal worker type
which requires installation of distro packages and database
configuration during job runtime. I tried to recreate (as closely as
possible) with shell scripts the setup previously performed by
corresponding Puppet modules which took place during image creation
for the prior worker type. You can see at
http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_04_22_654
that the job successfully logs into postgres with a root password of
"insecure_slave" and creates an openstack_citest role with password
"openstack_citest".

Any help from those more familiar with the database use in Fuel's
unit tests in narrowing down what's different about this postgrest
setup vs the old one would be most appreciated.
-- 
Jeremy Stanley

__
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][plugins] Should we maintain example plugins?

[Simon Pasquier]

What about maintaining a dummy plugin (eg running only one or two very
simple tasks) as a standalone project for the purpose of QA?
IMO it would make more sense than having those example plugins in the
fuel-plugins project...
Regards,
Simon

On Mon, Mar 7, 2016 at 2:49 PM, Igor Kalnitsky 
wrote:

> > and really lowering barriers for people who just begin create plugins.
>
> Nonsense. First, people usually create them via running `fpb --create
> plugin-name` that generates plugin boilerplate. And that boilerplate
> won't contain that changes.
>
> Second, if people ain't smart enough to change few lines in
> `metadata.yaml` of generated boilerplate to make it work with latest
> Fuel, maybe it's better for them to do not develop plugins at all?
>
> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>  wrote:
> > +1 to maintain example plugins. It is easy enough and really lowering
> > barriers for people who just begin create plugins.
> >
> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn  >
> > wrote:
> >>
> >> Igor,
> >>
> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> >> example plugin, add in the current Fuel release, and then build it. We
> >> maintained these plugins in the past, but now it should a manual step
> >> to test it out on the current release.
> >>
> >> What would be a more ideal situation that meets the needs of users and
> >> QA? Right now we have failed tests until we can decide on a solution
> >> that works for everybody.
> >>
> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky  >
> >> wrote:
> >> > No, this is a wrong road to go.
> >> >
> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
> >> > Remove v1 example from source tree? That doesn't seem good to me.
> >> >
> >> > Example plugins are only examples. The list of supported releases must
> >> > be maintained on system test side, and system tests must inject that
> >> > information into plugin's metadata.yaml and test it.
> >> >
> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
> >> > responsible for preparing plugins. I can say even more: tests should
> >> > not rely on what is produced by plugins, since it's something that
> >> > could be changed and tests start failing.
> >> >
> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
> >> > wrote:
> >> >> IMHO it is important to keep plugin examples and keep testing them,
> >> >> very
> >> >> valuable for plugin developers.
> >> >>
> >> >> For example, I've encountered [0] the case where "plugin as role"
> >> >> feature
> >> >> wasn't easily testable with fuel-qa because not compliant with the
> last
> >> >> plugin data structure,
> >> >> and more recently we've spotted a regression [1] with
> "vip-reservation"
> >> >> feature introduced by a change in nailgun.
> >> >> These kind of issues are time consuming for plugin developers and
> >> >> can/must
> >> >> be avoided by testing them.
> >> >>
> >> >> I don't even understand why the question is raised while fuel plugins
> >> >> are
> >> >> supposed to be supported and more and more used [3], even by murano
> [4]
> >> >> ...
> >> >>
> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> >> [3]
> >> >>
> >> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> >> [4] https://review.openstack.org/#/c/286310/
> >> >>
> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> Hi Fuelers,
> >> >>>
> >> >>> I would like to bring your attention a dilemma we have here. It
> seems
> >> >>> that there is a dispute as to whether we should maintain the
> releases
> >> >>> list for example plugins[0]. In this case, this is for adding
> version
> >> >>> 9.0 to the list.
> >> >>>
> >> >>> Right now, we run a swarm test that tries to install the example
> >> >>> plugin and do a deployment, but it's failing only for this reason. I
> >> >>> should add that this is the only automated daily test that will
> verify
> >> >>> that our plugin framework actually works. During the Mitaka
> >> >>> development  cycle, we already had an extended period where plugins
> >> >>> were broken[1]. Removing this test (or leaving it permanently red,
> >> >>> which is effectively the same), would raise the risk to any member
> of
> >> >>> the Fuel community who depends on plugins actually working.
> >> >>>
> >> >>> The other impact of abandoning maintenance of example plugins is
> that
> >> >>> it means that a given interested Fuel Plugin developer would not be
> >> >>> able to easily get started with plugin development. It might not be
> >> >>> inherently obvious to add the current Fuel release to the
> >> >>> metadata.yaml file and it would likely discourage such a user. In
> this
> >> >>> case, I would propose that we remove example plugins from
> fuel-plugins
> >> >>> GIT repo if they are not maintained. Non-functioning code is worse
> >> >>> than deleted code i

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Igor Kalnitsky]

> and really lowering barriers for people who just begin create plugins.

Nonsense. First, people usually create them via running `fpb --create
plugin-name` that generates plugin boilerplate. And that boilerplate
won't contain that changes.

Second, if people ain't smart enough to change few lines in
`metadata.yaml` of generated boilerplate to make it work with latest
Fuel, maybe it's better for them to do not develop plugins at all?

On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
 wrote:
> +1 to maintain example plugins. It is easy enough and really lowering
> barriers for people who just begin create plugins.
>
> On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn 
> wrote:
>>
>> Igor,
>>
>> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> example plugin, add in the current Fuel release, and then build it. We
>> maintained these plugins in the past, but now it should a manual step
>> to test it out on the current release.
>>
>> What would be a more ideal situation that meets the needs of users and
>> QA? Right now we have failed tests until we can decide on a solution
>> that works for everybody.
>>
>> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky 
>> wrote:
>> > No, this is a wrong road to go.
>> >
>> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> > Remove v1 example from source tree? That doesn't seem good to me.
>> >
>> > Example plugins are only examples. The list of supported releases must
>> > be maintained on system test side, and system tests must inject that
>> > information into plugin's metadata.yaml and test it.
>> >
>> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> > responsible for preparing plugins. I can say even more: tests should
>> > not rely on what is produced by plugins, since it's something that
>> > could be changed and tests start failing.
>> >
>> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
>> > wrote:
>> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> very
>> >> valuable for plugin developers.
>> >>
>> >> For example, I've encountered [0] the case where "plugin as role"
>> >> feature
>> >> wasn't easily testable with fuel-qa because not compliant with the last
>> >> plugin data structure,
>> >> and more recently we've spotted a regression [1] with "vip-reservation"
>> >> feature introduced by a change in nailgun.
>> >> These kind of issues are time consuming for plugin developers and
>> >> can/must
>> >> be avoided by testing them.
>> >>
>> >> I don't even understand why the question is raised while fuel plugins
>> >> are
>> >> supposed to be supported and more and more used [3], even by murano [4]
>> >> ...
>> >>
>> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> [3]
>> >>
>> >> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> [4] https://review.openstack.org/#/c/286310/
>> >>
>> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> 
>> >> wrote:
>> >>>
>> >>> Hi Fuelers,
>> >>>
>> >>> I would like to bring your attention a dilemma we have here. It seems
>> >>> that there is a dispute as to whether we should maintain the releases
>> >>> list for example plugins[0]. In this case, this is for adding version
>> >>> 9.0 to the list.
>> >>>
>> >>> Right now, we run a swarm test that tries to install the example
>> >>> plugin and do a deployment, but it's failing only for this reason. I
>> >>> should add that this is the only automated daily test that will verify
>> >>> that our plugin framework actually works. During the Mitaka
>> >>> development  cycle, we already had an extended period where plugins
>> >>> were broken[1]. Removing this test (or leaving it permanently red,
>> >>> which is effectively the same), would raise the risk to any member of
>> >>> the Fuel community who depends on plugins actually working.
>> >>>
>> >>> The other impact of abandoning maintenance of example plugins is that
>> >>> it means that a given interested Fuel Plugin developer would not be
>> >>> able to easily get started with plugin development. It might not be
>> >>> inherently obvious to add the current Fuel release to the
>> >>> metadata.yaml file and it would likely discourage such a user. In this
>> >>> case, I would propose that we remove example plugins from fuel-plugins
>> >>> GIT repo if they are not maintained. Non-functioning code is worse
>> >>> than deleted code in my opinion.
>> >>>
>> >>> Please share your opinions and let's decide which way to go with this
>> >>> bug[2]
>> >>>
>> >>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
>> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
>> >>> [2] https://launchpad.net/bugs/1548340
>> >>>
>> >>> Best Regards,
>> >>> Matthew Mosesohn
>> >>>
>> >>>
>> >>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubsc

[openstack-dev] [Fuel] [QA] Major changes in fuel-qa

[Dmitry Tyzhnenko]

Hello,

Recently system_test framework had changes [0] which incompatible previous
test case design.

Now it has separate packages for:
- actions - contains classes with test actions
- core - contains core functionality and decorators
- test - contains base test and test cases
- helpers - contains some additional tools

Some re-design of system_test packages:
- actions were moved to separate packages (system_test.actions)
- core functionality was moved to core packages (system_test.core)
- added system_test.tests.base.ActionTest as main base class for tests,
all cases should inherit it.
- all test classes should inherit one or more classes with actions.

Specification can be found here: [1]

IMPORTANT!
If you use 3thd-party tests with this framework, you should:
   - use decorator @testcase for mark class as test and set groups
   - test class should inherits ActionTest and additional action classes
from system_test.actions package if required.
- remove case_factory() function from your test cases because it is not
used anymore (was replaced with @testcase)
- base_group class attribute moved to @testcase decorator, now it
should be used like this:
  @testcase(groups=['system_test', 'system_test.delete_after_deploy',
...])

P.S. This changes affect only tests in 9.0.

[0] -
https://github.com/openstack/fuel-qa/commit/82b392284a3a621aaa435c78d96dde799dfe2372
[1] -
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/template-based-testcases.rst

-- 
WBR,
Dmitry T.
Fuel QA Engineer
http://www.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

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Igor Kalnitsky]

Hey Prameswar,

It seems we're experiencing that issue on all our patches. For
example, the same error blocks that patch from merge [1].

I think it's some OpenStack CI issue. Let's give a time.

- Igor

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

On Mon, Mar 7, 2016 at 12:32 PM, Prameswar Lal  wrote:
> Hi All,
>
> I recently started exploring Fuel. Found a small error in documentation but
> when i am trying to push the fix, jenkins is throwing following errors:
>
>
>
> 2016-03-07 10:05:18.619 | psql: FATAL:  password authentication failed for
> user "postgres"
> 2016-03-07 10:05:18.619 | FATAL:  password authentication failed for user
> "postgres"
> 2016-03-07 10:05:18.619 | password retrieved from file
> "/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"
> 2016-03-07 10:05:18.620 | Creating role openstack_citest with password
> openstack_citest
> 2016-03-07 10:05:18.684 | psql: FATAL:  password authentication failed for
> user "postgres"
> 2016-03-07 10:05:18.684 | FATAL:  password authentication failed for user
> "postgres"
> 2016-03-07 10:05:18.684 | password retrieved from file
> "/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"
> 2016-03-07 10:05:18.686 | ERROR: InvocationError: '/bin/bash -c
> /home/jenkins/workspace/gate-fuel-web-python27/nailgun/tools/env.sh
> prepare_nailgun_database'
>
>
>
> http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_05_18_684
>
>
> Can anybody please provide me pointers on how to resolve this?
>
>
>
> Thanks & Regards
> Prameswar
>
> __
> 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-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Prameswar Lal]

Hi All,

I recently started exploring Fuel. Found a small error in documentation but
when i am trying to push the fix, jenkins is throwing following errors:


2016-03-07 10:05:18.619

| psql: FATAL:  password authentication failed for user
"postgres"2016-03-07 10:05:18.619

| FATAL:  password authentication failed for user "postgres"2016-03-07
10:05:18.619 

| password retrieved from file
"/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"2016-03-07
10:05:18.620 

| Creating role openstack_citest with password
openstack_citest2016-03-07 10:05:18.684

| psql: FATAL:  password authentication failed for user
"postgres"2016-03-07 10:05:18.684

| FATAL:  password authentication failed for user "postgres"2016-03-07
10:05:18.684 

| password retrieved from file
"/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"2016-03-07
10:05:18.686 

| ERROR: InvocationError: '/bin/bash -c
/home/jenkins/workspace/gate-fuel-web-python27/nailgun/tools/env.sh
prepare_nailgun_database'



http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_05_18_684


Can anybody please provide me pointers on how to resolve this?



Thanks & Regards
Prameswar
__
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] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Igor Marnat]

Samer,
did you make any progress?

If not yet, I have couple of questions:
- Did you download MOS image and VBox scripts from
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html#downloading-the-mirantis-openstack-image
?

- Can you login to your just deployed master node?

If you can, could you please send last 50-70 strings of the file
/var/log/puppet/bootstrap_admin_node.log from your master node?

Regards,
Igor Marnat

On Fri, Mar 4, 2016 at 11:20 PM, Maksim Malchuk 
wrote:

> Samer, please address my recommendations.
>
>
> On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara <
> samer.mach...@telecom-sudparis.eu> wrote:
>
>> Hi, Igor
>>   Thanks for answer so quickly.
>>
>> I wait until the following message appears
>> Installation timed out! (3000 seconds)
>> I don't have any virtual machines created.
>>
>> I update to 5.0 VirtualBox version, Now I got the following message
>>
>> VBoxManage: error: Machine 'fuel-master' is not currently running
>>  Waiting for product VM to download files. Please do NOT abort the
>> script...
>>
>> I'm still waiting
>>
>> --
>> *De: *"Maksim Malchuk" 
>> *À: *"OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Envoyé: *Vendredi 4 Mars 2016 15:19:54
>> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
>> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>>
>>
>> Igor,
>>
>> Some information about my system:
>> OS: ubuntu 14.04 LTS
>> Memory: 3,8GiB
>>
>> Samer can't run many guests I think.
>>
>>
>> On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat  wrote:
>>
>>> Samer, Maksim,
>>> I'd rather say that script started fuel-master already (VM "fuel-master"
>>> has been successfully started.), didn't find running guests, (VBoxManage:
>>> error: Guest not running) but it can try to start them afterwards.
>>>
>>> Samer,
>>> - how many VMs are there running besides fuel-master?
>>> - is it still showing "Waiting for product VM to download files. Please
>>> do NOT abort the script..." ?
>>> - for how long did you wait since the message above?
>>>
>>>
>>> Regards,
>>> Igor Marnat
>>>
>>> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
>>> wrote:
>>>
>>>> Hi Sames,
>>>>
>>>> *VBoxManage: error: Guest not running*
>>>>
>>>> looks line the problem with VirtualBox itself or settings for the
>>>> 'fuel-master' VM, it can't boot it.
>>>> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start
>>>> it manually - it should show you what is exactly happens.
>>>>
>>>>
>>>> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
>>>> samer.mach...@telecom-sudparis.eu> wrote:
>>>>
>>>>> Hello, everyone.
>>>>> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
>>>>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
>>>>> but I have the following Error:
>>>>>
>>>>>
>>>>> *Waiting for VM "fuel-master" to power on...*
>>>>> *VM "fuel-master" has been successfully started.*
>>>>> *VBoxManage: error: Guest not running*
>>>>> *VBoxManage: error: Guest not running*
>>>>> ...
>>>>> *VBoxManage: error: Guest not running*
>>>>> *Waiting for product VM to download files. Please do NOT abort the
>>>>> script...*
>>>>>
>>>>>
>>>>>
>>>>> I hope you can help me.
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>>
>>>>> Some information about my system:
>>>>> OS: ubuntu 14.04 LTS
>>>>> Memory: 3,8GiB
>>>>> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4
>>>>> OS type: 64-bit
>>>>> Disk 140,2GB
>>>>> VirtualBox Version: 4.3.36_Ubuntu
>>>>> Checking for 'expect'... OK
>>>>> Checking for 'xxd'... OK
>>>>> Checking for "VBoxManage"... OK
>>>>> Checking for VirtualBox Extension Pack... OK
>>>>> Checking if SSH client installed... OK
>>>

Re: [openstack-dev] [Fuel] Fuel 8 crashes when using Advanced Install

[Aleksey Zvyagintsev]

Hi Razvan,
could you please provide cmdline which has been passed ?
you can get it with simple `cat /proc/cmdline ` in second dracut tab



On Sun, Mar 6, 2016 at 2:42 PM, Razvan Rosca  wrote:

> Hey,
>
> Tried this on 4 Dell machines, issue is present on all. Each server has 2
> SSDs in no RAID.
>
> What I'm doing:
> - mount ISO
> - select Advanced Install
> - error
>
>
> ​
> Is this a known bug?
>
> Thanks,
> Razvan Rosca
>
> Email: raz...@webhipo.com
> Skype: razvan.rosca
> Tel.: +4 0731 059 660
> Web: http://www.webhipo.com
> Facebook: http://www.fb.com/webhipo
> Twitter: http://www.twitter.com/webhipo
>
>
> __
> 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,
   Aleksey Zvyagintsev
__
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] Newton PTL and CL elections

[Thierry Carrez]

Dmitry Borodaenko wrote:

Updated dates based on openstack/election events.yaml:

PTL self-nomination: March 11-17
PTL election: March 18-24
CL self-nomination: March 25-31
CL election: April 1-7

Can we fit the component leads election into the same process (i.e.
component lead candidates would self-nominate by submitting
candidates///.txt files to
openstack/election)?


I think the election officials already have their hands full with the 
elections required by our governance, they probably can't handle 
specific elections for custom subroles in project teams (like the 
component leads that Fuel seems to want).


I'd recommend that you run that part yourselves once the PTL is elected.

--
Thierry Carrez (ttx)

__
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] Fuel CI issues

[Dmitry Borodaenko]

Aleksandra,

Very good point on separating the concerns about integration tests for
Fuel as a whole and verifying commits to a single component such as
fuel-library. In theory, it could support the right balance between
stable CI and up-to-date code, but only if we resolve the two remaining
problems: one small and technical and the other large and social.

You've already pointed out the first problem: update of fuel-library CI
environment is not yet fully automated, and so the environment is liable
to lag behind all involved components for days if not weeks.

This by itself is simple enough, if labourous, to work around (update it
manually every day, or after every successful BVT), but still leaves us
with the problem of motivation.

We've been discussing the CI duty for fuel-library integration with
puppet-openstack since more than a month ago [0], and it has
continuously failed to materialize. Within days of getting an action
item in that IRC meeting to arrange it, Andrew Maksimov has responded
privately that nobody in his team has time for this. And we all know
what "I don't have time" actually means [1]. Two weeks later, we were
ready to launch the integration and the question of CI duty came up
again [2], with the same result.

[0] 
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66
[1] 
http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
[2] 
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190

Here we are two more weeks later, the integration is on, and the first
reaction from fuel-library core reviewers is "we don't have time to deal
with this, turn it back off right now". And I'm not just summarizing
Vladimir's email, on Friday we had a long thread on an internal mailing
list with exactly this in the subject line (my apologies, but my disgust
at the fact that it was started behind closed doors drowns any qualms
about dragging it back into the open).

After we change Fuel CI to use fixed, most recent to have passed BVT,
revisions of puppet-openstack modules, first thing that will happen is
that BVT on Fuel ISO will start failing again, while fuel-library CI
will continue to work. Without the pressure of failing commit
verification CI, fuel-library developers will have even less incentive
to keep fuel-library up to date with puppet-openstack (not to mention
pro-actively reviewing puppet-openstack commits to catch potential
regressions before they happen), and very soon Fuel QA team will get fed
up with not having a stable ISO for the swarm test, and will demand that
we go back to using fixed puppet-openstack revisions for the ISO, too.

Both here and on the internal thread, many technical and organizational
concerns were raised, and I'll get to them in a bit, but a concern
without the will to resolve it is only an excuse, we won't get far if we
don't want to make it work.

So why don't fuel-library developers want to spend time on
puppet-openstack integration?

I see two dimensions to this problem. On one axis, there's the
cost/benefit balance: how much work does it take, and what do we gain
from doing it? On the other is the question of who benefits and who
carries the costs?

Without tracking HEAD of puppet-openstack in fuel-library, the primary
cost is carried by puppet-openstack developers who maintain the upstream
modules in the first place, and a small fraction of fuel-library
contributors (5+ out of 50+ [3][4]) who periodically have to spend
significant amount of effort to bring fuel-library up to date with the
current state of puppet-openstack. Even though the conversion to
librarian has made the upstream sync simpler and safer, preparing the
update to Mitaka still took a full month of work for 5-7 people.

[3] 
http://stackalytics.com/?module=puppet%20openstack-group&company=mirantis&metric=commits
[4] http://stackalytics.com/?module=fuel-library&company=mirantis&metric=commits

Secondary costs are carried by Fuel Infra and QA teams who have to
support CI based on two OpenStack releases in parallel during that
month, fuel-library and puppet-openstack developers who have to deal
with a spike in code churn, all Fuel contributors who are blocked by
merge freeze during transition, and once again Fuel QA team who
occasionally get blocked by bugs that were fixed in upstream and not yet
pulled into fuel-library.

In short, under that model, most fuel-library developers don't have to
do much to gain the benefit of being up to date with upstream, such us
getting support of the next OpenStack release. The integration cost,
around 7-10 man-months per release, is carried mostly by other people.

Transition to full integration with upstream via tracking HEAD of
puppet-openstack in fuel-library dramatically alters this balance.
Massive upstream sync is gone, and so are the associated costs of
parallel CI, transition merge freeze, and missing upstream bugfixes. The
code churn is still there, but more 

[openstack-dev] [Fuel] Fuel 8 crashes when using Advanced Install

[Razvan Rosca]

Hey,

Tried this on 4 Dell machines, issue is present on all. Each server has 2
SSDs in no RAID.

What I'm doing:
- mount ISO
- select Advanced Install
- error


​
Is this a known bug?

Thanks,
Razvan Rosca

Email: raz...@webhipo.com
Skype: razvan.rosca
Tel.: +4 0731 059 660
Web: http://www.webhipo.com
Facebook: http://www.fb.com/webhipo
Twitter: http://www.twitter.com/webhipo
__
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] Fuel CI issues

[Aleksandra Fedorova]

I think we need to address two separate concerns here:

1) smooth integration of puppet-openstack with Fuel master;
2)  tests for changes in fuel-library.

For 1) we need to build and test Fuel against master of
puppet-openstack and treat any integration issues as critical/blocker.
And this is what regular ISO builds and BVT tests are for.

But for 2) we need to test new commit to fuel-library against fixed
baseline - which means stable everything including Ubuntu upstream
mirror, QA framework, fuel code, mos packages or puppet-openstack
modules.

So while I think we should build ISO from current latest HEAD, debug
BVT failures and address them ASAP, we need also to pin puppet modules
used for fuel-library tests to provide targeted feedback on
fuel-library reviews.

To do so we can rely on the same process as we use now for fixing
ubuntu upstream repo:

We have a jenkins job which defines environment for deployment tests:

  https://ci.fuel-infra.org/view/devops/job/devops.master.env/

And additionally to fuel-qa commit, ubuntu mirror id and iso magnet
link we can provide there also the versions list or the entire tarball
of puppet modules which were tested in the latest bvt.

Then we will update the environment as a whole via the same process as
we have now for ISO images.
(Actually I hope it will become a much better process soon as we plan
to speed up and fully automate environment update in the nearest
future).

On Tue, Mar 1, 2016 at 11:36 PM, Sergey Kolekonov
 wrote:
> I think we should also look at the root cause of these CI failures.
> They are connected with difference in packages and not with manifests or
> deployment process.
> So another possible solution is to stay as close as possible to the package
> sources used by OpenStack Puppet modules CI.
> For example, we have a BP [0] that adds an ability to deploy UCA packages
> with Fuel.
> Current package sources used by openstack-modules CI can be found here [1]
>
> Just my 2c.
> Thanks.
>
> [0] https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages
> [1]
> https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/repos.pp#L4
>
> On Tue, Mar 1, 2016 at 2:21 PM, Vladimir Kuklin 
> wrote:
>>
>> Dmitry
>>
>> >I don't think "hurried" is applicable here: the only way to become more
>> >ready to track upstream than we already are is to *start* tracking
>> >upstream. Postponing that leaves us in a Catch-22 situation where we
>> >can't stay in sync with upstream because we're not continuously catching
>> >up with upstream.
>>
>> First of all, if you read my email again, you will see that I propose a
>> way of tracking upstream in less continuous mode with nightly testing and
>> switching to it based on automated integration testing which will leave us 0
>> opportunity to face the aforementioned issues.
>>
>> >That would lock us into that Catch-22 situation where we can't allow
>> >Fuel CI to vote on puppet-openstack commits because fuel-library is
>> >always too far behind puppet-openstack for its votes to mean anything
>> >useful.
>>
>> This is not true. We can run FUEL CI against any set of commits.
>>
>> > We have to approach this from the opposite direction: make Fuel CI
>> > stable and meaningful enough so that, 9 times out of 10, Fuel CI failure
>> > indicates a real problem with the code, and the remaining cases can be
>> > quickly unblocked by pushing a catch-up commit to fuel-library (ideally
>> > with a Depends-On tag).
>>
>> Dmitry, could you please point me at the person who will be strictly
>> responsible for creating this 'ketchup' commit? Do you know that this may
>> take up the whole day (couple of hours to do RCA, couple of hours on writing
>> and debugging and couple of hours for FUEL CI tests run) and block the
>> entire Fuel project from having ANY code merged? Taking into consideration
>> that openstack infra is currently under really high load it may take even
>> several days for the fix to land into master. How do you expect us to have
>> any feature merged prior to FF?
>>
>> > It is a matter of trust between projects: do we trust Puppet OpenStack
>> > project to take Fuel's problems seriously and to avoid breaking our CI
>> > more often than necessary? Can Puppet OpenStack project trust us with
>> > the same? So far, our collaboration track record has been pretty good
>> > bordering on examplary, and I think we should build on that and move
>> > forward instead of clinging to the old ways.
>> > The problem with moving only one piece at a time is that you end up so
>> > far behind that you're slowing everyone down. BKL and GIL are not the
>> > only way to deal with concurrency, we can do better than that.
>>
>> I have always thought that buliding software is about verification being
>> more important than 'trust'. There should not be any humanitarian stuff
>> invloved - we are not in a relationship with Puppet-OpenStack folks,
>> although I really admire their work very much. We should not follow

Re: [openstack-dev] [fuel] Fuel 9.0/Mitaka is now in Feature Freeze

[Dmitry Borodaenko]

Based on the list of approved exceptions, we're going to be merging some
feature changes until March 24. It doesn't make sense to have Soft Code
Freeze until a couple of weeks after that, so I propose to shift the
release dates by 3 weeks:

9.0 Soft Code Freeze: April 6
9.0 Release: April 20

Updated schedule:
https://wiki.openstack.org/wiki/Fuel/9.0_Release_Schedule

-- 
Dmitry Borodaenko


On Thu, Mar 03, 2016 at 04:31:56PM -0800, Dmitry Borodaenko wrote:
> Following feature freeze exceptions were granted, ordered by their merge
> deadline. See linked emails for additonal conditions attached to some of
> these exceptions.
> 
> UCA, 3/10:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088309.html
> 
> Multipath disks, 3/10:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088282.html
> 
> LCM readyness for all deployment tasks, 3/15:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088310.html
> 
> HugePages, 3/16:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088292.html
> 
> Numa, 3/16:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088292.html
> 
> SR-IOV, 3/16:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088307.html
> 
> Decouple Fuel and OpenStack tasks, 3/20:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html
> 
> Remove conflicting openstack module parts, 3/20:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html
> 
> DPDK, 3/24:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088291.html
> 
> Unlock "Settings" Tab, 3/24:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088305.html
> 
> ConfigDB, 3/24:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088279.html
> 
> Osnailyfacter refactoring for Puppet Master compatibility, 3/24:
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088308.html
> 
> All other feature changes will have to wait until Soft Code Freeze.
> 
> See IRC meeting minutes and log from #fuel-dev for more details:
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.html
> http://irclog.perlgeek.de/fuel-dev/2016-03-03#i_12133112
> 
> -- 
> Dmitry Borodaenko
> 
> 
> On Wed, Mar 02, 2016 at 10:31:09PM -0800, Dmitry Borodaenko wrote:
> > Feature Freeze [0] for Fuel 9.0/Mitaka is now in effect. From this
> > moment and until stable/mitaka branch is created at Soft Code Freeze,
> > please do not merge feature related changes that have not received a
> > feature freeze exception.
> > 
> > [0] https://wiki.openstack.org/wiki/FeatureFreeze
> > 
> > We will discuss all outstanding feature freeze exception requests in our
> > weekly IRC meeting tomorrow [1]. If that discussion takes longer than
> > the 1 hour time slot we have booked on #openstack-meeting-alt, we'll
> > move the discussion to #fuel-dev and finish it there.
> > 
> > [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
> > 
> > The list of exceptions requested so far is exceedingly long and it is
> > likely that most of these exceptions will be rejected. If you want your
> > exception to be approved, please have the following information ready
> > for the meeting:
> > 
> > 1) Link to design spec in fuel-specs, spec review status;
> > 
> > 2) Links to all outstanding commits for the feature;
> > 
> > 3) Dependencies between your change and other features: what will be
> > broken or useless if your change is not merged, what else has to be
> > merged for your change to work;
> > 
> > 4) Analysis of impact and risks mitigation plan: which components are
> > affected by the change, what can break, how can impact be verified, how
> > can the change be isolated;
> > 
> > 5) Status of test coverage: what can be tested, what's covered by
> > automated tests, what's been tested so far (with links to test results).
> > 
> > -- 
> > Dmitry Borodaenko

__
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 8.0 is released

[Dmitry Borodaenko]

No, we have no plans for CentOS 7.x on controllers in Fuel 9.0/Mitaka,
and our plans for Newton are still under discussion.

I strongly suspect that life cycle management related features will
consume most of Fuel team's attention, we've found that problems with
the numerous LCM use cases cause a lot more pain to operators than the
limited choice of base operating system distributions.

Still, if you or someone else is willing to dedicate some time to adding
support for CentOS 7.x based controllers to Fuel, we would gladly
welcome it. Mind that it's not going to be easy, see the amount of work
that went into adding Ubuntu 12.04 support in Fuel 4.0 and later
updating that to Ubuntu 14.04 in Fuel 6.1.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 07:40:36PM +0800, Shake Chen wrote:
> Hi
> 
> any plan support install Openstack controller in CentOS 7.x?
> 
> On Wed, Mar 2, 2016 at 10:20 AM, Dmitry Borodaenko  > wrote:
> 
> > We are proud to announce the release of Fuel 8.0, deployment and
> > management tool for OpenStack.
> >
> > This release initroduces support for OpenStack Liberty, adds a number of
> > exciting new features and enhancements, fixes over 1600 bugs, and
> > eliminates a great deal of technical debt.
> >
> > Some highlights:
> >
> > - Support for multi-rack deployments with L3 routing between racks that
> >   was first introduced in Fuel 6.0 was expanded with more automation and
> >   validation; some key limitations of the previous implementation, such
> >   as placing all VIPs, floating IPs, and controllers in a single rack,
> >   have been relaxed (although controller services failover across racks
> >   still needs extra work); node groups can now be managed via Fuel UI.
> >
> > - Fuel master node now runs on CentOS 7 with Python 2.7.
> >
> > - The bootstrap image used for node discovery and provisioning is now
> >   generated when Fuel node is setup, and can be dynamically rebuilt to
> >   include additional drivers. This unifies the kernel version from
> >   discovery to a working install, removing a whole host of possible
> >   compatibility issues
> >
> > - As another small step towards enabling life cycle management, a
> >   limited set of cloud configuration parameters can now be changed after
> >   deployment. This includes changing configuration of OpenStack services
> >   and installation of additional software via plugins.
> >
> > Learn more about Fuel:
> > https://wiki.openstack.org/wiki/Fuel
> >
> > How we work:
> > https://wiki.openstack.org/wiki/Fuel/How_to_contribute
> >
> > Specs for features in 8.0 and other Fuel releases:
> > http://specs.openstack.org/openstack/fuel-specs/
> >
> > ISO image:
> >
> > http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
> >
> > RPM packages:
> > http://mirror.fuel-infra.org/mos-repos/centos/mos8.0-centos7-fuel/
> >
> > Great work Fuel team, thanks to everyone who contributed to this awesome
> > release!
> >
> > --
> > Dmitry Borodaenko
> >
> > __
> > 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
> >
> 
> 
> 
> -- 
> Shake Chen

> __
> 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] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Maksim Malchuk]

Samer, please address my recommendations.


On Fri, Mar 4, 2016 at 7:49 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Hi, Igor
>   Thanks for answer so quickly.
>
> I wait until the following message appears
> Installation timed out! (3000 seconds)
> I don't have any virtual machines created.
>
> I update to 5.0 VirtualBox version, Now I got the following message
>
> VBoxManage: error: Machine 'fuel-master' is not currently running
>  Waiting for product VM to download files. Please do NOT abort the
> script...
>
> I'm still waiting
>
> --
> *De: *"Maksim Malchuk" 
> *À: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Envoyé: *Vendredi 4 Mars 2016 15:19:54
> *Objet: *Re: [openstack-dev] [Fuel] [Openstack] Instalation
> Problem:VBoxManage: error: Guest not running [ubuntu14.04]
>
>
> Igor,
>
> Some information about my system:
> OS: ubuntu 14.04 LTS
> Memory: 3,8GiB
>
> Samer can't run many guests I think.
>
>
> On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat  wrote:
>
>> Samer, Maksim,
>> I'd rather say that script started fuel-master already (VM "fuel-master"
>> has been successfully started.), didn't find running guests, (VBoxManage:
>> error: Guest not running) but it can try to start them afterwards.
>>
>> Samer,
>> - how many VMs are there running besides fuel-master?
>> - is it still showing "Waiting for product VM to download files. Please
>> do NOT abort the script..." ?
>> - for how long did you wait since the message above?
>>
>>
>> Regards,
>> Igor Marnat
>>
>> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
>> wrote:
>>
>>> Hi Sames,
>>>
>>> *VBoxManage: error: Guest not running*
>>>
>>> looks line the problem with VirtualBox itself or settings for the
>>> 'fuel-master' VM, it can't boot it.
>>> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start
>>> it manually - it should show you what is exactly happens.
>>>
>>>
>>> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
>>> samer.mach...@telecom-sudparis.eu> wrote:
>>>
>>>> Hello, everyone.
>>>> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
>>>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
>>>> but I have the following Error:
>>>>
>>>>
>>>> *Waiting for VM "fuel-master" to power on...*
>>>> *VM "fuel-master" has been successfully started.*
>>>> *VBoxManage: error: Guest not running*
>>>> *VBoxManage: error: Guest not running*
>>>> ...
>>>> *VBoxManage: error: Guest not running*
>>>> *Waiting for product VM to download files. Please do NOT abort the
>>>> script...*
>>>>
>>>>
>>>>
>>>> I hope you can help me.
>>>>
>>>> Thanks in advance
>>>>
>>>>
>>>> Some information about my system:
>>>> OS: ubuntu 14.04 LTS
>>>> Memory: 3,8GiB
>>>> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4
>>>> OS type: 64-bit
>>>> Disk 140,2GB
>>>> VirtualBox Version: 4.3.36_Ubuntu
>>>> Checking for 'expect'... OK
>>>> Checking for 'xxd'... OK
>>>> Checking for "VBoxManage"... OK
>>>> Checking for VirtualBox Extension Pack... OK
>>>> Checking if SSH client installed... OK
>>>> Checking if ipconfig or ifconfig installed... OK
>>>>
>>>>
>>>> I modify the config.sh to adapt my hardware configuration
>>>> ...
>>>> # Master node settings
>>>> if [ "$CONFIG_FOR" = "4GB" ]; then
>>>> vm_master_memory_mb=1024
>>>> vm_master_disk_mb=2
>>>> ...
>>>> # The number of nodes for installing OpenStack on
>>>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>>>> cluster_size=3
>>>> ...
>>>> # Slave node settings. This section allows you to define CPU count for
>>>> each slave node.
>>>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>>>> vm_slave_cpu_default=1
>>>> vm_slave_cpu[1]=1
>>>> vm_slave_cpu[2]=1
>

Re: [openstack-dev] [fuel] Newton PTL and CL elections

[Dmitry Borodaenko]

On Thu, Mar 03, 2016 at 10:34:30AM +0100, Thierry Carrez wrote:
> Dmitry Borodaenko wrote:
> >Team,
> >
> >We're only two weeks away from the beginning of the Newton elections
> >period. Based on the Fuel 9.0/Mitaka release schedule [0], I propose the
> >following dates for PTL and CL self-nomination and election periods:
> >
> >PTL self-nomination: March 13-20
> >PTL election: March 21-27
> >CL self-nomination: March 28-April 3
> >CL election: April 4-10
> 
> Note that since Fuel is now an official project, the Fuel PTL election will
> be organized by the election officials (under the Technical Committee
> oversight).
> 
> Tentative dates have been posted here:
> http://git.openstack.org/cgit/openstack/election/tree/events.yaml

My apologies, should have done my homework better... For the reference,
here's the wiki page for PTL elections that I should have read:
https://wiki.openstack.org/wiki/PTL_Elections_March_2016

Updated dates based on openstack/election events.yaml:

PTL self-nomination: March 11-17
PTL election: March 18-24
CL self-nomination: March 25-31
CL election: April 1-7

Can we fit the component leads election into the same process (i.e.
component lead candidates would self-nominate by submitting
candidates///.txt files to
openstack/election)?

-- 
Dmitry Borodaenko

__
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] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Samer Machara]

Hi, Igor 
Thanks for answer so quickly. 

I wait until the following message appears 
Installation timed out! (3000 seconds) 
I don't have any virtual machines created. 

I update to 5.0 VirtualBox version, Now I got the following message 

VBoxManage: error: Machine 'fuel-master' is not currently running 
Waiting for product VM to download files. Please do NOT abort the script... 

I'm still waiting 

- Mail original -

De: "Maksim Malchuk"  
À: "OpenStack Development Mailing List (not for usage questions)" 
 
Envoyé: Vendredi 4 Mars 2016 15:19:54 
Objet: Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: 
error: Guest not running [ubuntu14.04] 

Igor, 



Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 

Samer can't run many guests I think. 


On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat < imar...@mirantis.com > wrote: 



Samer, Maksim, 
I'd rather say that script started fuel-master already (VM "fuel-master" has 
been successfully started.), didn't find running guests, (VBoxManage: error: 
Guest not running) but it can try to start them afterwards. 

Samer, 
- how many VMs are there running besides fuel-master? 
- is it still showing "Waiting for product VM to download files. Please do NOT 
abort the script..." ? 
- for how long did you wait since the message above? 


Regards, 
Igor Marnat 

On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com > wrote: 



Hi Sames, 

VBoxManage: error: Guest not running 

looks line the problem with VirtualBox itself or settings for the 'fuel-master' 
VM, it can't boot it. 
Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it 
manually - it should show you what is exactly happens. 


On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < 
samer.mach...@telecom-sudparis.eu > wrote: 





Hello, everyone. 
I'm new with Fuel. I'm trying to follow the QuickStart Guide ( 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), 
but I have the following Error: 


Waiting for VM "fuel-master" to power on... 
VM "fuel-master" has been successfully started. 
VBoxManage: error: Guest not running 
VBoxManage: error: Guest not running 
... 
VBoxManage: error: Guest not running 
Waiting for product VM to download files. Please do NOT abort the script... 


I hope you can help me. 

Thanks in advance 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 





I modify the config.sh to adapt my hardware configuration 
... 
# Master node settings 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_master_memory_mb=1024 
vm_master_disk_mb=2 
... 
# The number of nodes for installing OpenStack on 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
cluster_size=3 
... 
# Slave node settings. This section allows you to define CPU count for each 
slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_cpu_default=1 
vm_slave_cpu[1]=1 
vm_slave_cpu[2]=1 
vm_slave_cpu[3]=1 
... 
# This section allows you to define RAM size in MB for each slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_memory_default=1024 


vm_slave_memory_mb[1]=512 
vm_slave_memory_mb[2]=512 
vm_slave_memory_mb[3]=512 
... 
# Nodes with combined roles may require more disk space. 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_first_disk_mb=2 
vm_slave_second_disk_mb=2 
vm_slave_third_disk_mb=2 
... 


I found someone that had a similar problem ( 
https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html ), he 
had a corrupted iso file, he solved the problem downloaded it again. I 
downloaded the .iso file from 
http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
 . I chek the size 3,1 GB. How ever I still with the problem. 

__ 
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, 
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://

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Samer Machara]

Hi, Igor 
Thanks for answer so quickly. 

I wait until the following message appears 
Installation timed out! (3000 seconds) 
I don't have any virtual machines created. 

I update to 5.0 VirtualBox version, Now I got the following message 

VBoxManage: error: Machine 'fuel-master' is not currently running 
Waiting for product VM to download files. Please do NOT abort the script... 



- Mail original -

De: "Maksim Malchuk"  
À: "OpenStack Development Mailing List (not for usage questions)" 
 
Envoyé: Vendredi 4 Mars 2016 15:19:54 
Objet: Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: 
error: Guest not running [ubuntu14.04] 

Igor, 



Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 

Samer can't run many guests I think. 


On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat < imar...@mirantis.com > wrote: 



Samer, Maksim, 
I'd rather say that script started fuel-master already (VM "fuel-master" has 
been successfully started.), didn't find running guests, (VBoxManage: error: 
Guest not running) but it can try to start them afterwards. 

Samer, 
- how many VMs are there running besides fuel-master? 
- is it still showing "Waiting for product VM to download files. Please do NOT 
abort the script..." ? 
- for how long did you wait since the message above? 


Regards, 
Igor Marnat 

On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk < mmalc...@mirantis.com > wrote: 



Hi Sames, 

VBoxManage: error: Guest not running 

looks line the problem with VirtualBox itself or settings for the 'fuel-master' 
VM, it can't boot it. 
Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it 
manually - it should show you what is exactly happens. 


On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara < 
samer.mach...@telecom-sudparis.eu > wrote: 





Hello, everyone. 
I'm new with Fuel. I'm trying to follow the QuickStart Guide ( 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), 
but I have the following Error: 


Waiting for VM "fuel-master" to power on... 
VM "fuel-master" has been successfully started. 
VBoxManage: error: Guest not running 
VBoxManage: error: Guest not running 
... 
VBoxManage: error: Guest not running 
Waiting for product VM to download files. Please do NOT abort the script... 


I hope you can help me. 

Thanks in advance 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 





I modify the config.sh to adapt my hardware configuration 
... 
# Master node settings 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_master_memory_mb=1024 
vm_master_disk_mb=2 
... 
# The number of nodes for installing OpenStack on 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
cluster_size=3 
... 
# Slave node settings. This section allows you to define CPU count for each 
slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_cpu_default=1 
vm_slave_cpu[1]=1 
vm_slave_cpu[2]=1 
vm_slave_cpu[3]=1 
... 
# This section allows you to define RAM size in MB for each slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_memory_default=1024 


vm_slave_memory_mb[1]=512 
vm_slave_memory_mb[2]=512 
vm_slave_memory_mb[3]=512 
... 
# Nodes with combined roles may require more disk space. 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_first_disk_mb=2 
vm_slave_second_disk_mb=2 
vm_slave_third_disk_mb=2 
... 


I found someone that had a similar problem ( 
https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html ), he 
had a corrupted iso file, he solved the problem downloaded it again. I 
downloaded the .iso file from 
http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
 . I chek the size 3,1 GB. How ever I still with the problem. 

__ 
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, 
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.opens

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Maksim Malchuk]

Igor,

Some information about my system:
OS: ubuntu 14.04 LTS
Memory: 3,8GiB

Samer can't run many guests I think.


On Fri, Mar 4, 2016 at 5:12 PM, Igor Marnat  wrote:

> Samer, Maksim,
> I'd rather say that script started fuel-master already (VM "fuel-master"
> has been successfully started.), didn't find running guests, (VBoxManage:
> error: Guest not running) but it can try to start them afterwards.
>
> Samer,
> - how many VMs are there running besides fuel-master?
> - is it still showing "Waiting for product VM to download files. Please do
> NOT abort the script..." ?
> - for how long did you wait since the message above?
>
>
> Regards,
> Igor Marnat
>
> On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
> wrote:
>
>> Hi Sames,
>>
>> *VBoxManage: error: Guest not running*
>>
>> looks line the problem with VirtualBox itself or settings for the
>> 'fuel-master' VM, it can't boot it.
>> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start
>> it manually - it should show you what is exactly happens.
>>
>>
>> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
>> samer.mach...@telecom-sudparis.eu> wrote:
>>
>>> Hello, everyone.
>>> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
>>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
>>> but I have the following Error:
>>>
>>>
>>> *Waiting for VM "fuel-master" to power on...*
>>> *VM "fuel-master" has been successfully started.*
>>> *VBoxManage: error: Guest not running*
>>> *VBoxManage: error: Guest not running*
>>> ...
>>> *VBoxManage: error: Guest not running*
>>> *Waiting for product VM to download files. Please do NOT abort the
>>> script...*
>>>
>>>
>>>
>>> I hope you can help me.
>>>
>>> Thanks in advance
>>>
>>>
>>> Some information about my system:
>>> OS: ubuntu 14.04 LTS
>>> Memory: 3,8GiB
>>> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4
>>> OS type: 64-bit
>>> Disk 140,2GB
>>> VirtualBox Version: 4.3.36_Ubuntu
>>> Checking for 'expect'... OK
>>> Checking for 'xxd'... OK
>>> Checking for "VBoxManage"... OK
>>> Checking for VirtualBox Extension Pack... OK
>>> Checking if SSH client installed... OK
>>> Checking if ipconfig or ifconfig installed... OK
>>>
>>>
>>> I modify the config.sh to adapt my hardware configuration
>>> ...
>>> # Master node settings
>>> if [ "$CONFIG_FOR" = "4GB" ]; then
>>> vm_master_memory_mb=1024
>>> vm_master_disk_mb=2
>>> ...
>>> # The number of nodes for installing OpenStack on
>>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>>> cluster_size=3
>>> ...
>>> # Slave node settings. This section allows you to define CPU count for
>>> each slave node.
>>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>>> vm_slave_cpu_default=1
>>> vm_slave_cpu[1]=1
>>> vm_slave_cpu[2]=1
>>> vm_slave_cpu[3]=1
>>> ...
>>> # This section allows you to define RAM size in MB for each slave node.
>>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>>> vm_slave_memory_default=1024
>>>
>>> vm_slave_memory_mb[1]=512
>>> vm_slave_memory_mb[2]=512
>>> vm_slave_memory_mb[3]=512
>>> ...
>>> # Nodes with combined roles may require more disk space.
>>> if [ "$CONFIG_FOR" = "4GB" ]; then
>>> vm_slave_first_disk_mb=2
>>> vm_slave_second_disk_mb=2
>>> vm_slave_third_disk_mb=2
>>> ...
>>>
>>> I found someone that had a similar problem (
>>> https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html),
>>> he had a corrupted iso file, he solved the problem downloaded it again. I
>>> downloaded the .iso file from
>>> http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
>>> . I chek the size 3,1 GB. How ever I still with the problem.
>>>
>>>
>>> __
>>> 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,
>> 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
>>
>>
>
> __
> 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,
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.or

Re: [openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Igor Marnat]

Samer, Maksim,
I'd rather say that script started fuel-master already (VM "fuel-master"
has been successfully started.), didn't find running guests, (VBoxManage:
error: Guest not running) but it can try to start them afterwards.

Samer,
- how many VMs are there running besides fuel-master?
- is it still showing "Waiting for product VM to download files. Please do
NOT abort the script..." ?
- for how long did you wait since the message above?


Regards,
Igor Marnat

On Fri, Mar 4, 2016 at 5:04 PM, Maksim Malchuk 
wrote:

> Hi Sames,
>
> *VBoxManage: error: Guest not running*
>
> looks line the problem with VirtualBox itself or settings for the
> 'fuel-master' VM, it can't boot it.
> Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it
> manually - it should show you what is exactly happens.
>
>
> On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
> samer.mach...@telecom-sudparis.eu> wrote:
>
>> Hello, everyone.
>> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
>> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
>> but I have the following Error:
>>
>>
>> *Waiting for VM "fuel-master" to power on...*
>> *VM "fuel-master" has been successfully started.*
>> *VBoxManage: error: Guest not running*
>> *VBoxManage: error: Guest not running*
>> ...
>> *VBoxManage: error: Guest not running*
>> *Waiting for product VM to download files. Please do NOT abort the
>> script...*
>>
>>
>>
>> I hope you can help me.
>>
>> Thanks in advance
>>
>>
>> Some information about my system:
>> OS: ubuntu 14.04 LTS
>> Memory: 3,8GiB
>> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4
>> OS type: 64-bit
>> Disk 140,2GB
>> VirtualBox Version: 4.3.36_Ubuntu
>> Checking for 'expect'... OK
>> Checking for 'xxd'... OK
>> Checking for "VBoxManage"... OK
>> Checking for VirtualBox Extension Pack... OK
>> Checking if SSH client installed... OK
>> Checking if ipconfig or ifconfig installed... OK
>>
>>
>> I modify the config.sh to adapt my hardware configuration
>> ...
>> # Master node settings
>> if [ "$CONFIG_FOR" = "4GB" ]; then
>> vm_master_memory_mb=1024
>> vm_master_disk_mb=2
>> ...
>> # The number of nodes for installing OpenStack on
>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>> cluster_size=3
>> ...
>> # Slave node settings. This section allows you to define CPU count for
>> each slave node.
>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>> vm_slave_cpu_default=1
>> vm_slave_cpu[1]=1
>> vm_slave_cpu[2]=1
>> vm_slave_cpu[3]=1
>> ...
>> # This section allows you to define RAM size in MB for each slave node.
>> elif [ "$CONFIG_FOR" = "4GB" ]; then
>> vm_slave_memory_default=1024
>>
>> vm_slave_memory_mb[1]=512
>> vm_slave_memory_mb[2]=512
>> vm_slave_memory_mb[3]=512
>> ...
>> # Nodes with combined roles may require more disk space.
>> if [ "$CONFIG_FOR" = "4GB" ]; then
>> vm_slave_first_disk_mb=2
>> vm_slave_second_disk_mb=2
>> vm_slave_third_disk_mb=2
>> ...
>>
>> I found someone that had a similar problem (
>> https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html),
>> he had a corrupted iso file, he solved the problem downloaded it again. I
>> downloaded the .iso file from
>> http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
>> . I chek the size 3,1 GB. How ever I still with the problem.
>>
>> __
>> 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,
> 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
>
>
__
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] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Maksim Malchuk]

Hi Sames,

*VBoxManage: error: Guest not running*

looks line the problem with VirtualBox itself or settings for the
'fuel-master' VM, it can't boot it.
Open the VirtualBox Manger (GUI), select the 'fuel-master' VM and start it
manually - it should show you what is exactly happens.


On Fri, Mar 4, 2016 at 4:41 PM, Samer Machara <
samer.mach...@telecom-sudparis.eu> wrote:

> Hello, everyone.
> I'm new with Fuel. I'm trying to follow the QuickStart Guide (
> https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html),
> but I have the following Error:
>
>
> *Waiting for VM "fuel-master" to power on...*
> *VM "fuel-master" has been successfully started.*
> *VBoxManage: error: Guest not running*
> *VBoxManage: error: Guest not running*
> ...
> *VBoxManage: error: Guest not running*
> *Waiting for product VM to download files. Please do NOT abort the
> script...*
>
>
>
> I hope you can help me.
>
> Thanks in advance
>
>
> Some information about my system:
> OS: ubuntu 14.04 LTS
> Memory: 3,8GiB
> Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4
> OS type: 64-bit
> Disk 140,2GB
> VirtualBox Version: 4.3.36_Ubuntu
> Checking for 'expect'... OK
> Checking for 'xxd'... OK
> Checking for "VBoxManage"... OK
> Checking for VirtualBox Extension Pack... OK
> Checking if SSH client installed... OK
> Checking if ipconfig or ifconfig installed... OK
>
>
> I modify the config.sh to adapt my hardware configuration
> ...
> # Master node settings
> if [ "$CONFIG_FOR" = "4GB" ]; then
> vm_master_memory_mb=1024
> vm_master_disk_mb=2
> ...
> # The number of nodes for installing OpenStack on
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> cluster_size=3
> ...
> # Slave node settings. This section allows you to define CPU count for
> each slave node.
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_cpu_default=1
> vm_slave_cpu[1]=1
> vm_slave_cpu[2]=1
> vm_slave_cpu[3]=1
> ...
> # This section allows you to define RAM size in MB for each slave node.
> elif [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_memory_default=1024
>
> vm_slave_memory_mb[1]=512
> vm_slave_memory_mb[2]=512
> vm_slave_memory_mb[3]=512
> ...
> # Nodes with combined roles may require more disk space.
> if [ "$CONFIG_FOR" = "4GB" ]; then
> vm_slave_first_disk_mb=2
> vm_slave_second_disk_mb=2
> vm_slave_third_disk_mb=2
> ...
>
> I found someone that had a similar problem (
> https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html),
> he had a corrupted iso file, he solved the problem downloaded it again. I
> downloaded the .iso file from
> http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
> . I chek the size 3,1 GB. How ever I still with the problem.
>
> __
> 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,
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

[openstack-dev] [Fuel] [Openstack] Instalation Problem:VBoxManage: error: Guest not running [ubuntu14.04]

[Samer Machara]

Hello, everyone. 
I'm new with Fuel. I'm trying to follow the QuickStart Guide ( 
https://docs.fuel-infra.org/openstack/fuel/fuel-8.0/quickstart-guide.html ), 
but I have the following Error: 


Waiting for VM "fuel-master" to power on... 
VM "fuel-master" has been successfully started. 
VBoxManage: error: Guest not running 
VBoxManage: error: Guest not running 
... 
VBoxManage: error: Guest not running 
Waiting for product VM to download files. Please do NOT abort the script... 


I hope you can help me. 

Thanks in advance 




Some information about my system: 
OS: ubuntu 14.04 LTS 
Memory: 3,8GiB 
Processor: Intel® Core™2 Quad CPU Q9550 @ 2.83GHz × 4 
OS type: 64-bit 
Disk 140,2GB 
VirtualBox Version: 4.3.36_Ubuntu 
Checking for 'expect'... OK 
Checking for 'xxd'... OK 
Checking for "VBoxManage"... OK 
Checking for VirtualBox Extension Pack... OK 
Checking if SSH client installed... OK 
Checking if ipconfig or ifconfig installed... OK 





I modify the config.sh to adapt my hardware configuration 
... 
# Master node settings 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_master_memory_mb=1024 
vm_master_disk_mb=2 
... 
# The number of nodes for installing OpenStack on 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
cluster_size=3 
... 
# Slave node settings. This section allows you to define CPU count for each 
slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_cpu_default=1 
vm_slave_cpu[1]=1 
vm_slave_cpu[2]=1 
vm_slave_cpu[3]=1 
... 
# This section allows you to define RAM size in MB for each slave node. 
elif [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_memory_default=1024 


vm_slave_memory_mb[1]=512 
vm_slave_memory_mb[2]=512 
vm_slave_memory_mb[3]=512 
... 
# Nodes with combined roles may require more disk space. 
if [ "$CONFIG_FOR" = "4GB" ]; then 
vm_slave_first_disk_mb=2 
vm_slave_second_disk_mb=2 
vm_slave_third_disk_mb=2 
... 


I found someone that had a similar problem ( 
https://www.mail-archive.com/fuel-dev@lists.launchpad.net/msg01084.html ), he 
had a corrupted iso file, he solved the problem downloaded it again. I 
downloaded the .iso file from 
http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent
 . I chek the size 3,1 GB. How ever I still with the problem. 
__
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][plugins] Should we maintain example plugins?

[Stanislaw Bogatkin]

+1 to maintain example plugins. It is easy enough and really lowering
barriers for people who just begin create plugins.

On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn 
wrote:

> Igor,
>
> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> example plugin, add in the current Fuel release, and then build it. We
> maintained these plugins in the past, but now it should a manual step
> to test it out on the current release.
>
> What would be a more ideal situation that meets the needs of users and
> QA? Right now we have failed tests until we can decide on a solution
> that works for everybody.
>
> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky 
> wrote:
> > No, this is a wrong road to go.
> >
> > What if in Fuel 10 we drop v1 plugins support? What should we do?
> > Remove v1 example from source tree? That doesn't seem good to me.
> >
> > Example plugins are only examples. The list of supported releases must
> > be maintained on system test side, and system tests must inject that
> > information into plugin's metadata.yaml and test it.
> >
> > Again, I don't say we shouldn't test plugins. I say, tests should be
> > responsible for preparing plugins. I can say even more: tests should
> > not rely on what is produced by plugins, since it's something that
> > could be changed and tests start failing.
> >
> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
> wrote:
> >> IMHO it is important to keep plugin examples and keep testing them, very
> >> valuable for plugin developers.
> >>
> >> For example, I've encountered [0] the case where "plugin as role"
> feature
> >> wasn't easily testable with fuel-qa because not compliant with the last
> >> plugin data structure,
> >> and more recently we've spotted a regression [1] with "vip-reservation"
> >> feature introduced by a change in nailgun.
> >> These kind of issues are time consuming for plugin developers and
> can/must
> >> be avoided by testing them.
> >>
> >> I don't even understand why the question is raised while fuel plugins
> are
> >> supposed to be supported and more and more used [3], even by murano [4]
> ...
> >>
> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> [3]
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> [4] https://review.openstack.org/#/c/286310/
> >>
> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> >> wrote:
> >>>
> >>> Hi Fuelers,
> >>>
> >>> I would like to bring your attention a dilemma we have here. It seems
> >>> that there is a dispute as to whether we should maintain the releases
> >>> list for example plugins[0]. In this case, this is for adding version
> >>> 9.0 to the list.
> >>>
> >>> Right now, we run a swarm test that tries to install the example
> >>> plugin and do a deployment, but it's failing only for this reason. I
> >>> should add that this is the only automated daily test that will verify
> >>> that our plugin framework actually works. During the Mitaka
> >>> development  cycle, we already had an extended period where plugins
> >>> were broken[1]. Removing this test (or leaving it permanently red,
> >>> which is effectively the same), would raise the risk to any member of
> >>> the Fuel community who depends on plugins actually working.
> >>>
> >>> The other impact of abandoning maintenance of example plugins is that
> >>> it means that a given interested Fuel Plugin developer would not be
> >>> able to easily get started with plugin development. It might not be
> >>> inherently obvious to add the current Fuel release to the
> >>> metadata.yaml file and it would likely discourage such a user. In this
> >>> case, I would propose that we remove example plugins from fuel-plugins
> >>> GIT repo if they are not maintained. Non-functioning code is worse
> >>> than deleted code in my opinion.
> >>>
> >>> Please share your opinions and let's decide which way to go with this
> >>> bug[2]
> >>>
> >>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> >>> [2] https://launchpad.net/bugs/1548340
> >>>
> >>> Best Regards,
> >>> Matthew Mosesohn
> >>>
> >>>
> __
> >>> 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

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Matthew Mosesohn]

Igor,

It seems you are proposing an IKEA approach to plugins. Take Fuel's
example plugin, add in the current Fuel release, and then build it. We
maintained these plugins in the past, but now it should a manual step
to test it out on the current release.

What would be a more ideal situation that meets the needs of users and
QA? Right now we have failed tests until we can decide on a solution
that works for everybody.

On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky  wrote:
> No, this is a wrong road to go.
>
> What if in Fuel 10 we drop v1 plugins support? What should we do?
> Remove v1 example from source tree? That doesn't seem good to me.
>
> Example plugins are only examples. The list of supported releases must
> be maintained on system test side, and system tests must inject that
> information into plugin's metadata.yaml and test it.
>
> Again, I don't say we shouldn't test plugins. I say, tests should be
> responsible for preparing plugins. I can say even more: tests should
> not rely on what is produced by plugins, since it's something that
> could be changed and tests start failing.
>
> On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset  wrote:
>> IMHO it is important to keep plugin examples and keep testing them, very
>> valuable for plugin developers.
>>
>> For example, I've encountered [0] the case where "plugin as role" feature
>> wasn't easily testable with fuel-qa because not compliant with the last
>> plugin data structure,
>> and more recently we've spotted a regression [1] with "vip-reservation"
>> feature introduced by a change in nailgun.
>> These kind of issues are time consuming for plugin developers and can/must
>> be avoided by testing them.
>>
>> I don't even understand why the question is raised while fuel plugins are
>> supposed to be supported and more and more used [3], even by murano [4] ...
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> [3]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> [4] https://review.openstack.org/#/c/286310/
>>
>> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn 
>> wrote:
>>>
>>> Hi Fuelers,
>>>
>>> I would like to bring your attention a dilemma we have here. It seems
>>> that there is a dispute as to whether we should maintain the releases
>>> list for example plugins[0]. In this case, this is for adding version
>>> 9.0 to the list.
>>>
>>> Right now, we run a swarm test that tries to install the example
>>> plugin and do a deployment, but it's failing only for this reason. I
>>> should add that this is the only automated daily test that will verify
>>> that our plugin framework actually works. During the Mitaka
>>> development  cycle, we already had an extended period where plugins
>>> were broken[1]. Removing this test (or leaving it permanently red,
>>> which is effectively the same), would raise the risk to any member of
>>> the Fuel community who depends on plugins actually working.
>>>
>>> The other impact of abandoning maintenance of example plugins is that
>>> it means that a given interested Fuel Plugin developer would not be
>>> able to easily get started with plugin development. It might not be
>>> inherently obvious to add the current Fuel release to the
>>> metadata.yaml file and it would likely discourage such a user. In this
>>> case, I would propose that we remove example plugins from fuel-plugins
>>> GIT repo if they are not maintained. Non-functioning code is worse
>>> than deleted code in my opinion.
>>>
>>> Please share your opinions and let's decide which way to go with this
>>> bug[2]
>>>
>>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
>>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
>>> [2] https://launchpad.net/bugs/1548340
>>>
>>> Best Regards,
>>> Matthew Mosesohn
>>>
>>> __
>>> 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

__
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] Feature Freeze Exception Request - switching to CentOS-7.2

[Igor Marnat]

Dmitry, Aleksandra,
thank you for help and support!

Regards,
Igor Marnat

On Fri, Mar 4, 2016 at 1:20 AM, Aleksandra Fedorova 
wrote:

> As we agreed, we have switched ISO builds to latest CentOS 7.2 snapshots.
>
> You can see now that each ISO build (see for ex. [1]) produces several
> *_id.txt artifacts.
> Note that centos_mirror_id.txt points to CentOS snapshot at
> http://mirror.fuel-infra.org/pkgs/
>
> BVT test is stable, see [2], and nightly system tests results are
> basically the same as they were before.
>
>
> [1] https://ci.fuel-infra.org/job/9.0-community.all/3868/
> [2]
> https://ci.fuel-infra.org/view/ISO/job/9.0.fuel_community.ubuntu.bvt_2/
>
> On Thu, Mar 3, 2016 at 3:46 AM, Dmitry Borodaenko
>  wrote:
> > Thanks for the detailed explanation, very helpful!
> >
> > Considering that this change is atomic and easily revertable, lets
> > proceed with the change, the sooner we do that the more time we'll have
> > to confirm that there is no impact and revert if necessary.
> >
> > --
> > Dmitry Borodaenko
> >
> > On Thu, Mar 03, 2016 at 03:40:22AM +0300, Aleksandra Fedorova wrote:
> >> Hi,
> >>
> >> let me add some details about the change:
> >>
> >> 1) There are two repositories used to build Fuel ISO: base OS
> >> repository [1], and mos repository [2], where we put Fuel dependencies
> >> and packages we rebuild due to certain version requirements.
> >>
> >> The CentOS 7.2 feature is related to the upstream repo only. Packages
> >> like RabbitMQ, MCollective, Puppet, MySQL and PostgreSQL live in mos
> >> repository, which has higher priority then upstream.
> >>
> >> I think we need to setup a separate discussion about our policy
> >> regarding these packages, but for now they are fixed and won't be
> >> updated by CentOS 7.2 switch.
> >>
> >> 2) This change doesn't affect Fuel codebase.
> >>
> >> The upstream mirror we use for ISO build is controlled by environment
> >> variable which is set via Jenkins [3] and can be changed anytime.
> >>
> >> As we have daily snapshots of CentOS repository available at [4], in
> >> case of regression in upstream we can pin our builds to stable
> >> snapshot and work on the issue without blocking the main development
> >> flow.
> >
> > Please make sure that the current snapshot of CentOS 7.1 is not rotated
> > away so that we don't loose the point we can revert to.
> >
> >> 3) The "improve snapshotting" work item which is at the moment in
> >> progress, will prevent any possibility to "accidentally" migrate to
> >> CentOS 7.3, when it becomes available.
> >> Thus the only changes which we can fetch from upstream are changes
> >> which are published to updates/ component of CentOS 7.2 repo.
> >>
> >>
> >> As latest BVT on master is green
> >>https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/69/
> >> I think we should proceed with Jenkins reconfiguration [5] and switch
> >> to latest snapshots by default.
> >>
> >> [1] currently http://vault.centos.org/7.1.1503/
> >> [2]
> http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7-fuel/os/x86_64/
> >> [3]
> https://github.com/fuel-infra/jenkins-jobs/blob/76b5cdf1828b7db1957f7967180d20be099b0c63/common/scripts/all.sh#L84
> >> [4] http://mirror.fuel-infra.org/pkgs/
> >> [5] https://review.fuel-infra.org/#/c/17712/
> >>
> >> On Wed, Mar 2, 2016 at 9:22 PM, Mike Scherbakov
> >>  wrote:
> >> > It is not just about BVT. I'd suggest to monitor situation overall,
> >> > including failures of system tests [1]. If we see regressions there,
> or some
> >> > test cases will start flapping (what is even worse), then we'd have to
> >> > revert back to CentOS 7.1.
> >> >
> >> > [1] https://github.com/openstack/fuel-qa
> >> >
> >> > On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko <
> dborodae...@mirantis.com>
> >> > wrote:
> >> >>
> >> >> I agree with Mike's concerns, and propose to make these limitations
> (4
> >> >> weeks before FF for OS upgrades, 2 weeks for upgrades of key
> >> >> dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL,
> >> >> anything else?) official for 10.0/Newton.
> >> >>
> >> >> For 9.0/Mitaka, it is too late to impose them, so we just have to be
> >> >> very careful and conservative with this upgrade. First of all, we
> need
> >> >> to have a green BVT before and after switching to the CentOS 7.2 repo
> >> >> snapshot, so while I approved the spec, we can't move forward with
> this
> >> >> until BVT is green again, and right now it's red:
> >> >>
> >> >> https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/
> >> >>
> >> >> If we get it back to green but it becomes red after the upgrade, you
> >> >> must switch back to CentOS 7.1 *immediately*. If you are able to
> stick
> >> >> to this plan, there is still time to complete the transition today
> >> >> without requiring an FFE.
> >> >>
> >> >> --
> >> >> Dmitry Borodaenko
> >> >>
> >> >>
> >> >> On Wed, Mar 02, 2016 at 05:53:53PM +, Mike Scherbakov wrote:
> >> >> > Formally, we can merge it today. Historicall

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Igor Kalnitsky]

No, this is a wrong road to go.

What if in Fuel 10 we drop v1 plugins support? What should we do?
Remove v1 example from source tree? That doesn't seem good to me.

Example plugins are only examples. The list of supported releases must
be maintained on system test side, and system tests must inject that
information into plugin's metadata.yaml and test it.

Again, I don't say we shouldn't test plugins. I say, tests should be
responsible for preparing plugins. I can say even more: tests should
not rely on what is produced by plugins, since it's something that
could be changed and tests start failing.

On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset  wrote:
> IMHO it is important to keep plugin examples and keep testing them, very
> valuable for plugin developers.
>
> For example, I've encountered [0] the case where "plugin as role" feature
> wasn't easily testable with fuel-qa because not compliant with the last
> plugin data structure,
> and more recently we've spotted a regression [1] with "vip-reservation"
> feature introduced by a change in nailgun.
> These kind of issues are time consuming for plugin developers and can/must
> be avoided by testing them.
>
> I don't even understand why the question is raised while fuel plugins are
> supposed to be supported and more and more used [3], even by murano [4] ...
>
> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> [4] https://review.openstack.org/#/c/286310/
>
> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn 
> wrote:
>>
>> Hi Fuelers,
>>
>> I would like to bring your attention a dilemma we have here. It seems
>> that there is a dispute as to whether we should maintain the releases
>> list for example plugins[0]. In this case, this is for adding version
>> 9.0 to the list.
>>
>> Right now, we run a swarm test that tries to install the example
>> plugin and do a deployment, but it's failing only for this reason. I
>> should add that this is the only automated daily test that will verify
>> that our plugin framework actually works. During the Mitaka
>> development  cycle, we already had an extended period where plugins
>> were broken[1]. Removing this test (or leaving it permanently red,
>> which is effectively the same), would raise the risk to any member of
>> the Fuel community who depends on plugins actually working.
>>
>> The other impact of abandoning maintenance of example plugins is that
>> it means that a given interested Fuel Plugin developer would not be
>> able to easily get started with plugin development. It might not be
>> inherently obvious to add the current Fuel release to the
>> metadata.yaml file and it would likely discourage such a user. In this
>> case, I would propose that we remove example plugins from fuel-plugins
>> GIT repo if they are not maintained. Non-functioning code is worse
>> than deleted code in my opinion.
>>
>> Please share your opinions and let's decide which way to go with this
>> bug[2]
>>
>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
>> [2] https://launchpad.net/bugs/1548340
>>
>> Best Regards,
>> Matthew Mosesohn
>>
>> __
>> 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

Re: [openstack-dev] [Fuel] UI code freeze

[Vladimir Kozhukalov]

Vitaly,

As we decided yesterday custom job with fuel-ui and fuel-web refspec
parameters could help here. Is it not enough for our case? In general, the
case when two PRs depends on each other was deliberately denied to be
handled automatically. Please read this thread [1] for details.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-February/056515.html




Vladimir Kozhukalov

On Thu, Mar 3, 2016 at 7:01 PM, Vitaly Kramskikh 
wrote:

> Fuel UI code has been completely removed from fuel-web repo and CI jobs to
> verify fuel-web RR with fuel-ui code and fuel-ui RR with fuel-web code have
> been set up. So the code separation can be considered as done.
>
> Though there is one thing needs to be done and we don't know how to solve
> that task properly: how do we test and merge RRs to fuel-web and fuel-ui
> which are dependent on each other? Example of such RR:
> https://review.openstack.org/#/c/286547/. It has -1 from CI because this
> change needs to be tested against corresponding RR to fuel-web repo.
>
> If you have any ideas, feel free to tell us.
>
> 2016-03-01 16:09 GMT+07:00 Vitaly Kramskikh :
>
>> The new repo has been created: https://github.com/openstack/fuel-ui.
>> Please move all change requests there. Fuel UI code in fuel-web repo is
>> going to be removed soon.
>>
>> 2016-02-26 19:53 GMT+07:00 Vladimir Kozhukalov 
>> :
>>
>>> Dear colleagues,
>>>
>>> We are ready for moving UI javascript code to a separate git repository.
>>> Since now all review requests for fuel-web@master that are related to
>>> UI must be marked -2 and later abandoned. Once new project fuel-ui is
>>> created those changes should be backported to this new repository.
>>>
>>> Checklist:
>>>
>>>
>>>- Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
>>>- openstack-infra
>>>   - project-config https://review.openstack.org/#/c/260455 (ON
>>>   REVIEW)
>>>   - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
>>>- fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
>>>- label jenkins slaves for the new job (ci team)
>>>- UI directory freeze (DONE)
>>>- prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
>>>- waiting for openstack-infra patches to be merged
>>>- .gitreview .gitignore MAINTAINERS (TODO)
>>>- rpm spec (TODO)
>>>- custom ci jobs (TODO)
>>>- fuel-main (TODO)
>>>- packaging ci (TODO)
>>>- remove old files (TODO)
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> Mirantis, Inc.
>>
>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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
>
>
__
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][FFE] Enable UCA repositories for deployment

[Bogdan Dobrelya]

On 02.03.2016 16:27, Matthew Mosesohn wrote:
> Hi all,
> 
> I would like to request a feature freeze exception for "Deploy with
> UCA packages" feature.
> 
> I anticipate 2 more days to get tests green and add some depth to the
> existing test.

I vote to support this as that benefits community and makes Fuel more
versatile.

> 
> https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages
> 
> The impact to BVT stability is quite small because it only touches 1
> task in OpenStack deployment, and by default it is not enabled.
> 
> Open reviews:
> https://review.openstack.org/#/c/281762/
> https://review.openstack.org/#/c/279556/
> https://review.openstack.org/#/c/279542/
> https://review.openstack.org/#/c/284584/
> 
> Best Regards,
> Matthew Mosesohn
> 
> __
> 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,
Bogdan Dobrelya,
Irc #bogdando

__
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] [yaql] yaql.js

[Kirill Zaitsev]

(and thus port YAQL to JS)

FYI, you’re not the first one to have that idea. =)

We have https://review.openstack.org/#/c/159905/3 an initial draft of how YAQL 
may look on JS. It’s outdated, but most certainly can be revived and finished 
if you have interest in helping us make it happen. =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 2 March 2016 at 14:01:57, Vitaly Kramskikh (vkramsk...@mirantis.com) wrote:

Oh, so there is a spec. I was worried that this patch has 
"WIP-no-bprint-assigned-yet" string in the commit message, so I thought there 
is no spec for it. So the commit message should be updated to avoid such 
confusion.

It's really good I've seen this spec. There are plans to overhaul UI data 
format description which we use for cluster and node settings to solve some 
issues and implement long-awaited features like nested structures, so we might 
also want to deprecate our expression language and also switch to YAQL (and 
thus port YAQL to JS).

2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
Vitaly

Thanks for bringing this up. Actually the spec has been on review for almost 2 
weeks: https://review.openstack.org/#/c/282695/. Essentially, this is not 
introducing new DSL but replacing the existing one with more powerful 
extendable language which is being actively developed within OpenStack and is 
already a part of other projects (Murano, Mistral), which has much more 
contributors, can return not only boolean but any arbitrary collections. So it 
means that we want to deprecate current Expression language that you wrote and 
replace it with YAQL due to those reasons. You are not going to extend this 
Expression-based language in 3 weeks up to level of support of extensions, 
method overloading, return of arbitrary collections (e.g. we also want to 
calculate cross-depends and requires fields on the fly which require for it to 
return list of dicts) and support of this stuff on your own, are you?

On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh  
wrote:
I think it's not a part of best practices to introduce changes like 
https://review.openstack.org/#/c/279714/ (adding yet another DSL to the 
project) without a blueprint and review and discussion of the spec.

2016-03-02 2:19 GMT+07:00 Alexey Shtokolov :
Fuelers,

I would like to request a feature freeze exception for "Unlock settings tab" 
feature [0]

This feature being combined with Task-based deployment [1] and LCM-readiness 
for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We conducted a 
thorough redesign of this feature and splitted it into several granular changes 
[3]-[6] to allow users to change settings on deployed, partially deployed, 
stopped or erred clusters and further run redeployment using a particular graph 
(custom or calculated based on expected changes stored in DB) and with new 
parameters.

We need 3 weeks after FF to finish this feature.  
Risk of not delivering it after 3 weeks is low.

Patches on review or in progress:
https://review.openstack.org/#/c/284139/
https://review.openstack.org/#/c/279714/
https://review.openstack.org/#/c/286754/
https://review.openstack.org/#/c/286783/

Specs:
https://review.openstack.org/#/c/286713/
https://review.openstack.org/#/c/284797/
https://review.openstack.org/#/c/282695/
https://review.openstack.org/#/c/284250/


[0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
[1] https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
[2] https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
[3] https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
[4] https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
[5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
[6] https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database

--
---
WBR, Alexey Shtokolov

__
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




--
Vitaly Kramskikh,
Fuel UI Tech Lead,
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




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

Re: [openstack-dev] [fuel] Fuel 9.0/Mitaka is now in Feature Freeze

[Dmitry Borodaenko]

Following feature freeze exceptions were granted, ordered by their merge
deadline. See linked emails for additonal conditions attached to some of
these exceptions.

UCA, 3/10:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088309.html

Multipath disks, 3/10:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088282.html

LCM readyness for all deployment tasks, 3/15:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088310.html

HugePages, 3/16:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088292.html

Numa, 3/16:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088292.html

SR-IOV, 3/16:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088307.html

Decouple Fuel and OpenStack tasks, 3/20:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html

Remove conflicting openstack module parts, 3/20:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html

DPDK, 3/24:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088291.html

Unlock "Settings" Tab, 3/24:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088305.html

ConfigDB, 3/24:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088279.html

Osnailyfacter refactoring for Puppet Master compatibility, 3/24:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088308.html

All other feature changes will have to wait until Soft Code Freeze.

See IRC meeting minutes and log from #fuel-dev for more details:
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.html
http://irclog.perlgeek.de/fuel-dev/2016-03-03#i_12133112

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 10:31:09PM -0800, Dmitry Borodaenko wrote:
> Feature Freeze [0] for Fuel 9.0/Mitaka is now in effect. From this
> moment and until stable/mitaka branch is created at Soft Code Freeze,
> please do not merge feature related changes that have not received a
> feature freeze exception.
> 
> [0] https://wiki.openstack.org/wiki/FeatureFreeze
> 
> We will discuss all outstanding feature freeze exception requests in our
> weekly IRC meeting tomorrow [1]. If that discussion takes longer than
> the 1 hour time slot we have booked on #openstack-meeting-alt, we'll
> move the discussion to #fuel-dev and finish it there.
> 
> [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
> 
> The list of exceptions requested so far is exceedingly long and it is
> likely that most of these exceptions will be rejected. If you want your
> exception to be approved, please have the following information ready
> for the meeting:
> 
> 1) Link to design spec in fuel-specs, spec review status;
> 
> 2) Links to all outstanding commits for the feature;
> 
> 3) Dependencies between your change and other features: what will be
> broken or useless if your change is not merged, what else has to be
> merged for your change to work;
> 
> 4) Analysis of impact and risks mitigation plan: which components are
> affected by the change, what can break, how can impact be verified, how
> can the change be isolated;
> 
> 5) Status of test coverage: what can be tested, what's covered by
> automated tests, what's been tested so far (with links to test results).
> 
> -- 
> Dmitry Borodaenko

__
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] [FFE] LCM readiness for all deployment tasks

[Dmitry Borodaenko]

Granted, merge deadline March 15.

-- 
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 05:03:11PM +0100, Szymon Banka wrote:
> Hi All,
> 
> I’d like to request a Feature Freeze Exception for "LCM readiness for all 
> deployment tasks” [1] until Mar 11.
> 
> We need additional 1.5 week to finish and merge necessary changes which will 
> fix tasks in Fuel to be idempotent. That will be foundation and will enable 
> further development of LCM features.
> 
> More details about work being done: [2]
> 
> [1] https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
> [2] https://review.openstack.org/#/q/topic:bp/granular-task-idempotency,n,z
> 
> --
> Thanks,
> Szymon Bańka
> Mirantis
> http://www.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

Re: [openstack-dev] [Fuel][FFE] Enable UCA repositories for deployment

[Dmitry Borodaenko]

Granted, merge deadline March 10.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 06:27:32PM +0300, Matthew Mosesohn wrote:
> Hi all,
> 
> I would like to request a feature freeze exception for "Deploy with
> UCA packages" feature.
> 
> I anticipate 2 more days to get tests green and add some depth to the
> existing test.
> 
> https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages
> 
> The impact to BVT stability is quite small because it only touches 1
> task in OpenStack deployment, and by default it is not enabled.
> 
> Open reviews:
> https://review.openstack.org/#/c/281762/
> https://review.openstack.org/#/c/279556/
> https://review.openstack.org/#/c/279542/
> https://review.openstack.org/#/c/284584/
> 
> Best Regards,
> Matthew Mosesohn
> 
> __
> 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] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

[Dmitry Borodaenko]

Granted conditionally, design consensus deadline March 10, merge
deadline March 16 for patches that do not conflict with
fuel-openstack-tasks and fuel-remove-conflict-openstack, March 24 for
remaining patches.

If design consensus is not reached by March 10, the exception will be
revoked.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 07:01:02AM -0700, Scott Brimhall wrote:
> This is not possible to move to 10. This is a critical feature that
> our 2 largest customers are dependent on for deployment at the end of
> May. Puppet Master flat out will not work with a Fuel deployed
> environment without doing this unless we were to create our own
> composition layer, which would leave us with two separate code bases
> to maintain.  That isn't an option and this pretty much has to happen
> in 9.
> 
> ---
> Scott Brimhall, Cloud Architect
> Mirantis - Pure Play Openstack
> 
> > On Mar 2, 2016, at 02:01, Aleksandr Didenko  wrote:
> > 
> > Hi,
> > 
> > > Merging this code is relatively non-intrusive to core Fuel Library code
> > > as it is merely re-organizing the file structure of the osnailyfacter
> > > module to be compatible with Puppet Master. 
> > 
> > It looks like super-intrusive to me. Modular manifests are,
> > actually, the core of Fuel Library. And the majority of changes we
> > introduce in Fuel Library are proposed for those manifests. So if
> > you're going to move those manifests into "osnailyfacter::*" classes
> > then it will basically conflict with the 90% of other patches for
> > Fuel Library. This may slow down development of other features as
> > well as bug fixing.
> > 
> > Also I see no patches on review and spec is not yet accepted. I
> > think starting such an intrusive feature after FF is too risky,
> > let's move it to 10.0.
> > 
> > Regards,
> > Alex
> > 
> >> On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall  
> >> wrote:
> >> Greetings,
> >> 
> >> As you might know, we are working on integrating a 3rd party
> >> configuration management platform (Puppet Master) with Fuel.
> >> This integration will provide the capability for state enforcement
> >> and will further enable "day 2" operations of a Fuel-deployed site.
> >> We must refactor the 'osnailyfacter' module in Fuel Library to be
> >> compatible with both a masterful and masterless Puppet approach.
> >> 
> >> This change is required to enable a Puppet Master based LCM
> >> solution.
> >> 
> >> We request a FFE for this feature for 3 weeks, until Mar 24.  By that
> >> time, we will provide a tested solution in accordance with the following
> >> specifications [1].
> >> 
> >> The feature includes the following components:
> >> 
> >> 1. Refactor 'osnailyfacter' Fuel Library module to be compatible with
> >> Puppet Master by becoming a valid and compliant Puppet module.
> >> This involves moving manifests into the proper manifests directory
> >> and moving the contents into classes that can be included by Puppet
> >> Master.
> >> 2. Update deployment tasks to update their manifest path to the new
> >> location.
> >> 
> >> Merging this code is relatively non-intrusive to core Fuel Library code
> >> as it is merely re-organizing the file structure of the osnailyfacter
> >> module to be compatible with Puppet Master.  Upon updating the
> >> deployment tasks to reflect the new location of manifests, this feature
> >> remains compatible with the masterless puppet apply approach that
> >> Fuel uses while providing the ability to integrate a Puppet Master
> >> based LCM solution.
> >> 
> >> Overall, I consider this change as low risk for integrity and timeline of
> >> the release and it is a critical feature for the ability to integrate an 
> >> LCM
> >> solution using Puppet Master.
> >> 
> >> Please consider our request and share concerns so we can properly
> >> resolve them.
> >> 
> >> [1] 
> >> https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility
> >> 
> >> ---
> >> Best Regards,
> >> 
> >> Scott Brimhall
> >> Systems Architect
> >> 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
> > 
> > __
> > 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


__
Ope

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

[Dmitry Borodaenko]

Granted, merge deadline March 24, task history part of the feature is to
be excluded from this exception grant unless a consensus is reached by
March 10.

Relevant part of the meeting log starts at:
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
> Oh, so there is a spec. I was worried that this patch has
> "WIP-no-bprint-assigned-yet" string in the commit message, so I thought
> there is no spec for it. So the commit message should be updated to avoid
> such confusion.
> 
> It's really good I've seen this spec. There are plans to overhaul UI data
> format description which we use for cluster and node settings to solve some
> issues and implement long-awaited features like nested structures, so we
> might also want to deprecate our expression language and also switch to
> YAQL (and thus port YAQL to JS).
> 
> 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
> 
> > Vitaly
> >
> > Thanks for bringing this up. Actually the spec has been on review for
> > almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially,
> > this is not introducing new DSL but replacing the existing one with more
> > powerful extendable language which is being actively developed within
> > OpenStack and is already a part of other projects (Murano, Mistral), which
> > has much more contributors, can return not only boolean but any arbitrary
> > collections. So it means that we want to deprecate current Expression
> > language that you wrote and replace it with YAQL due to those reasons. You
> > are not going to extend this Expression-based language in 3 weeks up to
> > level of support of extensions, method overloading, return of arbitrary
> > collections (e.g. we also want to calculate cross-depends and requires
> > fields on the fly which require for it to return list of dicts) and support
> > of this stuff on your own, are you?
> >
> > On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh  > > wrote:
> >
> >> I think it's not a part of best practices to introduce changes like
> >> https://review.openstack.org/#/c/279714/ (adding yet another DSL to the
> >> project) without a blueprint and review and discussion of the spec.
> >>
> >> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov :
> >>
> >>> Fuelers,
> >>>
> >>> I would like to request a feature freeze exception for "Unlock settings
> >>> tab" feature [0]
> >>>
> >>> This feature being combined with Task-based deployment [1] and
> >>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We
> >>> conducted a thorough redesign of this feature and splitted it into several
> >>> granular changes [3]-[6] to allow users to change settings on deployed,
> >>> partially deployed, stopped or erred clusters and further run redeployment
> >>> using a particular graph (custom or calculated based on expected changes
> >>> stored in DB) and with new parameters.
> >>>
> >>> We need 3 weeks after FF to finish this feature.
> >>> Risk of not delivering it after 3 weeks is low.
> >>>
> >>> Patches on review or in progress:
> >>> 
> >>> https://review.openstack.org/#/c/284139/
> >>> https://review.openstack.org/#/c/279714/
> >>> https://review.openstack.org/#/c/286754/
> >>> https://review.openstack.org/#/c/286783/
> >>>
> >>> Specs:
> >>> https://review.openstack.org/#/c/286713/
> >>> https://review.openstack.org/#/c/284797/
> >>> https://review.openstack.org/#/c/282695/
> >>> https://review.openstack.org/#/c/284250/
> >>>
> >>>
> >>> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
> >>> [1]
> >>> https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
> >>> [2]
> >>> https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
> >>> [3]
> >>> https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
> >>> [4]
> >>> https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
> >>> [5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
> >>> [6]
> >>> https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database
> >>>
> >>> --
> >>> ---
> >>> WBR, Alexey Shtokolov
> >>>
> >>>
> >>> __
> >>> 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
> >>>
> >>>
> >>
> >>
> >> --
> >> Vitaly Kramskikh,
> >> Fuel UI Tech Lead,
> >> 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/mai

Re: [openstack-dev] [Fuel] [FFE] FF exception request for SR-IOV

[Dmitry Borodaenko]

Granted, merge deadline March 16, feature to be marked experimental
until QA has signed off that it's fully tested and stable. 

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 01:40:26PM +0200, Aleksey Kasatkin wrote:
> > And we need to write a new patch for:
> https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov
> 
> It is on review now: https://review.openstack.org/286704
> 
> Complete list of patches on review:
> https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov
> 
> 
> 
> Aleksey Kasatkin
> 
> 
> On Tue, Mar 1, 2016 at 6:27 PM, Aleksandr Didenko 
> wrote:
> 
> > Hi,
> >
> > I'd like to to request a feature freeze exception for "Support for SR-IOV
> > for improved networking performance" feature [0].
> >
> > Part of this feature is already merged [1]. We have the following patches
> > in work / on review:
> >
> > https://review.openstack.org/280782
> > https://review.openstack.org/284603
> > https://review.openstack.org/286633
> >
> > And we need to write a new patch for:
> > https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov
> >
> > We need 2 weeks at most after FF to accomplish this.
> > Risk of not delivering it after 2 weeks is very low.
> >
> > Regards,
> > Alex
> >
> > [0] https://blueprints.launchpad.net/fuel/+spec/support-sriov
> > [1]
> > https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-sriov
> >
> >
> > __
> > 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

Re: [openstack-dev] [Fuel] [FFE] Component registry improvements

[Dmitry Borodaenko]

Denied.

A fairly large patch with potentially intrusive refactoring that is not
required for any other features. We can safely postpone this until
Newton.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 11:05:52AM +0200, Andriy Popovych wrote:
> Hi,
> 
> I would like to request a feature freeze exception for "Component
> registry improvements" feature [0]
> 
> It's related only with components and hasn't any impact on other Fuel
> parts. We have 2 patches [1], [2] which currently on review but
> blocked with CI issue due separation of fuel-web and fuel-ui parts.
> 
> We need no more than 1 week to finish review.
> 
> [0] 
> https://blueprints.launchpad.net/fuel/+spec/component-registry-improvements
> [1] https://review.openstack.org/#/c/282911/
> [2] https://review.openstack.org/#/c/286547/
> 
> __
> 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] [Fuel][Upgrade][FFE] Reassigning Nodes without Re-Installation

[Dmitry Borodaenko]

Denied.

This came in very late (patch remained in WIP until 1 day before FF),
covers a corner case, there was not enough risk analysis, it wasn't
represented in the IRC meeting earlier today, and the spec for the
high-level feature is sitting with a -1 from fuel-python component lead
since 1.5 weeks ago.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 12:02:17AM -0600, Ilya Kharin wrote:
> I'd like to request a feature freeze exception for Reassigning Nodes
> without Re-Installation [1].
> 
> This feature is very important to several upgrade strategies that re-deploy
> control plane nodes, alongside of re-using some already deployed nodes,
> such as computes nodes or storage nodes. These changes affect only the
> upgrade part of Nailgun that mostly implemented in the cluster_upgrade
> extension and do not affect both the provisioning and the deployment.
> 
> I need one week to finish implementation and testing.
> 
> [1] https://review.openstack.org/#/c/280067/ (review in progress)
> 
> Best regards,
> Ilya Kharin.
> 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


__
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][FFE] Remove conflicting openstack module parts

[Dmitry Borodaenko]

Granted, merge deadline 3/20.

-- 
Dmitry Borodaenko

On Tue, Mar 01, 2016 at 11:26:57PM +, Andrew Woodward wrote:
> I'd like to request a feature freeze exception for the Remove conflicting
> openstack module parts feature [0]
> 
> This is necessary to make the feature Decouple Fuel and OpenStack tasks
> feature useful [1] , some of the patches are ready for review and some
> still need to be written [2]
> 
> We need 2 - 3 weeks after FF to finish this feature. Risk of not delivering
> it after 3 weeks is low.
> 
> [0]
> https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack
> [1] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
> [2]
> https://review.openstack.org/#/q/topic:bp/fuel-remove-conflict-openstack,n,z
> -- 
> 
> --
> 
> 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


__
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][FFE] Decouple Fuel and OpenStack tasks

[Dmitry Borodaenko]

Granted, merge deadline 3/20.

-- 
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 10:07:55PM +, Andrew Woodward wrote:
> I'd like to request a feature freeze exception for Decouple Fuel and
> OpenStack tasks feature [0].
> 
> While the code change [1] is ready and usually passing CI we have too much
> churn in the tasks currently which puts the patch set in conflict
> constantly so it has to be rebased multiple times a day.
> 
> We need more review and feedback on the change, and a quiet period to merge
> it
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
> [1] https://review.openstack.org/#/c/283332/
> -- 
> 
> --
> 
> 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


__
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][FFE] FF exception request for non-root accounts on slave nodes

[Dmitry Borodaenko]

Denied.

Most of this feature has landed before FF as expected, the rest can wait
until Newton. At least, operators who want to disable root access to
target nodes are now able to do so, with some exceptions and some
additional manual tweaking that we should clean up in the next release.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 12:28:31AM +0300, Dmitry Nikishov wrote:
> Hello,
> 
> I'd like to request a FF exception for "Run Fuel slave nodes as non-root"
> feature[1].
> 
> Current status:
> larger part of the feature is already merged[2] and some more
> patches[3][4][5][6] are expected to land before the FF.
> 
> When these patches are in the master, Fuel 9.0 will be able to create
> non-root accounts on target nodes, however, root SSH will still be enabled.
> To change that we'll need actually to
> - Fix fuel-qa to be able to use non-root accounts [7].
> - Fix ceph deployment by either merging [8] or waiting for community ceph
> module support.
> - Disable root SSH [9].
> 
> For that, we need 2.5 weeks after the FF to finish the feature. Risk of not
> delivering the feature after 2.5 weeks is low.
> 
> Thanks.
> 
> [1] https://blueprints.launchpad.net/fuel/+spec/fuel-nonroot-openstack-nodes
> [2]
> https://review.openstack.org/#/q/status:merged+topic:bp-fuel-nonsuperuser
> [3] https://review.openstack.org/258200
> [4] https://review.openstack.org/284682
> [5] https://review.openstack.org/285299
> [6] https://review.openstack.org/258671
> [7] https://review.openstack.org/281776
> [8] https://review.openstack.org/278953
> [9] https://review.openstack.org/278954
> -- 
> Dmitry Nikishov,
> Deployment Engineer,
> 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


__
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][FFE] Multi-release packages

[Dmitry Borodaenko]

Denied.

This change is likely to require a Nailgun DB schema change, and can
benefit from more design discussions.

-- 
Dmitry Borodaenko

On Tue, Mar 01, 2016 at 11:00:24PM +0300, Alexey Shtokolov wrote:
> Fuelers,
> 
> I would like to request a feature freeze exception for "Multi-release
> packages" feature [0][1]
> 
> This feature extends already existing multi-release support in Fuel Plugins.
> We would like to allow plugin developers to specify all plugin components
> per release and distribute different deployment graphs, partitioning
> schemas, network and node roles for each release in one package.
> 
> This feature is not blocker for us, but it provides very important
> improvement of users and plugin developers experience.
> 
> We need 3 weeks after FF to finish this feature.
> Risk of not delivering it after 3 weeks is low.
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/plugins-v5
> [1] https://review.openstack.org/#/c/271417
> ---
> WBR, Alexey Shtokolov

> __
> 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] [Fuel][FFE] FF exception request for Numa and CPU pinning

[Dmitry Borodaenko]

Granted, merge deadline March 16, feature to be marked experimental
until QA has signed off that it's fully tested and stable.

-- 
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 10:23:08PM +0300, Dmitry Klenov wrote:
> Hi,
> 
> I'd like to to request a feature freeze exception for "Add support for
> NUMA/CPU pinning features" feature [0].
> 
> Part of this feature is already merged [1]. We have the following patches
> in work / on review:
> 
> https://review.openstack.org/#/c/281802/
> https://review.openstack.org/#/c/285282/
> https://review.openstack.org/#/c/284171/
> https://review.openstack.org/#/c/280624/
> https://review.openstack.org/#/c/280115/
> https://review.openstack.org/#/c/285309/
> 
> No new patches are expected.
> 
> We need 2 weeks after FF to finish this feature.
> Risk of not delivering it after 2 weeks is low.
> 
> Regards,
> Dmitry
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/support-numa-cpu-pinning
> [1]
> https://review.openstack.org/#/q/status:merged+topic:bp/support-numa-cpu-pinning

> __
> 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] [Fuel][FFE] FF exception request for HugePages

[Dmitry Borodaenko]

Granted, merge deadline March 16, feature to be marked experimental
until QA has signed off that it's fully tested and stable.

-- 
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 10:23:06PM +0300, Dmitry Klenov wrote:
> Hi,
> 
> I'd like to to request a feature freeze exception for "Support for Huge
> pages for improved performance" feature [0].
> 
> Part of this feature is already merged [1]. We have the following patches
> in work / on review:
> 
> https://review.openstack.org/#/c/286628/
> https://review.openstack.org/#/c/282367/
> https://review.openstack.org/#/c/286495/
> 
> And we need to write new patches for the following parts of this feature:
> https://blueprints.launchpad.net/fuel/+spec/support-hugepages
> 
> We need 1.5 weeks after FF to finish this feature.
> Risk of not delivering it after 1.5 weeks is low.
> 
> Regards,
> Dmitry
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/support-hugepages
> [1]
> https://review.openstack.org/#/q/status:merged+topic:bp/support-hugepages

> __
> 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] [Fuel] [FFE] FF exception request for DPDK

[Dmitry Borodaenko]

Granted, merge deadline March 24, feature to be marked experimental
until QA has signed off that it's fully tested and stable.

-- 
Dmitry Borodaenko


On Thu, Mar 03, 2016 at 05:27:11PM +0300, Vladimir Eremin wrote:
> Hi,
> 
> All patches for DPDK feature [1] are on review, new patches are not expected:
> * https://review.openstack.org/286611 Support for DPDK enablement on node 
> interfaces
> * https://review.openstack.org/284283 Add DPDK support for node interfaces
> 
> For DPDK bonding [2]:
> * https://review.openstack.org/287410 Added dpdkovs provider for bond
> 
> For network verifications [3]:
> * https://review.openstack.org/287806 Network verification for DPDK enabled 
> interfaces
> 
> [1]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk
> [2]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond
> [3]: https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk
> 
> -- 
> With best regards,
> Vladimir Eremin,
> Fuel Deployment Engineer,
> Mirantis, Inc.
> 
> 
> 
> > On Mar 1, 2016, at 7:27 PM, Aleksandr Didenko  wrote:
> > 
> > Hi,
> > 
> > I'd like to to request a feature freeze exception for "Support for DPDK for 
> > improved networking performance" feature [0].
> > 
> > Part of this feature is already merged [1]. We have the following patches 
> > in work / on review:
> > 
> > https://review.openstack.org/281827
> > https://review.openstack.org/283044
> > https://review.openstack.org/286595
> > https://review.openstack.org/284285
> > https://review.openstack.org/284283
> > https://review.openstack.org/286611
> > 
> > And we need to write new patches for the following parts of this feature:
> > https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk
> > https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond
> > 
> > We need 3 weeks after FF to finish this feature.
> > Risk of not delivering it after 3 weeks is low.
> > 
> > Regards,
> > Alex
> > 
> > [0] https://blueprints.launchpad.net/fuel/+spec/support-dpdk
> > [1] 
> > https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-dpdk
> > __
> > 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

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

[Aleksandra Fedorova]

As we agreed, we have switched ISO builds to latest CentOS 7.2 snapshots.

You can see now that each ISO build (see for ex. [1]) produces several
*_id.txt artifacts.
Note that centos_mirror_id.txt points to CentOS snapshot at
http://mirror.fuel-infra.org/pkgs/

BVT test is stable, see [2], and nightly system tests results are
basically the same as they were before.


[1] https://ci.fuel-infra.org/job/9.0-community.all/3868/
[2]
https://ci.fuel-infra.org/view/ISO/job/9.0.fuel_community.ubuntu.bvt_2/

On Thu, Mar 3, 2016 at 3:46 AM, Dmitry Borodaenko
 wrote:
> Thanks for the detailed explanation, very helpful!
>
> Considering that this change is atomic and easily revertable, lets
> proceed with the change, the sooner we do that the more time we'll have
> to confirm that there is no impact and revert if necessary.
>
> --
> Dmitry Borodaenko
>
> On Thu, Mar 03, 2016 at 03:40:22AM +0300, Aleksandra Fedorova wrote:
>> Hi,
>>
>> let me add some details about the change:
>>
>> 1) There are two repositories used to build Fuel ISO: base OS
>> repository [1], and mos repository [2], where we put Fuel dependencies
>> and packages we rebuild due to certain version requirements.
>>
>> The CentOS 7.2 feature is related to the upstream repo only. Packages
>> like RabbitMQ, MCollective, Puppet, MySQL and PostgreSQL live in mos
>> repository, which has higher priority then upstream.
>>
>> I think we need to setup a separate discussion about our policy
>> regarding these packages, but for now they are fixed and won't be
>> updated by CentOS 7.2 switch.
>>
>> 2) This change doesn't affect Fuel codebase.
>>
>> The upstream mirror we use for ISO build is controlled by environment
>> variable which is set via Jenkins [3] and can be changed anytime.
>>
>> As we have daily snapshots of CentOS repository available at [4], in
>> case of regression in upstream we can pin our builds to stable
>> snapshot and work on the issue without blocking the main development
>> flow.
>
> Please make sure that the current snapshot of CentOS 7.1 is not rotated
> away so that we don't loose the point we can revert to.
>
>> 3) The "improve snapshotting" work item which is at the moment in
>> progress, will prevent any possibility to "accidentally" migrate to
>> CentOS 7.3, when it becomes available.
>> Thus the only changes which we can fetch from upstream are changes
>> which are published to updates/ component of CentOS 7.2 repo.
>>
>>
>> As latest BVT on master is green
>>https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/69/
>> I think we should proceed with Jenkins reconfiguration [5] and switch
>> to latest snapshots by default.
>>
>> [1] currently http://vault.centos.org/7.1.1503/
>> [2] 
>> http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7-fuel/os/x86_64/
>> [3] 
>> https://github.com/fuel-infra/jenkins-jobs/blob/76b5cdf1828b7db1957f7967180d20be099b0c63/common/scripts/all.sh#L84
>> [4] http://mirror.fuel-infra.org/pkgs/
>> [5] https://review.fuel-infra.org/#/c/17712/
>>
>> On Wed, Mar 2, 2016 at 9:22 PM, Mike Scherbakov
>>  wrote:
>> > It is not just about BVT. I'd suggest to monitor situation overall,
>> > including failures of system tests [1]. If we see regressions there, or 
>> > some
>> > test cases will start flapping (what is even worse), then we'd have to
>> > revert back to CentOS 7.1.
>> >
>> > [1] https://github.com/openstack/fuel-qa
>> >
>> > On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko 
>> > 
>> > wrote:
>> >>
>> >> I agree with Mike's concerns, and propose to make these limitations (4
>> >> weeks before FF for OS upgrades, 2 weeks for upgrades of key
>> >> dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL,
>> >> anything else?) official for 10.0/Newton.
>> >>
>> >> For 9.0/Mitaka, it is too late to impose them, so we just have to be
>> >> very careful and conservative with this upgrade. First of all, we need
>> >> to have a green BVT before and after switching to the CentOS 7.2 repo
>> >> snapshot, so while I approved the spec, we can't move forward with this
>> >> until BVT is green again, and right now it's red:
>> >>
>> >> https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/
>> >>
>> >> If we get it back to green but it becomes red after the upgrade, you
>> >> must switch back to CentOS 7.1 *immediately*. If you are able to stick
>> >> to this plan, there is still time to complete the transition today
>> >> without requiring an FFE.
>> >>
>> >> --
>> >> Dmitry Borodaenko
>> >>
>> >>
>> >> On Wed, Mar 02, 2016 at 05:53:53PM +, Mike Scherbakov wrote:
>> >> > Formally, we can merge it today. Historically, every update of OS caused
>> >> > us
>> >> > instability for some time: from days to a couple of month.
>> >> > Taking this into account and number of other exceptions requested,
>> >> > overall
>> >> > stability of code, my opinion would be to postpone this to 10.0.
>> >> >
>> >> > Also, I'd suggest to change the process, and have freeze date for all OS
>> >> > update

Re: [openstack-dev] [Fuel][FFE] Use RGW as a default object store instead of Swift

[Dmitry Borodaenko]

Denied.

This is a major functional change and it needs a lot more discussion
than a single review posted 2 days before Feature Freeze. Lets start
this discussion now, summarize its result in a spec, and see if it's
something we want to target for Newton.

-- 
Dmitry Borodaenko


On Wed, Mar 02, 2016 at 03:50:45PM +0200, Konstantin Danilov wrote:
> Igor,
> 
> You are right. I have updated a request -
> https://review.openstack.org/287195
> 
> Thanks.
> 
> On Tue, Mar 1, 2016 at 6:01 PM, Igor Kalnitsky 
> wrote:
> 
> > Hey Konstantin,
> >
> > I see that provided patch [1] is for stable/8.0. Fuel 8.0 is recently
> > released and we usually do not accept any features to stable branch.
> >
> > Or your meant that patch for master branch?
> >
> > Thanks,
> > Igor
> >
> > [1]: https://review.openstack.org/#/c/286100/
> >
> > On Tue, Mar 1, 2016 at 4:44 PM, Konstantin Danilov
> >  wrote:
> > > Colleagues,
> > > I would like to request a feature freeze exception for
> > > 'Use RGW as a default object store instead of Swift' [1].
> > >
> > > To merge the changes we need at most one week of time.
> > >
> > > [1]: https://review.openstack.org/#/c/286100/
> > >
> > > Thanks
> > > --
> > >
> > > Kostiantyn Danilov aka koder.ua
> > > Principal software engineer, Mirantis
> > >
> > > skype:koder.ua
> > > http://koder-ua.blogspot.com/
> > > http://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
> >
> 
> 
> 
> -- 
> Kostiantyn Danilov aka koder.ua
> Principal software engineer, Mirantis
> 
> skype:koder.ua
> http://koder-ua.blogspot.com/
> http://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

Re: [openstack-dev] [Fuel] [FFE] Add multipath disks support

[Dmitry Borodaenko]

Granted, merge deadline March 10.

On Tue, Mar 01, 2016 at 04:27:50PM +0100, Szymon Banka wrote:
> Hi All,
> 
> I’d like to request a Feature Freeze Exception for "Add multipath disks 
> support” until Mar 9.
> This feature allows to use FC multipath disks in Fuel nodes – BP [1], spec 
> [2].
> 
> Development is already done and we need following patches still to be merged:
> review and merge multipath support in fuel-agent [3]
> review and merge multipath support railgun-agent [4]
> [1] https://blueprints.launchpad.net/fuel/+spec/multipath-disks-support
> [2] https://review.openstack.org/#/c/276745/
> [3] https://review.openstack.org/#/c/285340/
> [4] https://review.openstack.org/#/c/282552/
> 
> --
> Thanks,
> Szymon Bańka
> Mirantis
> http://www.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

Re: [openstack-dev] [Fuel] [FFE] Use packetary for building ISO

[Dmitry Borodaenko]

On Thu, Mar 03, 2016 at 11:21:58PM +0800, Thomas Goirand wrote:
> On 03/03/2016 07:14 PM, Aleksey Zvyagintsev wrote:
> > Hello team's ,
> > Please take in mind my HUGE +1
> > We really need to remove package building process from iso build flow.
> Same point of view over here. Let's get rid of the "make world" approach
> ASAP.

Denied.

Apologies, but the risk of build process changes impacting development
and bugfixing in other components is too great. I realize that it's
almost done and it's a transition we've all been eagerly anticipating
for a long while, we'll just have to wait a little bit longer. Right
after SCF is a much better time and place for these kinds of changes.

-- 
Dmitry Borodaenko

__
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] FFE request for ConfigDB service

[Dmitry Borodaenko]

Granted, merge deadline March 24, no impact expected in core components
(fuel-library, fuel-web, fuel-ui).

-- 
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 04:22:05PM +0300, Oleg Gelbukh wrote:
> Greetings,
> 
> As you might know, we are working on centralised storage for
> deployment configuration data in Fuel. Such store will allow external
> 3rd-party services to consume the entirety of settings provided by
> Fuel to deployment mechanisms on target nodes. It will also allow to
> manage and override the settings via simple client application.
> 
> This change is required to enable Puppet Master based LCM solution.
> 
> We request a FFE for this feature for 3 weeks, until Mar 24. By that
> time, we will provide tested solution in accordance with the following
> specifications [1] [2]
> 
> The feature includes 3 main components:
> 1. Extension to Nailgun API with separate DB structure to store serialized 
> data
> 2. Backend library for Hiera to consume the API in question to lookup
> values of the certain parameters
> 3. Astute task to download all serialized data from nodes and upload
> them to ConfigDB API upon successful deployment of cluster
> 
> Since introduction of stevedore-based extensions [3], we could develop
> extensions in separate code repos. This makes change to Nailgun
> non-intrusive to core code.
> Backend library will be implemented in fuel-library code tree and
> packaged as a sub-package. This change also doesn't require changes in
> the core code.
> Astute task will add a task in the flow. We will make this task
> configurable, i.e. normally this code path won't be used at all. It
> also won't touch core code of Astute.
> 
> Overall, I consider this change as low risk for integrity and timeline
> of the release.
> 
> Please, consider our request and share concerns so we could properly
> resolve them.
> 
> [1] 
> https://blueprints.launchpad.net/fuel/+spec/upload-deployment-facts-to-configdb
> [2] https://blueprints.launchpad.net/fuel/+spec/serialized-facts-nailgun-api
> [3] https://blueprints.launchpad.net/fuel/+spec/stevedore-extensions-discovery
> 
> --
> Best regards,
> Oleg Gelbukh
> 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

__
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][plugins] Should we maintain example plugins?

[Swann Croiset]

IMHO it is important to keep plugin examples and keep testing them, very
valuable for plugin developers.

For example, I've encountered [0] the case where "plugin as role" feature
wasn't easily testable with fuel-qa because not compliant with the last
plugin data structure,
and more recently we've spotted a regression [1] with "vip-reservation"
feature introduced by a change in nailgun.
These kind of issues are time consuming for plugin developers and can/must
be avoided by testing them.

I don't even understand why the question is raised while fuel plugins are
supposed to be supported and more and more used [3], even by murano [4] ...

[0] https://bugs.launchpad.net/fuel/+bug/1543962
[1] https://bugs.launchpad.net/fuel/+bug/1551320
[3]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
[4] https://review.openstack.org/#/c/286310/

On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn 
wrote:

> Hi Fuelers,
>
> I would like to bring your attention a dilemma we have here. It seems
> that there is a dispute as to whether we should maintain the releases
> list for example plugins[0]. In this case, this is for adding version
> 9.0 to the list.
>
> Right now, we run a swarm test that tries to install the example
> plugin and do a deployment, but it's failing only for this reason. I
> should add that this is the only automated daily test that will verify
> that our plugin framework actually works. During the Mitaka
> development  cycle, we already had an extended period where plugins
> were broken[1]. Removing this test (or leaving it permanently red,
> which is effectively the same), would raise the risk to any member of
> the Fuel community who depends on plugins actually working.
>
> The other impact of abandoning maintenance of example plugins is that
> it means that a given interested Fuel Plugin developer would not be
> able to easily get started with plugin development. It might not be
> inherently obvious to add the current Fuel release to the
> metadata.yaml file and it would likely discourage such a user. In this
> case, I would propose that we remove example plugins from fuel-plugins
> GIT repo if they are not maintained. Non-functioning code is worse
> than deleted code in my opinion.
>
> Please share your opinions and let's decide which way to go with this
> bug[2]
>
> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> [2] https://launchpad.net/bugs/1548340
>
> Best Regards,
> Matthew Mosesohn
>
> __
> 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] [fuel][plugins] Should we maintain example plugins?

[Alex Schultz]

On Thu, Mar 3, 2016 at 7:19 AM, Matthew Mosesohn  wrote:
>
> Hi Fuelers,
>
> I would like to bring your attention a dilemma we have here. It seems
> that there is a dispute as to whether we should maintain the releases
> list for example plugins[0]. In this case, this is for adding version
> 9.0 to the list.
>
> Right now, we run a swarm test that tries to install the example
> plugin and do a deployment, but it's failing only for this reason. I
> should add that this is the only automated daily test that will verify
> that our plugin framework actually works. During the Mitaka
> development  cycle, we already had an extended period where plugins
> were broken[1]. Removing this test (or leaving it permanently red,
> which is effectively the same), would raise the risk to any member of
> the Fuel community who depends on plugins actually working.
>

IMHO we need to fix the plugins and this should just be part of the
basic maintenance of the plugins for each release cycle. These are
effectively documentation that needs to be updated on a regular basis
and should not be let to go stale.  Integrating with fuel and plugins
is already a complex task so having something that can be used as an
example is very important from an end user experiance standpoint.

>
> The other impact of abandoning maintenance of example plugins is that
> it means that a given interested Fuel Plugin developer would not be
> able to easily get started with plugin development. It might not be
> inherently obvious to add the current Fuel release to the
> metadata.yaml file and it would likely discourage such a user. In this
> case, I would propose that we remove example plugins from fuel-plugins
> GIT repo if they are not maintained. Non-functioning code is worse
> than deleted code in my opinion.
>
> Please share your opinions and let's decide which way to go with this bug[2]
>
> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> [2] https://launchpad.net/bugs/1548340
>
> Best Regards,
> Matthew Mosesohn
>
> __
> 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] [Fuel] UI code freeze

[Vitaly Kramskikh]

Fuel UI code has been completely removed from fuel-web repo and CI jobs to
verify fuel-web RR with fuel-ui code and fuel-ui RR with fuel-web code have
been set up. So the code separation can be considered as done.

Though there is one thing needs to be done and we don't know how to solve
that task properly: how do we test and merge RRs to fuel-web and fuel-ui
which are dependent on each other? Example of such RR:
https://review.openstack.org/#/c/286547/. It has -1 from CI because this
change needs to be tested against corresponding RR to fuel-web repo.

If you have any ideas, feel free to tell us.

2016-03-01 16:09 GMT+07:00 Vitaly Kramskikh :

> The new repo has been created: https://github.com/openstack/fuel-ui.
> Please move all change requests there. Fuel UI code in fuel-web repo is
> going to be removed soon.
>
> 2016-02-26 19:53 GMT+07:00 Vladimir Kozhukalov :
>
>> Dear colleagues,
>>
>> We are ready for moving UI javascript code to a separate git repository.
>> Since now all review requests for fuel-web@master that are related to UI
>> must be marked -2 and later abandoned. Once new project fuel-ui is created
>> those changes should be backported to this new repository.
>>
>> Checklist:
>>
>>
>>- Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
>>- openstack-infra
>>   - project-config https://review.openstack.org/#/c/260455 (ON
>>   REVIEW)
>>   - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
>>- fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
>>- label jenkins slaves for the new job (ci team)
>>- UI directory freeze (DONE)
>>- prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
>>- waiting for openstack-infra patches to be merged
>>- .gitreview .gitignore MAINTAINERS (TODO)
>>- rpm spec (TODO)
>>- custom ci jobs (TODO)
>>- fuel-main (TODO)
>>- packaging ci (TODO)
>>- remove old files (TODO)
>>
>>
>> Vladimir Kozhukalov
>>
>> __
>> 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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

Re: [openstack-dev] [Fuel] [FFE] Use packetary for building ISO

[Thomas Goirand]

On 03/03/2016 07:14 PM, Aleksey Zvyagintsev wrote:
> Hello team's ,
> Please take in mind my HUGE +1
> We really need to remove package building process from iso build flow.

Same point of view over here. Let's get rid of the "make world" approach
ASAP.

Cheers,

Thomas Goirand (zigo)



__
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][FFE] API must allow VIP to be manually set to ANY valid IP address

[Artem Roma]

I'm glad to inform you that all required functionality for the feature was
successfully landed into upstream and FFE is not needed anymore.

On Mon, Feb 29, 2016 at 7:23 PM, Artem Roma  wrote:

> Colleagues,
> I would like to request a feature freeze exception for 'API must allow VIP
> to be manually set to ANY valid IP address' [1].
>
> There are three patches still under the review process [2][3][4].
>
> [2][3] are blocked by merge freeze for UI changes due to separation of
> fuel-ui and fuel-web repositories.
>
> [4] introduces fix for old tech debt issue and blocked by corresponding
> issue in cluster upgrade code. That needs to be addressed properly too in
> the scope of the feature.
>
> To merge the changes we need at most one week of time.
>
> ​[1]: ​https://blueprints.launchpad.net/fuel/+spec/allow-any-vip
> [2]: https://review.openstack.org/#/c/286046/
> [3]: https://review.openstack.org/#/c/285297/
> [4]: https://review.openstack.org/#/c/284841/
>
> --
> Regards!)
>



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

Re: [openstack-dev] [Fuel] [FFE] FF exception request for DPDK

[Vladimir Eremin]

Hi,

All patches for DPDK feature [1] are on review, new patches are not expected:
* https://review.openstack.org/286611 Support for DPDK enablement on node 
interfaces
* https://review.openstack.org/284283 Add DPDK support for node interfaces

For DPDK bonding [2]:
* https://review.openstack.org/287410 Added dpdkovs provider for bond

For network verifications [3]:
* https://review.openstack.org/287806 Network verification for DPDK enabled 
interfaces

[1]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk
[2]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond
[3]: https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Mar 1, 2016, at 7:27 PM, Aleksandr Didenko  wrote:
> 
> Hi,
> 
> I'd like to to request a feature freeze exception for "Support for DPDK for 
> improved networking performance" feature [0].
> 
> Part of this feature is already merged [1]. We have the following patches in 
> work / on review:
> 
> https://review.openstack.org/281827
> https://review.openstack.org/283044
> https://review.openstack.org/286595
> https://review.openstack.org/284285
> https://review.openstack.org/284283
> https://review.openstack.org/286611
> 
> And we need to write new patches for the following parts of this feature:
> https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk
> https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond
> 
> We need 3 weeks after FF to finish this feature.
> Risk of not delivering it after 3 weeks is low.
> 
> Regards,
> Alex
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/support-dpdk
> [1] 
> https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-dpdk
> __
> 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-dev] [fuel][plugins] Should we maintain example plugins?

[Matthew Mosesohn]

Hi Fuelers,

I would like to bring your attention a dilemma we have here. It seems
that there is a dispute as to whether we should maintain the releases
list for example plugins[0]. In this case, this is for adding version
9.0 to the list.

Right now, we run a swarm test that tries to install the example
plugin and do a deployment, but it's failing only for this reason. I
should add that this is the only automated daily test that will verify
that our plugin framework actually works. During the Mitaka
development  cycle, we already had an extended period where plugins
were broken[1]. Removing this test (or leaving it permanently red,
which is effectively the same), would raise the risk to any member of
the Fuel community who depends on plugins actually working.

The other impact of abandoning maintenance of example plugins is that
it means that a given interested Fuel Plugin developer would not be
able to easily get started with plugin development. It might not be
inherently obvious to add the current Fuel release to the
metadata.yaml file and it would likely discourage such a user. In this
case, I would propose that we remove example plugins from fuel-plugins
GIT repo if they are not maintained. Non-functioning code is worse
than deleted code in my opinion.

Please share your opinions and let's decide which way to go with this bug[2]

[0] https://github.com/openstack/fuel-plugins/tree/master/examples
[1] https://bugs.launchpad.net/fuel/+bug/1544505
[2] https://launchpad.net/bugs/1548340

Best Regards,
Matthew Mosesohn

__
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] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Dmitry Klenov]

Maksim, good job! +1 from my side though I am not a core.

On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev <
azvyagint...@mirantis.com> wrote:

> +1
>
> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko 
> wrote:
>
>> +1
>>
>> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov 
>> wrote:
>>
>>> +1
>>>
>>> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov 
>>> wrote:
>>>
 +1

 On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov 
 wrote:

> Hey Fuelers,
>
> Since we've successfully moved [1] virtual-box scripts from fuel-main
> [2] to
> separate fuel-virtualbox [3] git repo, I propose to update
> fuel-virtualbox-core
> team [4] by adding Maksim Malchuk. Maksim is the main contributor to
> these
> scripts during Mitaka release cycle [5]
>
> Fuel Cores, please vote.
>
> [1].
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
> [2]. https://github.com/openstack/fuel-main
> [3]. https://github.com/openstack/fuel-virtualbox
> [4]. https://review.openstack.org/#/admin/groups/1299,members
> [5]. https://github.com/openstack/fuel-virtualbox/commits/master
>
> --
> Sergey
> DevOps Engineer
> IRC: SergK
> Skype: Sergey_kul
>
>
> __
> 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
>>>
>>>
>>
>> __
>> 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,
>Aleksey Zvyagintsev
>
> __
> 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] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Aleksey Zvyagintsev]

+1

On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko 
wrote:

> +1
>
> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov 
> wrote:
>
>> +1
>>
>> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov 
>> wrote:
>>
>>> +1
>>>
>>> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov 
>>> wrote:
>>>
 Hey Fuelers,

 Since we've successfully moved [1] virtual-box scripts from fuel-main
 [2] to
 separate fuel-virtualbox [3] git repo, I propose to update
 fuel-virtualbox-core
 team [4] by adding Maksim Malchuk. Maksim is the main contributor to
 these
 scripts during Mitaka release cycle [5]

 Fuel Cores, please vote.

 [1].
 http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
 [2]. https://github.com/openstack/fuel-main
 [3]. https://github.com/openstack/fuel-virtualbox
 [4]. https://review.openstack.org/#/admin/groups/1299,members
 [5]. https://github.com/openstack/fuel-virtualbox/commits/master

 --
 Sergey
 DevOps Engineer
 IRC: SergK
 Skype: Sergey_kul


 __
 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
>>
>>
>
> __
> 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,
   Aleksey Zvyagintsev
__
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] [Ci] New 'fuel-astute' gate job

[Dmitry Kaiharodsev]

Hi to all,

please be informed that starting from today we're launching gate job [1]
for 'fuel-astute' package [2]

Mentioned job will be triggered on each commit and will perform next steps:
- build a package from the commit
- run system tests scenario [3] with using created package
- vote in a patchset according to system test result

Job duration around 1 hour

For any additional questions please use our #fuel-infra IRC channel

[1]
https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.ubuntu.review_astute_patched/
[2] https://github.com/openstack/fuel-astute
[3]
https://github.com/openstack/fuel-qa/blob/master/gates_tests/tests/test_review_in_astute.py#L41-L49

-- 
Kind Regards,
Dmitry Kaigarodtsev
IRC: dkaiharodsev
__
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