[openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Ilya Kutukov]

+1

Alexander is a great specialist

>Hey fellow fuelers,

>I'd like to nominate Alexander Kislitsky to the fuel-web-core team.>He's doing 
>thorough review [1], participate in feature developments>(e.g. Config-DB 
>enhancements, network-manager performance
improvements) and made an outstanding contribution bug-fixing.>>Core
reviewers, please reply back with +1/-1.>>Thanks,>Ihor>>[1]
http://stackalytics.com/?release=ocata=fuel-web


-- 
С уважением,
Кутуков Илья

+7 962 909 10 35
post.i...@gmail.com
skype: blinkedeye
__
OpenStack Development Mailing 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] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Maybe smth like this
[image: Inline image 1]

On Fri, Jun 24, 2016 at 2:18 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote:

> Here is top-down projection
> https://www.the-blueprints.com/blueprints-depot/ships/ships-france/nmf-mistral-l9013.png
>
> On Fri, Jun 24, 2016 at 2:17 PM, Ilya Kutukov <ikutu...@mirantis.com>
> wrote:
>
>> Look, Mistral landing markup (white stripes and circles with numbers)
>> looks like tasks queue:
>> https://patriceayme.files.wordpress.com/2014/05/mistral.jpg
>>
>> On Fri, Jun 24, 2016 at 12:55 PM, Hardik <
>> hardik.par...@nectechnologies.in> wrote:
>>
>>> +1 :)
>>>
>>>
>>> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>>>
>>> I like the idea of the logo being a stylized wind turbine. Perhaps it
>>>> could be
>>>> a turbine with a gust of wind. Then we can show that Mistral harnesses
>>>> the
>>>> power of the wind :-)
>>>
>>>
>>> I like this idea! Combine Mistral functionality symbol with wind :)
>>>
>>> --
>>> Best Regards,
>>> Nikolay
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Here is top-down projection
https://www.the-blueprints.com/blueprints-depot/ships/ships-france/nmf-mistral-l9013.png

On Fri, Jun 24, 2016 at 2:17 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote:

> Look, Mistral landing markup (white stripes and circles with numbers)
> looks like tasks queue:
> https://patriceayme.files.wordpress.com/2014/05/mistral.jpg
>
> On Fri, Jun 24, 2016 at 12:55 PM, Hardik <hardik.par...@nectechnologies.in
> > wrote:
>
>> +1 :)
>>
>>
>> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>>
>> I like the idea of the logo being a stylized wind turbine. Perhaps it
>>> could be
>>> a turbine with a gust of wind. Then we can show that Mistral harnesses
>>> the
>>> power of the wind :-)
>>
>>
>> I like this idea! Combine Mistral functionality symbol with wind :)
>>
>> --
>> Best Regards,
>> Nikolay
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistal] Mistral logo ideas?

[Ilya Kutukov]

Look, Mistral landing markup (white stripes and circles with numbers) looks
like tasks queue:
https://patriceayme.files.wordpress.com/2014/05/mistral.jpg

On Fri, Jun 24, 2016 at 12:55 PM, Hardik 
wrote:

> +1 :)
>
>
> On Friday 24 June 2016 03:08 PM, Nikolay Makhotkin wrote:
>
> I like the idea of the logo being a stylized wind turbine. Perhaps it
>> could be
>> a turbine with a gust of wind. Then we can show that Mistral harnesses
>> the
>> power of the wind :-)
>
>
> I like this idea! Combine Mistral functionality symbol with wind :)
>
> --
> Best Regards,
> Nikolay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

[Ilya Kutukov]

Thank you! I appreciate that and hope that i'll help to reduce time of the
review stage)

On Mon, Jun 20, 2016 at 12:01 PM, Bulat Gaifullin <bgaiful...@mirantis.com>
wrote:

> Well, the agreement is reached. I added Ilya to fuel-web-core group.
>
> Ilya, congratulations! Will be happy to see even more thorough reviews from 
> you!
>
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 08 Jun 2016, at 20:52, Bulat Gaifullin <bgaiful...@mirantis.com> wrote:
>
> Hey Fuelers,
>
> I'd like to nominate Ilya Kutukov for the fuel-web-core team.
> Ilya`s doing good reviews with detailed feedback [1],
> and has implemented custom graph execution engine for Fuel.
> Also Ilya`s implemented new database models for storing deployment tasks
> in Fuel.
>
>
> Fuel Cores, please reply back with +1/-1.
>
> [1] http://stackalytics.com/report/contribution/fuel-web/90
>
>
> 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 Development Mailing 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] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

[Ilya Kutukov]

You are welcome!

On Sat, Apr 23, 2016 at 11:00 AM, Guillaume Thouvenin <thouv...@gmail.com>
wrote:

> Yes this patch fixes the issue.
> Thanks Ilya.
>
> On Fri, Apr 22, 2016 at 4:53 PM, Ilya Kutukov <ikutu...@mirantis.com>
> wrote:
>
>> Hello!
>>
>> I think your problem is related to the:
>> https://bugs.launchpad.net/fuel/+bug/1570846
>>
>> Fix to stable/mitaka was commited 20/04/2016
>> https://review.openstack.org/#/c/307658/
>>
>> Could you, please, try to apply this patch and reply does it help or not.
>>
>> On Fri, Apr 22, 2016 at 5:40 PM, Guillaume Thouvenin <thouv...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> deployment_tasks.yaml for the fuel-plugin-lma-collector plugin has this
>>> task definition:
>>>
>>> - id: lma-aggregator
>>>   type: puppet
>>>   version: 2.0.0
>>>   requires: [lma-base]
>>>   required_for: [post_deployment_end]
>>>   role: '*'
>>>   parameters:
>>> puppet_manifest: puppet/manifests/aggregator.pp
>>> puppet_modules: puppet/modules:/etc/puppet/modules
>>> timeout: 600
>>>
>>> It works well with MOS 8. Unfortunately it doesn't work anymore with MOS
>>> 9: the task doesn't appear in the deployment graph. The regression seems to
>>> be introduced by the computable-task-fields-yaql feature [1].
>>>
>>> We could use "roles: ['/.*/']" instead of "role: '*' " but then the task
>>> is skipped when using MOS 8. We also tried to declare both "roles" and
>>> "role" but again this doesn't work.
>>>
>>> How can we ensure that the same version of the plugin can be deployed on
>>> both versions of MOS? Obviously maintaining one Git branch per MOS release
>>> is not an option.
>>>
>>> [1] https://review.openstack.org/#/c/296414/
>>>
>>> Regards,
>>> Guillaume
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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][plugins] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

[Ilya Kutukov]

Hello!

I think your problem is related to the:
https://bugs.launchpad.net/fuel/+bug/1570846

Fix to stable/mitaka was commited 20/04/2016
https://review.openstack.org/#/c/307658/

Could you, please, try to apply this patch and reply does it help or not.

On Fri, Apr 22, 2016 at 5:40 PM, Guillaume Thouvenin 
wrote:

> Hello,
>
> deployment_tasks.yaml for the fuel-plugin-lma-collector plugin has this
> task definition:
>
> - id: lma-aggregator
>   type: puppet
>   version: 2.0.0
>   requires: [lma-base]
>   required_for: [post_deployment_end]
>   role: '*'
>   parameters:
> puppet_manifest: puppet/manifests/aggregator.pp
> puppet_modules: puppet/modules:/etc/puppet/modules
> timeout: 600
>
> It works well with MOS 8. Unfortunately it doesn't work anymore with MOS
> 9: the task doesn't appear in the deployment graph. The regression seems to
> be introduced by the computable-task-fields-yaql feature [1].
>
> We could use "roles: ['/.*/']" instead of "role: '*' " but then the task
> is skipped when using MOS 8. We also tried to declare both "roles" and
> "role" but again this doesn't work.
>
> How can we ensure that the same version of the plugin can be deployed on
> both versions of MOS? Obviously maintaining one Git branch per MOS release
> is not an option.
>
> [1] https://review.openstack.org/#/c/296414/
>
> Regards,
> Guillaume
>
>
> __
> OpenStack Development Mailing 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?

[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 <e...@mirantis.com> 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 <ikutu...@mirantis.com>
> 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 <ikalnit...@mirantis.com>
>> 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
>>> <sbogat...@mirantis.com> 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 develop

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 <ikutu...@mirantis.com> 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 <ikalnit...@mirantis.com>
> 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
>> <sbogat...@mirantis.com> 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
>> pl

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Ilya Kutukov]

On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <e...@mirantis.com> wrote:

> Ilya,
>
> >> My opinion that i've seen no example of multiple software of plugins
> versions shipped in one package or other form of bundle. Its not a common
> practice.
>
> With plugins we extend Fuel capabilities, which supports multiple
> operating system releases, so it's absolutely natural to extend multiple
> releases at the same time.
>
>
I just warning against idea when to merge content of several plugin
distributions in one bundle. But it's ok for plugin code to support
multiple releases one or another way.



> >> Anyway we need to provide ability to override paths in manifest
> (metadata.yaml).
>
> Could you please provide more information on that? I'm not sure if I
> understand your solution.
>
>
https://review.openstack.org/#/c/271417/5/specs/9.0/plugins-v5.rst L150 and
further
We are overriding default path with special per-release path attributes.
The question is to use per-release way described in spec or don't bother
and specify this overrides only in metadata.yaml root.


> Also I'm not sure what we are arguing about, if plugin developer (or
> certification process of some company) requires to have plugin per release,
> it's *very easy* and straight forward to do it even now *without any*
> changes.
>
> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc,
> let them do it, and again when we get full support
> of multi-version environments it's going to be even more crucial for UX to
> have a single plugin with multi-release support.
>
>
Thanks,
>
> On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutu...@mirantis.com>
> wrote:
>
>> My opinion that i've seen no example of multiple software of plugins
>> versions shipped in one package or other form of bundle. Its not a common
>> practice.
>>
>> Anyway we need to provide ability to override paths in manifest
>> (metadata.yaml).
>>
>> So the plugin developers could use this approaches to provide multiple
>> versions support:
>>
>> * tasks logic (do the plugin developers have access to current release
>> info?)
>> * hooks in pre-build process. Its not a big deal to preprocess source
>> folder to build different packages with scripts that adding or removing
>> some files or replacing some paths.
>> * and, perhaps, logic anchors with YACL or other DSL in tasks
>> dependancies if this functionality will be added this in theory could allow
>> to use or not to use some graph parts depending on release.
>>
>> I think its already better than nothing and more flexible than any
>> standardised approach.
>>
>> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasqu...@mirantis.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com> wrote:
>>>
>>>> Hey folks,
>>>>
>>>> The original idea is to provide a way to build plugin that are
>>>> compatible with few releases. It makes sense to me, cause it looks
>>>> awful if you need to maintain different branches for different Fuel
>>>> releases and there's no difference in the sources. In that case, each
>>>> bugfix to deployment scripts requires:
>>>>
>>>> * backport bugfix to other branches (N backports)
>>>> * build new packages for supported releases (N builds)
>>>> * release new packages (N releases)
>>>>
>>>> It's somehow.. annoying.
>>>>
>>>
>>> A big +1 on Igor's remark. I've already expressed it in another thread
>>> but it should be expected that plugin developers want to support 2
>>> consecutive versions of Fuel for a given version of their plugin.
>>> That being said, I've never had issues to do it with the current plugin
>>> framework. Except when Fuel breaks the backward compatibility but it's
>>> another story...
>>>
>>> Simon
>>>
>>>
>>>>
>>>> However, I starting agree that having all-in-one RPM when deployment
>>>> scripts are different, tasks are different, roles/volumes are
>>>> different, probably isn't a good idea. It basically means that your
>>>> sources are completely different, and that means you have different
>>>> implementations of the same plugin. In that case, in order to avoid
>>>> mess in source tree, it'd be better to separate such implementations
>>>> on VCS level.
>>>>
>>>> But I'd like to hear more opinion from plugin devel

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Ilya Kutukov]

Excuse me, i mean multi-release package. We already have release directives
in plugin metadata.yaml that defines releases compatible with the plugin.
As far as i understand "multi-release package" suppose ability to define
custom configuration/code for each of this releases.


On Fri, Feb 12, 2016 at 3:19 PM, Evgeniy L <e...@mirantis.com> wrote:

> >> We have package format <=4.0 where all files have fixed names and
> locations. This is the defaults.
>
> The thing is for 5.0 there should be no default, those fields from now on
> should be specified explicitly.
>
> >> Igor want to provide multi-package
>
> I'm not familiar with this idea, could you please clarify what
> multi-package is?
>
> Thanks,
>
> On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov <ikutu...@mirantis.com>
> wrote:
>
>>
>>
>> On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L <e...@mirantis.com> wrote:
>>
>>> Ilya,
>>>
>>> What do you mean by "default"? From the data format I see that we don't
>>> "override defaults" we specify the data for specific release, the way it
>>> was always done for deployment scripts and repositories.
>>>
>>>
>> We have package format <=4.0 where all files have fixed names and
>> locations. This is the defaults.
>>
>> 1. The maintenance team wants ability to specify folder instead plugin
>> configuration files so there should be ability to change this paths to
>> define a folder or other non-standard location. Yes, plugin developer could
>> have whatever source structure and then translate it to the file structure
>> required for the FPB with scripts or build system, but ability to split
>> e.g. tasks files looks useful for me.
>>
>> 2. Igor want to provide multi-package, so, according to spec, this custom
>> release-specific paths to other package files could be specified in release
>> records.
>>
>> I don't see any reasons to complicate format even more and to have some
>>> things which are related to the deployment specified in the root and some
>>> in specific release.
>>>
>>> There is consistent mechanism to specify such kind of things, lets just
>>> use it.
>>>
>>> Thanks,
>>>
>>> On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov <ikutu...@mirantis.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <e...@mirantis.com> wrote:
>>>>
>>>>> Ilya,
>>>>>
>>>>> >> My opinion that i've seen no example of multiple software of
>>>>> plugins versions shipped in one package or other form of bundle. Its not a
>>>>> common practice.
>>>>>
>>>>> With plugins we extend Fuel capabilities, which supports multiple
>>>>> operating system releases, so it's absolutely natural to extend multiple
>>>>> releases at the same time.
>>>>>
>>>>>
>>>> I just warning against idea when to merge content of several plugin
>>>> distributions in one bundle. But it's ok for plugin code to support
>>>> multiple releases one or another way.
>>>>
>>>>
>>>>
>>>>> >> Anyway we need to provide ability to override paths in manifest
>>>>> (metadata.yaml).
>>>>>
>>>>> Could you please provide more information on that? I'm not sure if I
>>>>> understand your solution.
>>>>>
>>>>>
>>>> https://review.openstack.org/#/c/271417/5/specs/9.0/plugins-v5.rst
>>>> L150 and further
>>>> We are overriding default path with special per-release path attributes.
>>>> The question is to use per-release way described in spec or don't
>>>> bother and specify this overrides only in metadata.yaml root.
>>>>
>>>>
>>>>> Also I'm not sure what we are arguing about, if plugin developer (or
>>>>> certification process of some company) requires to have plugin per 
>>>>> release,
>>>>> it's *very easy* and straight forward to do it even now *without any*
>>>>> changes.
>>>>>
>>>>> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH
>>>>> etc, let them do it, and again when we get full support
>>>>> of multi-version environments it's going to be even more crucial for UX to
>>>>> have a single plugin with multi-release suppor

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Ilya Kutukov]

On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L <e...@mirantis.com> wrote:

> Ilya,
>
> What do you mean by "default"? From the data format I see that we don't
> "override defaults" we specify the data for specific release, the way it
> was always done for deployment scripts and repositories.
>
>
We have package format <=4.0 where all files have fixed names and
locations. This is the defaults.

1. The maintenance team wants ability to specify folder instead plugin
configuration files so there should be ability to change this paths to
define a folder or other non-standard location. Yes, plugin developer could
have whatever source structure and then translate it to the file structure
required for the FPB with scripts or build system, but ability to split
e.g. tasks files looks useful for me.

2. Igor want to provide multi-package, so, according to spec, this custom
release-specific paths to other package files could be specified in release
records.

I don't see any reasons to complicate format even more and to have some
> things which are related to the deployment specified in the root and some
> in specific release.
>
> There is consistent mechanism to specify such kind of things, lets just
> use it.
>
> Thanks,
>
> On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov <ikutu...@mirantis.com>
> wrote:
>
>>
>>
>> On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <e...@mirantis.com> wrote:
>>
>>> Ilya,
>>>
>>> >> My opinion that i've seen no example of multiple software of plugins
>>> versions shipped in one package or other form of bundle. Its not a common
>>> practice.
>>>
>>> With plugins we extend Fuel capabilities, which supports multiple
>>> operating system releases, so it's absolutely natural to extend multiple
>>> releases at the same time.
>>>
>>>
>> I just warning against idea when to merge content of several plugin
>> distributions in one bundle. But it's ok for plugin code to support
>> multiple releases one or another way.
>>
>>
>>
>>> >> Anyway we need to provide ability to override paths in manifest
>>> (metadata.yaml).
>>>
>>> Could you please provide more information on that? I'm not sure if I
>>> understand your solution.
>>>
>>>
>> https://review.openstack.org/#/c/271417/5/specs/9.0/plugins-v5.rst L150
>> and further
>> We are overriding default path with special per-release path attributes.
>> The question is to use per-release way described in spec or don't bother
>> and specify this overrides only in metadata.yaml root.
>>
>>
>>> Also I'm not sure what we are arguing about, if plugin developer (or
>>> certification process of some company) requires to have plugin per release,
>>> it's *very easy* and straight forward to do it even now *without any*
>>> changes.
>>>
>>> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc,
>>> let them do it, and again when we get full support
>>> of multi-version environments it's going to be even more crucial for UX to
>>> have a single plugin with multi-release support.
>>>
>>>
>> Thanks,
>>>
>>> On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutu...@mirantis.com>
>>> wrote:
>>>
>>>> My opinion that i've seen no example of multiple software of plugins
>>>> versions shipped in one package or other form of bundle. Its not a common
>>>> practice.
>>>>
>>>> Anyway we need to provide ability to override paths in manifest
>>>> (metadata.yaml).
>>>>
>>>> So the plugin developers could use this approaches to provide multiple
>>>> versions support:
>>>>
>>>> * tasks logic (do the plugin developers have access to current release
>>>> info?)
>>>> * hooks in pre-build process. Its not a big deal to preprocess source
>>>> folder to build different packages with scripts that adding or removing
>>>> some files or replacing some paths.
>>>> * and, perhaps, logic anchors with YACL or other DSL in tasks
>>>> dependancies if this functionality will be added this in theory could allow
>>>> to use or not to use some graph parts depending on release.
>>>>
>>>> I think its already better than nothing and more flexible than any
>>>> standardised approach.
>>>>
>>>> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasqu...@mirantis.com
>>>> > wrote:
>>>>
&

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Ilya Kutukov]

r/YACL/YAQL/

On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote:

> My opinion that i've seen no example of multiple software of plugins
> versions shipped in one package or other form of bundle. Its not a common
> practice.
>
> Anyway we need to provide ability to override paths in manifest
> (metadata.yaml).
>
> So the plugin developers could use this approaches to provide multiple
> versions support:
>
> * tasks logic (do the plugin developers have access to current release
> info?)
> * hooks in pre-build process. Its not a big deal to preprocess source
> folder to build different packages with scripts that adding or removing
> some files or replacing some paths.
> * and, perhaps, logic anchors with YACL or other DSL in tasks dependancies
> if this functionality will be added this in theory could allow to use or
> not to use some graph parts depending on release.
>
> I think its already better than nothing and more flexible than any
> standardised approach.
>
> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasqu...@mirantis.com>
> wrote:
>
>> Hi,
>>
>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <ikalnit...@mirantis.com
>> > wrote:
>>
>>> Hey folks,
>>>
>>> The original idea is to provide a way to build plugin that are
>>> compatible with few releases. It makes sense to me, cause it looks
>>> awful if you need to maintain different branches for different Fuel
>>> releases and there's no difference in the sources. In that case, each
>>> bugfix to deployment scripts requires:
>>>
>>> * backport bugfix to other branches (N backports)
>>> * build new packages for supported releases (N builds)
>>> * release new packages (N releases)
>>>
>>> It's somehow.. annoying.
>>>
>>
>> A big +1 on Igor's remark. I've already expressed it in another thread
>> but it should be expected that plugin developers want to support 2
>> consecutive versions of Fuel for a given version of their plugin.
>> That being said, I've never had issues to do it with the current plugin
>> framework. Except when Fuel breaks the backward compatibility but it's
>> another story...
>>
>> Simon
>>
>>
>>>
>>> However, I starting agree that having all-in-one RPM when deployment
>>> scripts are different, tasks are different, roles/volumes are
>>> different, probably isn't a good idea. It basically means that your
>>> sources are completely different, and that means you have different
>>> implementations of the same plugin. In that case, in order to avoid
>>> mess in source tree, it'd be better to separate such implementations
>>> on VCS level.
>>>
>>> But I'd like to hear more opinion from plugin developers.
>>>
>>> - Igor
>>>
>>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin
>>> <bgaiful...@mirantis.com> wrote:
>>> > I agree with Stas, one rpm - one version.
>>> >
>>> > But plugin builder allows to specify several releases as compatible.
>>> The
>>> > deployment tasks and repositories can be specified per release, at the
>>> same
>>> > time the deployment graph is one for all releases.
>>> > Currently it looks like half-implemented feature.  Can we drop this
>>> feature?
>>> > or should we finish implementation of this feature.
>>> >
>>> >
>>> > Regards,
>>> > Bulat Gaifullin
>>> > Mirantis Inc.
>>> >
>>> >
>>> >
>>> > On 11 Feb 2016, at 02:41, Andrew Woodward <xar...@gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <
>>> dborodae...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> +1 to Stas, supplanting VCS branches with code duplication is a path
>>> to
>>> >> madness and despair. The dubious benefits of a cross-release backwards
>>> >> compatible plugin binary are not worth the code and infra technical
>>> debt
>>> >> that such approach would accrue over time.
>>> >
>>> >
>>> > Supporting multiple fuel releases will likely result in madness as
>>> > discussed, however as we look to support multiple OpenStack releases
>>> from
>>> > the same version of fuel, this methodology becomes much more important.
>>> >
>>> >>
>>> >> On

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Ilya Kutukov]

My opinion that i've seen no example of multiple software of plugins
versions shipped in one package or other form of bundle. Its not a common
practice.

Anyway we need to provide ability to override paths in manifest
(metadata.yaml).

So the plugin developers could use this approaches to provide multiple
versions support:

* tasks logic (do the plugin developers have access to current release
info?)
* hooks in pre-build process. Its not a big deal to preprocess source
folder to build different packages with scripts that adding or removing
some files or replacing some paths.
* and, perhaps, logic anchors with YACL or other DSL in tasks dependancies
if this functionality will be added this in theory could allow to use or
not to use some graph parts depending on release.

I think its already better than nothing and more flexible than any
standardised approach.

On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier 
wrote:

> Hi,
>
> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky 
> wrote:
>
>> Hey folks,
>>
>> The original idea is to provide a way to build plugin that are
>> compatible with few releases. It makes sense to me, cause it looks
>> awful if you need to maintain different branches for different Fuel
>> releases and there's no difference in the sources. In that case, each
>> bugfix to deployment scripts requires:
>>
>> * backport bugfix to other branches (N backports)
>> * build new packages for supported releases (N builds)
>> * release new packages (N releases)
>>
>> It's somehow.. annoying.
>>
>
> A big +1 on Igor's remark. I've already expressed it in another thread but
> it should be expected that plugin developers want to support 2 consecutive
> versions of Fuel for a given version of their plugin.
> That being said, I've never had issues to do it with the current plugin
> framework. Except when Fuel breaks the backward compatibility but it's
> another story...
>
> Simon
>
>
>>
>> However, I starting agree that having all-in-one RPM when deployment
>> scripts are different, tasks are different, roles/volumes are
>> different, probably isn't a good idea. It basically means that your
>> sources are completely different, and that means you have different
>> implementations of the same plugin. In that case, in order to avoid
>> mess in source tree, it'd be better to separate such implementations
>> on VCS level.
>>
>> But I'd like to hear more opinion from plugin developers.
>>
>> - Igor
>>
>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin
>>  wrote:
>> > I agree with Stas, one rpm - one version.
>> >
>> > But plugin builder allows to specify several releases as compatible. The
>> > deployment tasks and repositories can be specified per release, at the
>> same
>> > time the deployment graph is one for all releases.
>> > Currently it looks like half-implemented feature.  Can we drop this
>> feature?
>> > or should we finish implementation of this feature.
>> >
>> >
>> > Regards,
>> > Bulat Gaifullin
>> > Mirantis Inc.
>> >
>> >
>> >
>> > On 11 Feb 2016, at 02:41, Andrew Woodward  wrote:
>> >
>> >
>> >
>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <
>> dborodae...@mirantis.com>
>> > wrote:
>> >>
>> >> +1 to Stas, supplanting VCS branches with code duplication is a path to
>> >> madness and despair. The dubious benefits of a cross-release backwards
>> >> compatible plugin binary are not worth the code and infra technical
>> debt
>> >> that such approach would accrue over time.
>> >
>> >
>> > Supporting multiple fuel releases will likely result in madness as
>> > discussed, however as we look to support multiple OpenStack releases
>> from
>> > the same version of fuel, this methodology becomes much more important.
>> >
>> >>
>> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
>> >> > It changes mostly nothing for case of furious plugin development when
>> >> > big
>> >> > parts of code changed from one release to another.
>> >> >
>> >> > You will have 6 different deployment_tasks directories and 30 a
>> little
>> >> > bit
>> >> > different files in root directory of plugin. Also you forgot about
>> >> > repositories directory (+6 at least), pre_build hooks (also 6) and so
>> >> > on.
>> >> > It will look as hell after just 3 years of development.
>> >> >
>> >> > Also I can't imagine how to deal with plugin licensing if you have
>> >> > Apache
>> >> > for liberty but BSD for mitaka release, for example.
>> >> >
>> >> > Much easier way to develop a plugin is to keep it's source in VCS
>> like
>> >> > Git
>> >> > and just make a branches for every fuel release. It will give us
>> >> > opportunity to not store a bunch of similar but a little bit
>> different
>> >> > files in repo. There is no reason to drag all different versions of
>> code
>> >> > for specific release.
>> >> >
>> >> >
>> >> > On other hand there is a pros - your plugin can survive after
>> upgrade if
>> >> > it
>> >>