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

[Andriy Popovych]

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-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Andriy Popovych]

Hi fuelers,

We want to throw KVM/QEMU options from Wizard and instead of them leave
only one: Libvirt [0]. Libvirt option enables QEMU by default and there are
still be possibility to change it on KVM in settings. It looks more
logically because both QEMU\KVM are options for libvirt which manage them.

What are you think about it?

[0] https://review.openstack.org/#/c/258690
__
OpenStack Development Mailing 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][UX] Component registry

[Andriy Popovych]

Hi fuelers,

Currently we are working on feature component registry [1] which should
help us to prevent not logical compositions of different components in
wizard tab during cluster(environment) creation. Now we have a mechanizm
of 'restrictions' which is not flexible for components provided by
plugins. In our current approach we have two states for components -
compatible/incompatible which are described in compatibility matrix
based on OpenStack components (For example: cinder-vmware storage only
compatible with vCetner hypervisor and should work when only KVM uses).
In this case we allow user to choose only that components we defently
know works well with each other. Another approach tell us to have 3
states: compatible/incompatible/ and all other components about
compatibility with others we know nothing. In that case we should show
on wizard which components compatible, which not, and others which user
can enable on his own risk. So I need your opinions: should we allow for
user choose only that coponents which are tested and defently works or
prevent her/him from choosing which are defently not works and means
potentional risk of failing deployment when component about we know
nothing isn't work together.



[1] https://blueprints.launchpad.net/fuel/+spec/component-registry

__
OpenStack Development Mailing 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 related functionality in Fuel Client

[Andriy Popovych]

Actually it's an old issue 
https://blueprints.launchpad.net/fuel/+spec/plugin-manager-as-separate-service


On 10/09/2015 11:53 AM, Sergii Golovatiuk wrote:

+1 to Roman.

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

On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko mailto:m...@romcheg.me>> wrote:

I’d say even if it will be a separate service it’s better to proxy
requests through Nailgun’s API to have a single entry point.


9 жовт. 2015 р. о 10:23 Evgeniy L mailto:e...@mirantis.com>> написав(ла):

Hi,

+1, but I think it's better to spawn separate service, instead of
adding it to Nailgun.

Thanks,

On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko mailto:m...@romcheg.me>> wrote:

Folks,

it’s time to speak about Fuel Plugins and the way they are
managed.

Currently we have some methods in Fuel Client that allow to
install, remove and do some other things to plugins.
Everything looks great except that functionality requires Fuel
Client to be installed on a master node and be running under a
root user. It’s time for us to grow up and realize that
nothing can require Fuel Client to be installed on a specific
computer and of course we cannot require root permissions for
any actions.

I’d like to move all that code to Nailgun, utilizing mules and
hide it behind Nailgun’s API as soon as possible. For that I
filed a bug [1] and I’d like to ask Fuel Enhancements subgroup
of developers to take a close look at it.


1. https://bugs.launchpad.net/fuel/+bug/1504338


- romcheg



__
OpenStack Development Mailing 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



__
OpenStack Development Mailing 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] differenciate node with the same role - the spec is available

[Andriy Popovych]

Samuel,

As I know one node can have many roles.

For 1/ You can specify custom nova-nfs role and assign it on compute nodes.

Regards,
Andriy

On Wed, Jun 24, 2015 at 10:21 PM, Samuel Bartel  wrote:

> Andriy,
>
> May be 'role' was not the correct word  here.
> For me role are compute, controller, base-os, cinder, mongo. I know that
> we can specify that a task A should be executed on some role (controller
> and compute for example) and a task B on some other roles (Cinder for
> example).
>
> To come back to my previous examples with the label feature presented by
> Irina :
> 1/ not apply nova-nfs plugin in all compute nodes
> we would assign a label on the nodes on which we want to setup the nfs
> backend storage for ephemeral volume. Then in the deploymodule we would be
> able to put a condition to setup it or not. Here the cleaner solution would
> be in th task.yaml to define a condition to execute the task for a given
> role AND a given label (here role would be equal to compute and label could
> be equal to nfs)
>
> 2/ a plugin to define availability zone:
> if I have 3 compute nodes, I would be able to assign az1 label to compute
> node 1  and 2 and label az2 to compute node 3. Then in the plugin
> deployment moduel I would be able to setup a az called az1 with compute
> nodes 1 and 2 and a az called az2 with compute node 3. It is not custom
> role as these nodes are compute.
>
>
> regards
>
> Samuel
>
> 2015-06-24 20:20 GMT+02:00 Andriy Popovych :
>
>> Samuel,
>>
>> AFAIK labels will not be related to tasks, it's just marks for filtering
>> nodes.
>> What "roles" means for you?
>>
>> we have tasks (A, B, C, D) and on some nodes tasks A B D should be
>> executed, on some B C etc. So plugin can provide specials marks or tags or
>> sets (we call it "roles") and link
>> tasks with it. In example before we can describe roles 'a' and 'b' to
>> group 2 different sets of tasks ABD and BC. So A links with 'a', B with 'a'
>> and 'b', C with 'b' and D  with 'a'). Both roles 'a' and 'b' can be
>> implemented in context of ONE plugin. Actually I can't understand why
>> you want another mark(or tag) for tasks if we already have it and it's
>> called role.
>>
>> Thanks,
>> Andriy
>>
>> On Wed, Jun 24, 2015 at 6:45 PM, Samuel Bartel <
>> samuel.bartel@gmail.com> wrote:
>>
>>> Julia,
>>>
>>> It is exactly what i was thinking. With such a mechanism we would be
>>> able to define custom labels to apply different type of task on compute
>>> nodes according to their labels. I add a comment on the review. As for now
>>> I don't see how we would be able to create custom label from plugin. In
>>> such a case we would have to make evolution on plugin engine part so we
>>> will have to identify exact impact on the plugin feature
>>>
>>> regards
>>>
>>> Samuel
>>>
>>> 2015-06-24 13:54 GMT+02:00 Julia Aranovich :
>>>
>>>> Samuel, I would like you to consider this proposal:
>>>> https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst
>>>>
>>>> This is about support of custom node labels. I think plugins should be
>>>> able to assign its own labels to nodes via Nailgun API. Is it possible?
>>>> Will it suit your case?
>>>>
>>>> Thanks,
>>>> Julia
>>>>
>>>>
>>>>
>>>> On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel <
>>>> samuel.bartel@gmail.com> wrote:
>>>>
>>>>> Irina,
>>>>>
>>>>> Thanks for the link. Unfortunatly it does not cover my use cases. What
>>>>> we would like to do is not define a new role.
>>>>> We would like to be able to apply plugin to some compute node for
>>>>> example and not in the others compute nodes or to be able to execute 
>>>>> plugin
>>>>> with a given config on some compute nodes and with an other config on 
>>>>> other
>>>>> compute nodes
>>>>>
>>>>> It is related to a capcity to tag/flag nodes and not adding new role
>>>>>
>>>>> regards
>>>>>
>>>>> Samuel
>>>>>
>>>>> 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya <
>>>>> ipovolotsk...@mirantis.com>:
>>>>>
>>>>>> Sam

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role - the spec is available

[Andriy Popovych]

Samuel,

AFAIK labels will not be related to tasks, it's just marks for filtering
nodes.
What "roles" means for you?

we have tasks (A, B, C, D) and on some nodes tasks A B D should be
executed, on some B C etc. So plugin can provide specials marks or tags or
sets (we call it "roles") and link
tasks with it. In example before we can describe roles 'a' and 'b' to group
2 different sets of tasks ABD and BC. So A links with 'a', B with 'a' and
'b', C with 'b' and D  with 'a'). Both roles 'a' and 'b' can be implemented
in context of ONE plugin. Actually I can't understand why you want another
mark(or tag) for tasks if we already have it and it's called role.

Thanks,
Andriy

On Wed, Jun 24, 2015 at 6:45 PM, Samuel Bartel 
wrote:

> Julia,
>
> It is exactly what i was thinking. With such a mechanism we would be able
> to define custom labels to apply different type of task on compute nodes
> according to their labels. I add a comment on the review. As for now I
> don't see how we would be able to create custom label from plugin. In such
> a case we would have to make evolution on plugin engine part so we will
> have to identify exact impact on the plugin feature
>
> regards
>
> Samuel
>
> 2015-06-24 13:54 GMT+02:00 Julia Aranovich :
>
>> Samuel, I would like you to consider this proposal:
>> https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst
>>
>> This is about support of custom node labels. I think plugins should be
>> able to assign its own labels to nodes via Nailgun API. Is it possible?
>> Will it suit your case?
>>
>> Thanks,
>> Julia
>>
>>
>>
>> On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel <
>> samuel.bartel@gmail.com> wrote:
>>
>>> Irina,
>>>
>>> Thanks for the link. Unfortunatly it does not cover my use cases. What
>>> we would like to do is not define a new role.
>>> We would like to be able to apply plugin to some compute node for
>>> example and not in the others compute nodes or to be able to execute plugin
>>> with a given config on some compute nodes and with an other config on other
>>> compute nodes
>>>
>>> It is related to a capcity to tag/flag nodes and not adding new role
>>>
>>> regards
>>>
>>> Samuel
>>>
>>> 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya <
>>> ipovolotsk...@mirantis.com>:
>>>
 Samuel,

 Currently, there is a spec on introducing a new role through a plugin
 [1] - the feature is targeted at 7.0.

 Feel free to comment on it and ask questions right in the commit.

 [1] https://review.openstack.org/#/c/185267/
 --
 Best regards,

 Irina

 Partner Management Business Analyst
 skype: ira_live








 __
 OpenStack Development Mailing 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev