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

[Julia Aranovich]

+1

On Tue, Feb 21, 2017 at 4:32 PM Aleksey Kasatkin 
wrote:

> +1
>
>
> Aleksey Kasatkin
>
>
> On Tue, Feb 21, 2017 at 2:25 PM, Ihor Kalnytskyi 
> wrote:
>
> 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&module=fuel-web
>
> __
> OpenStack Development Mailing 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] [OpenStack-dev][Fuel][Plugin]

[Julia Aranovich]

Hi Nidhi,

This implemented https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
blueprint provided an ability to use "text_list" and "textarea_list" UI
control types.
They are suitable for settings where the value is a list of strings.
These controls represent on UI a list of single or multiline text inputs
with +/- buttons to add/remove an additional element:

My Setting  value1 +/-
   value2 +/-
   value3 +/-
(the result value for the setting "My Setting" is ['value1', 'value2',
'value3']).


If I understand your case properly, you need something like dynamic groups
of inputs of different type.
This is still not supported by Fuel UI. The implementation does not look
simple, it requires changing of data structure in settings yaml, adding a
new level of nesting. There is a need to think thoroughly about the
details: how to organize such a setting yaml structure, how to declare a
set of inputs in such a group, how inputs should be aligned in the group
(horizontally/vertically), etc.

For now, I would suggest the following ways of how to organize your plugin
settings:

1) use text_list/textarea_list controls for each field from a group that
represents storage backend configuration:

Field1  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

Field2  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

Field3  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

2) use text_list/textarea_list controls to configure a list of storage
backends by declaring their settings as a single comma-separated string:

Backends Settingscomma_separated_settings_for_backend_1 +/-
comma_separated_settings_for_backend_2 +/-
  comma_separated_settings_for_backend_3 +/-

>From my point of view, the first version looks more clear. Will it
suit your case, Nidhi?


Best regards,
Julia

On Fri, Oct 21, 2016 at 8:17 AM  wrote:

> Hi All,
>
>
> This is regarding an info required for fuel plugin development.
>
> We are working on Fuel Cinder Plugin where we require to
>
> configure multiple 'n' number of backends of storage vendor ,
>
> in one go, from Fuel UI screen. where 'n' will be known at run time.
>
>
> Its like from UI, I can configure a set of fields, [field1, field2,
> field3]
>
> for one backend and if user ask to configure 'n' backends then same
>
> set of fields to be asked repeatedly.
>
>
> I have found some similar provision was planned in
>
> https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
>
>
> But when i see implementation
> https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z
>
> which implements new type as text_list and textarea_list ..
>
> which is capability to add multiple lines of text in single field..
>
>
> It does not look like same as aim of BP, where acceptance criteria for BP
> is
>
> "Enable text and textarea field types to be extended - where a plugin user
> is able to toggle the visibility of additional fields with +/- signs and
> the data provided is used by plugin"
>
>
> Kindly correct my understanding if its wrong, do we have capability to add
> a text field by pressing +/- ?
>
> What capability do we have with Fuel UI to add fields dynamically today ?
>
>
> I have read
> https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel
>
> [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI -
> OpenStack Mailing List Archive
> 
> openstack.nimeyo.com
> Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp
> (to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> where suggestions are made to use restrictions to hide display components.
>
>
> Another suggestion is to use comma separated values.
>
>
> But its an year back post, do we have a better solution today ?
>
>
> Will be helpful if someone can suggest how do we achieve it in fuel UI.
>
>
>
> Thanks
>
> Nidhi
>
>
>
>
>
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
> __
> OpenStack Development Mailing List (not for us

[openstack-dev] [Fuel] Support of deployment history in fake Nailgun

[Julia Aranovich]

Hello everyone,

We [Fuel UI team] are working now on UI implementation of deployment
history [1] and deployment graphs [2] features.

For our development process and covering the features by functional tests,
it is critical to extend fake Nailgun with emulation of a real deployment
execution [3].

Now fake Nailgun provides a history with all the tasks in pending status
for a finished deployment. And we expect to get ready/error tasks as well
with task start and end timestamps.
Emulation of a history of running deployment is also needed.

So, is it possible to support the features in fake Nailgun?

Best regards,
Julia

[1] https://blueprints.launchpad.net/fuel/+spec/ui-deployment-history
[2] https://blueprints.launchpad.net/fuel/+spec/ui-custom-graph
[3] https://bugs.launchpad.net/fuel/+bug/1593757
__
OpenStack Development Mailing 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

[Julia Aranovich]

+1

On Wed, Jun 8, 2016 at 8:52 PM Bulat Gaifullin 
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][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Julia Aranovich]

+1

On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
wrote:

> I'm not a fuel core member, but i also would like to vote +1 for Matthew.
> He's doing great job!
>
> 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko :
>
>> +1
>>
>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Fellow Fuelers
>>>
>>> I would like to kindly ask you to consider voting for Matthew Mosesohn
>>> as a Fuel Library Core
>>> reviewer.
>>>
>>> Matthew has been working with Fuel since its inception, worked on
>>> countless amount of features, such as :
>>>
>>> Master Node Upgrades and Backup
>>> Improvements to Fuel Infra
>>> Mitaka, Kilo and Juno Support
>>> Detachable Services Plugins
>>> RHOS Support in Fuel
>>> UCA Support
>>> Refactoring of Haproxy and Firewall pieces
>>>
>>> He has also been known as our Fuel Master node and Docker guru and has
>>> been continuously working on bugfixing where he scores as a bug squashing
>>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
>>> throughout FL history).
>>>
>>> As you can see, there is not a piece of Fuel Library that he has not yet
>>> gained experience with.
>>>
>>> And this can easily be fetched with simple statistics of Matt's
>>> contribution. He is the topmost contributor to all Fuel projects among all
>>> Fuel Library folks and is the 3rd contributor of Fuel Library.
>>> He also reviews a lot and has a fair amount of -1's (he is not as cruel
>>> as me, though :-))
>>>
>>> Having that said, I would like to open the vote to promote Matt to
>>> OpenStack Fuel Library core reviewers.
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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 UI] Node role list grouping

[Julia Aranovich]

I support Vitaly's proposal with 'base' group name instead of 'controller'.
So, now we have the following suggestion for role list grouping:

BASE: controller, detach-* plugin roles, murano (if it will go to plugin)
COMPUTE: compute, virt, compute-vmware, ironic
STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
OTHER: base-os, mongo, zabbix

On Mon, Feb 1, 2016 at 8:46 PM Vitaly Kramskikh 
wrote:

> Folks,
>
> That's true, Nailgun is still using Role entity - in DB, API, plugins can
> provide new roles, etc., and it's not going away, at least in 9.0.
>
> I'm fine with proposed set of role groups, except the "controller" group.
> We don't have anything else but "controller" role in this group in the base
> installation, but there are plugins that can detach some services from the
> controller, like detach-database, detach-rabbitmq, etc. So these roles with
> detached services should also be in the "controller" group, but it looks a
> little illogical to me. So I'd prefer to go with something like "base" or
> "core" group.
>
> 2016-01-29 16:53 GMT+03:00 Bogdan Dobrelya :
>
>> On 29.01.2016 13:35, Vladimir Kuklin wrote:
>> >> We removed role as abstraction from library. It's very very artificial
>> >> abstraction. Instead we use tasks, grouping them to different
>> >> combinations. That allows plugin developers to adjust reference
>> >> architecture to their needs.
>>
>> I only replied to that. We did not remove role as abstraction
>>
>> --
>> 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
>>
>
>
>
> --
> 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] [Fuel UI] Node role list grouping

[Julia Aranovich]

Sergii,

Just to clarify: we rely on a role 'limits' attribute [1] to define is role
required for deployment ('min' limit presented in the role description) or
recommended for deployment ('recommended' limit). Roles without 'min' or
'recommended' limit are considered as optional for basic deployment.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L23-L24


On Fri, Jan 29, 2016 at 1:27 PM Vladimir Kuklin 
wrote:

> Sergii
>
> I disagree with you here a little bit. Role abstraction is a useful thing
> from high-level standpoint. I would suggest that this list of roles
> grouping, e.g. which roles are mandatory and which are configured within
> which group can be specified:
>
> 1) in global settings of Nailgun
> 2) per-plugin
> 3) per environment in UI
>
> This should cover all the cases even for very flexible roles allocation.
>
> On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>>
>> On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich > > wrote:
>>
>>> Hi folks,
>>>
>>> Our team has started a redesign of node roles panel [1] on Add
>>> Nodes/Edit Roles screens in Fuel UI.
>>> Currently, node roles panel takes a big part of the screen and User have
>>> to scroll down to node list to check nodes and then scroll up again to
>>> check roles. This becomes more actual for desktops with a small screen.
>>>
>>> And we faced with the question of grouping new role containers in the
>>> panel. There is out initial suggestion [2]:
>>>
>>> [image: role-list-grouping-1.png]
>>>
>>>- the first group (the first line on the screenshot) is roles which
>>>are required or recommended for deployment (controller, compute, cinder,
>>>etc.).
>>>
>>> It's not true. There can be deployments without Controllers or without
>> computes or without Storage.
>>
>>>
>>>- the second group is optional roles which are not mandatory for
>>>deployment (base-os, virt, etc.)
>>>- the last group is roles which are unavailable at the moment
>>>because of some restrictions. For example, mongo role can not be assigned
>>>to a node if ceilometer setting is not enabled on Settings tab
>>>
>>> BUT there is also a suggestion [3] (see comment #6) to add a new role
>>> 'category' attribute into its yaml description [4] that will reflect the
>>> role function.
>>> For example, cinder, ceph-osd, cinder-vmware roles are from Storage
>>> category; compute, ironic are Compute and so on.
>>> This new 'category' attribute will also allow proper calculating of an
>>> environment capacity: it does not make sense to count CPU and RAM of
>>> non-compute nodes or HDD of non-storage nodes.
>>>
>>> So, we have an initial proposal for such a grouping by a role category:
>>>
>>> CONTROLLER: controller
>>> COMPUTE: compute, virt, compute-vmware, ironic
>>> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
>>> OTHER: base-os, mongo
>>>
>>> And we ask your help to review this grouping, i.e. to define the list of
>>> possible role categories and to distribute the roles between these
>>> categories.
>>>
>>
>> We removed role as abstraction from library. It's very very artificial
>> abstraction. Instead we use tasks, grouping them to different combinations.
>> That allows plugin developers to adjust reference architecture to their
>> needs.
>>
>>
>>>
>>> Best regards,
>>> Julia
>>>
>>> P.S. We also should take into account, that Fuel plugins can also
>>> provide their own roles.
>>>
>>> [1]
>>> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
>>> [2]
>>> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
>>> [3] https://bugs.launchpad.net/fuel/+bug/1375750
>>> [4]
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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 UI] Node role list grouping

[Julia Aranovich]

Hi folks,

Our team has started a redesign of node roles panel [1] on Add Nodes/Edit
Roles screens in Fuel UI.
Currently, node roles panel takes a big part of the screen and User have to
scroll down to node list to check nodes and then scroll up again to check
roles. This becomes more actual for desktops with a small screen.

And we faced with the question of grouping new role containers in the
panel. There is out initial suggestion [2]:

[image: role-list-grouping-1.png]

   - the first group (the first line on the screenshot) is roles which are
   required or recommended for deployment (controller, compute, cinder, etc.).
   - the second group is optional roles which are not mandatory for
   deployment (base-os, virt, etc.)
   - the last group is roles which are unavailable at the moment because of
   some restrictions. For example, mongo role can not be assigned to a node if
   ceilometer setting is not enabled on Settings tab

BUT there is also a suggestion [3] (see comment #6) to add a new role
'category' attribute into its yaml description [4] that will reflect the
role function.
For example, cinder, ceph-osd, cinder-vmware roles are from Storage
category; compute, ironic are Compute and so on.
This new 'category' attribute will also allow proper calculating of an
environment capacity: it does not make sense to count CPU and RAM of
non-compute nodes or HDD of non-storage nodes.

So, we have an initial proposal for such a grouping by a role category:

CONTROLLER: controller
COMPUTE: compute, virt, compute-vmware, ironic
STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
OTHER: base-os, mongo

And we ask your help to review this grouping, i.e. to define the list of
possible role categories and to distribute the roles between these
categories.

Best regards,
Julia

P.S. We also should take into account, that Fuel plugins can also provide
their own roles.

[1] https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
[2] http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
[3] https://bugs.launchpad.net/fuel/+bug/1375750
[4]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
__
OpenStack Development Mailing 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] Nominating Roman Prykhodchenko to python-fuelclient cores

[Julia Aranovich]

+1

On Tue, Dec 1, 2015 at 10:29 PM Sergii Golovatiuk 
wrote:

> +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Dec 1, 2015 at 6:15 PM, Aleksey Kasatkin 
> wrote:
>
>> +1.
>> No doubts. )
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov 
>> wrote:
>>
>>> Guys,
>>>
>>> I propose to promote Roman Prykhodchenko to python-fuelclient cores. He
>>> is the main contributor and maintainer of this repo. And he did a great job
>>> making changes toward OpenStack recommendations. Cores, please reply with
>>> your +1/-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
>>
>>
> __
> OpenStack Development Mailing 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 UI] Support of separate provisioning is blocked by backend issues

[Julia Aranovich]

Hi fuelers,

Currently Fuel UI team is working on blueprint [1] to give Fuel UI user an
ability to launch provisioning of environment nodes separately from
deployment (without choosing particular nodes for now).

In the process we were faced with the following issues. Some of them block
the blueprint:

   - deployment constantly failed on environment with pre-provisioned nodes
   [2]
   - node pending_addition flag is reset to False for provisioned nodes
   [3]. This causes a lot of UX problems: provisioned node roles, disks,
   interfaces can not be reconfigured, node can not be deleted from
   environment, just can be marked as pending deletion (that requires
   environment deployment)
   - completed provisioning task has Null message. So, there is no to show
   the user after provisioning finished [4]
   - no notification comes on UI after provisioned finished [5]
   - fake provisioning task is also should be fixed: environment nodes stay
   in 'provisioning' status after provisioning finished [6]. This breaks fake
   Fuel UI workflow and brings difficulties in Fuel UI development.

Could you please consider/fix the tickets and help to unblock the blueprint
targeted for the current release.

Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
ISO.

Thank you!
Julia

[1]
https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
[2] https://bugs.launchpad.net/fuel/+bug/1515903
[3] https://bugs.launchpad.net/fuel/+bug/1515898
[4] https://bugs.launchpad.net/fuel/+bug/1515895
[5] https://bugs.launchpad.net/fuel/+bug/1515891
[6] https://bugs.launchpad.net/fuel/+bug/1515893
__
OpenStack Development Mailing 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 Custom node attributes feature

[Julia Aranovich]

The fuelclient request was merged with all needed +1s. Known issues are
filed to Launchpad:
https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli

So, we'll have a support of custom node labels both in Fuel UI and CLI in
7.0.

Thank you guys all who contributed to the feature and helped with review
and with everything else. Thanks Mike for granting the feature with an
additional day to merge the latest patch.
Will focus on the filed bugs for now.

Regards,
Julia


On Fri, Jul 24, 2015 at 1:16 PM Andrey Danin  wrote:

> I apologize for my hasty email earlier. Thank you all who tried to help me
> but I have to revoke my additions to this feature.
>
> I completely missed the fact that labels may be changed after the
> deployment is done. It creates inconsistency between label values and
> actual values in astute.yaml on the nodes. It's bad UX and it may break a
> cluster in some circumstances. Merging my code we just add a new tech dept
> into Fuel and it's not we want to do.
>
> So, thank you again, and I'll come up later with a better proposal for 8.0.
>
>
> On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky 
> wrote:
>
>> Fuelers,
>>
>> I'm ok to go with CLI part of this story. It's already implemented and
>> was actively reviewed yesterday.
>>
>> As for labels serialisation to astute.yaml.. I don't know it seems
>> pretty easy to implement, but we must be strict and do not accept any
>> exceptions because it's easy to implement. Otherwise, we'll start to
>> accept exceptions for all small changes and the story of 6.1 will
>> happened again.
>>
>> Thanks,
>> Igor
>>
>>
>> On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov
>>  wrote:
>> > Colleagues,
>> > it sounds like we need to complete what was requested by Julia here
>> (and it
>> > would take about a day as I understand), plus Andrey's request (which
>> seems
>> > to be very important for partner story and flexibility), plus additional
>> > pieces which turned into bugs [1].
>> >
>> > I'd like to hear opinion from fuel-web cores on this. I don't think we
>> can
>> > do all of what is requested.
>> >
>> > [1]
>> https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli
>> >
>> > On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin 
>> wrote:
>> >>
>> >> Hi, folks.
>> >>
>> >> I understand it may be not a good time but I want to make a proposal
>> >> regarding this feature.
>> >> The feature may be extremely useful for plugin developers if these
>> labels
>> >> would be serialized into astute.yaml. They may be used by plugin tasks
>> to do
>> >> node-specific modifications. Let me provide some examples:
>> >> * For Xen integration we need to provide unique Xen Server credentials
>> for
>> >> each Compute node. But with current architecture we don't have any
>> >> customizable per-node parameters.
>> >> * It may be possible to use special labels to override global values
>> (i.e.
>> >> libvirt_type, thus implementing BP
>> >> https://blueprints.launchpad.net/fuel/+spec/auto-virt-type).
>> >> * Another case may be the fencing. A user may put IPMI credentials into
>> >> labels.
>> >> And there are more cases like that.
>> >>
>> >> Despite the original spec doesn't have this idea I propose to implement
>> >> that. Moreover, I've already did it. Here are my two commits with a
>> spec
>> >> update [0] and an implementation[1]. They are pretty simple.
>> >>
>> >> [0] https://review.openstack.org/#/c/205105/
>> >> [1] https://review.openstack.org/#/c/205113/
>> >>
>> >>
>> >> Please grant FFE to this feature with my additions till tomorrow
>> evening.
>> >>
>> >> On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich
>> >>  wrote:
>> >>>
>> >>>
>> >>> Mike, thanks for the important points you've provided.
>> >>>
>> >>> My main argument for this FFE is the following: we've already got a
>> >>> confirmation from SME for this patch. But also got some not critical
>> >>> comments at the last minute before we were going to merge it and have
>> to
>> >>> handle it now. But it looks that these comments don't block the
>> feature and
>> >>> we can fix i

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

[Julia Aranovich]

Mike, thanks for the important points you've provided.

My main argument for this FFE is the following: we've already got a
confirmation from SME for this patch. But also got some not critical
comments at the last minute before we were going to merge it and have to
handle it now. But it looks that these comments don't block the feature and
we can fix it after merging a base patch.

We tested the patch and it matches an acceptance criteria for the feature
with some not critical known issues that already converted to launchpad
tickets.

I believe we can land it in master tomorrow with +1 from SME.

BTW, I see no intersection in reviewers with this patch
https://review.openstack.org/#/c/204321/.

Thank you,
Julia


On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov 
wrote:

> -1
> My concerns are the following:
>
>1. This feature is of a High priority, not Essential [1]
>2. We already had to give exception for flexible networking CLI part
>[2], as it is essential one. So basically that means we have a conflict of
>focus for SMEs in the area.
>3. Just by working on this, we don't spend time on bugs. Which
>increases risk of delivering on time with expected level of quality
>
> +390, -35 LOC also scare me a little bit, it's not a tiny change.
>
> One of the possible workarounds can be, if we deliver this patch after
> HCF, and have an updated package of client. If someone want it in
> experimental mode, then the one could update client package and have this
> functionality.
>
> If you convince me though that it can be finished by end of the week with
> only code reviews from SMEs (and only after flexible networking part is
> done), only after it I can change my mind.
>
> [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes
> [2] https://review.openstack.org/#/c/204321/
>
> On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski <
> skalinow...@mirantis.com> wrote:
>
>> +1 for this FFE as it's important to have this functionality covered in
>> CLI
>>
>> 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky :
>>
>>> Hi Julia,
>>>
>>> I'm ok with FF exception for CLI part. I don't think it can somehow
>>> decrease product quality, so as a core I'll help to land it.
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich
>>>  wrote:
>>> > Team,
>>> >
>>> > I would like to request an exception from the Feature Freeze for CLI
>>> changes
>>> > of working with custom node labels added to fuelclient (fuel2) [1]. UI
>>> and
>>> > Nailgun parts of the story are already merged [2].
>>> >
>>> > There CLI request is being actively reviewed, the base flow is
>>> accepted.
>>> > There are minimal risks here since the changes added to fuel2 version.
>>> >
>>> > Please, respond if you have any questions or concerns related to this
>>> > request.
>>> >
>>> > Thanks in advance,
>>> > Julia
>>> >
>>> > [1] https://review.openstack.org/#/c/204524/
>>> > [2] https://review.openstack.org/#/c/201472/
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing 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
>>
> --
> 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

[openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

[Julia Aranovich]

Team,

I would like to request an exception from the Feature Freeze for CLI
changes of working with custom node labels added to fuelclient (fuel2) [1].
UI and Nailgun parts of the story are already merged [2].

There CLI request is being actively reviewed, the base flow is accepted.
There are minimal risks here since the changes added to fuel2 version.

Please, respond if you have any questions or concerns related to this
request.

Thanks in advance,
Julia

[1] *https://review.openstack.org/#/c/204524/
*
[2] https://review.openstack.org/#/c/201472/
__
OpenStack Development Mailing 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

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

Re: [openstack-dev] [fuel][plugin][astute][UI] DSL restrictions with an action: "none" to display a message?

[Julia Aranovich]

You can setting up fake dev environment [1] based on the latest master, run
'npm install && gulp bower' from fuel-web/nailgun directory to load
uncompressed ui and its dependencies and replace nailgun/static dir with
compressed ui on your master node by the static dir from fake environment.

But this is a rather cumbersome way, and something can go wrong :) so I
would still suggest you to re-install with the last iso.

Hope this will be helpful for you!

[1] -
https://github.com/stackforge/fuel-web/blob/master/docs/develop/nailgun/development/env.rst#running-nailgun-in-fake-mode

On Thu, May 28, 2015 at 11:29 AM, Swann Croiset 
wrote:

> Many thanks Julia for the quick fix!
>
> Is it possible to update my fuel master to test this patch?  w/o download
> a new ISO and avoid to reinstall my env ?
>
> On Wed, May 27, 2015 at 6:04 PM, Julia Aranovich 
> wrote:
>
>> Hi,
>>
>> That's an issue of course. Settings definitely should support 'none'
>> action in their restrictions. Thank you for catching it!
>> And we've prepared the *fix*: https://review.openstack.org/#/c/186049/. It
>> should be merged ASAP.
>>
>> Best regards,
>> Julia
>>
>> On Wed, May 27, 2015 at 5:57 PM, Swann Croiset 
>> wrote:
>>
>>> Folks,
>>>
>>> With our plugin UI definition [0]  I'm trying to use a restriction with
>>> 'action: "none"' to display a message but nothing happen.
>>> According to the doc this should just works [1], btw I didn't find any
>>> similar example on fuel-web/nailgun.
>>> So I guess I hit a bug here or smth is wrong with plugin integration or
>>> I missed smth.
>>>
>>> Does somebody can confirm the bug and help to determine if it should be
>>> filled on 'fuel-plugin' or 'fuel' launchpad project?
>>>
>>> Thanks
>>>
>>> [0] https://review.openstack.org/#/c/184981/4/environment_config.yaml,cm
>>> [1]
>>> https://github.com/stackforge/fuel-web/blob/master/docs/develop/nailgun/customization/settings.rst#restrictions
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kind Regards,
>> Julia Aranovich,
>> Software Engineer,
>> Mirantis, Inc
>> +7 (905) 388-82-61 (cell)
>> Skype: juliakirnosova
>> www.mirantis.ru
>> jaranov...@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
>
>


-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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][plugin][astute][UI] DSL restrictions with an action: "none" to display a message?

[Julia Aranovich]

Hi,

That's an issue of course. Settings definitely should support 'none' action
in their restrictions. Thank you for catching it!
And we've prepared the *fix*: https://review.openstack.org/#/c/186049/. It
should be merged ASAP.

Best regards,
Julia

On Wed, May 27, 2015 at 5:57 PM, Swann Croiset 
wrote:

> Folks,
>
> With our plugin UI definition [0]  I'm trying to use a restriction with
> 'action: "none"' to display a message but nothing happen.
> According to the doc this should just works [1], btw I didn't find any
> similar example on fuel-web/nailgun.
> So I guess I hit a bug here or smth is wrong with plugin integration or I
> missed smth.
>
> Does somebody can confirm the bug and help to determine if it should be
> filled on 'fuel-plugin' or 'fuel' launchpad project?
>
> Thanks
>
> [0] https://review.openstack.org/#/c/184981/4/environment_config.yaml,cm
> [1]
> https://github.com/stackforge/fuel-web/blob/master/docs/develop/nailgun/customization/settings.rst#restrictions
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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] [UI] Sorting and filtering of node list

[Julia Aranovich]

Oleg, thank you for the feedback. We'll definitely consider it.

Also, I'd like to share some basic mockups for node sort/filter/group
operations: http://postimg.org/gallery/2c32wcu8q/

On Mon, Feb 16, 2015 at 11:20 AM, Oleg Gelbukh 
wrote:

> Julia,
>
> It would be nice to add grouping by Status to the existing 'Grouping'
> dropdown. It would save some time finding faulty/offline nodes in the list
> and performing bulk actions (like Delete) on them.
>
> Another useful feature for large deployments would be an ability to see IP
> addresses of nodes (including Management and Public addresses) in the UI
> and group/sort by those addresses.
>
> --
> Best regards,
> Oleg Gelbukh
> Mirantis Labs
>
> On Sat, Feb 14, 2015 at 11:27 AM, Julia Aranovich  > wrote:
>
>> Hi All,
>>
>> Currently we [Fuel UI team] are planning the features of *sorting and
>> filtering of node list *to introduce it in 6.1 release.
>>
>> Now user can filter nodes just by it's name or MAC address and no sorters
>> are available. It's rather poor UI for managing 200+ nodes environment. So,
>> the current suggestion is to filter and sort nodes by the following
>> parameters:
>>
>>1. name
>>2. manufacturer
>>3. IP address
>>4. MAC address
>>5. CPU
>>6. memory
>>7. disks total size (we need to think about "less than"/"more than"
>>representation)
>>8. interfaces speed
>>9. status (Ready, Pending Addition, Error, etc.)
>>10. roles
>>
>>
>> It will be a form-based filter. Items [1-4] should go to a single text
>> input and other go to a separate controls.
>> And also there is an idea to translate a user filter selection to a
>> query and add it to a location string. Like it's done for the logs search:
>> *#cluster/x/logs/type:local;source:api;level:info*.
>>
>> Please also note, that the changes we are thinking about should not
>> affect backend code.
>>
>>
>> I will be very grateful if you share your ideas about this or tell some
>> of the cases that would be useful to you at work with real deployments.
>> We would like to introduce really usefull tools based on your feedback.
>>
>>
>> Best regards,
>> Julia
>>
>> --
>> Kind Regards,
>> Julia Aranovich,
>> Software Engineer,
>> Mirantis, Inc
>> +7 (905) 388-82-61 (cell)
>> Skype: juliakirnosova
>> www.mirantis.ru
>> jaranov...@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
>
>


-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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-dev] [Fuel] [UI] Sorting and filtering of node list

[Julia Aranovich]

Hi All,

Currently we [Fuel UI team] are planning the features of *sorting and
filtering of node list *to introduce it in 6.1 release.

Now user can filter nodes just by it's name or MAC address and no sorters
are available. It's rather poor UI for managing 200+ nodes environment. So,
the current suggestion is to filter and sort nodes by the following
parameters:

   1. name
   2. manufacturer
   3. IP address
   4. MAC address
   5. CPU
   6. memory
   7. disks total size (we need to think about "less than"/"more than"
   representation)
   8. interfaces speed
   9. status (Ready, Pending Addition, Error, etc.)
   10. roles


It will be a form-based filter. Items [1-4] should go to a single text
input and other go to a separate controls.
And also there is an idea to translate a user filter selection to a query
and add it to a location string. Like it's done for the logs search:
*#cluster/x/logs/type:local;source:api;level:info*.

Please also note, that the changes we are thinking about should not affect
backend code.


I will be very grateful if you share your ideas about this or tell some of
the cases that would be useful to you at work with real deployments.
We would like to introduce really usefull tools based on your feedback.


Best regards,
Julia

-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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-dev] [Fuel] [UI] Deploy Changes dialog redesign

[Julia Aranovich]

Hi All,

Since we changed Deploy Changes pop-up and added processing of role limits
and restrictions <https://review.openstack.org/#/c/126930/> I would like to
raise a question of it's subsequent refactoring.

In particular, I mean 'changes' attribute of cluster model. It's displayed
in Deploy Changes dialog in the following format
<http://s2.postimg.org/ak9inonhl/deploy_changes_dialog.png>:

   - Changed disks configuration on the following nodes:
   - 
   - Changed interfaces configuration on the following nodes:
  - 
   - Changed network settings
   - Changed OpenStack settings

This list looks absolutely useless.

It doesn't make any sense to display lists of new, not deployed nodes with
changed disks/interfaces. It's obvious I think that new nodes attributes
await deployment. At the same time user isn't able to change
disks/interfaces on deployed nodes (at least in UI). So, such node name
lists are definitely redundant.
Networks and settings are also locked after deployment finished.


I tend to get rid of cluster model 'changes' attribute at all.

It is important for me to know your opinion, to make a final decision.
Please feel free and share your ideas and concerns if any.


Regards,
Julia

-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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] [Scale] [UI] Improvements to handle 200+ nodes

[Julia Aranovich]

Can we introduce both form-based and query language-based filter options?
Like 'Simple' and 'Advanced' mode on JIRA 'Issues' -> 'Search for issues'
page.

I also like a feature of saving custom user filters.
Maybe it's not critical fot the first iteration but I would consider it to
the next releases. And yes, this option will require an appropriate backend
changes.

On Tue, Jan 20, 2015 at 1:05 AM, Andrey Danin  wrote:

> Definitely, it should be a form-based filter. It's much more simpler than
> a pure query.
> Also, you can translate a user selection to a query and add to a location
> string (like it's done now for the Logs tab [1], for instance). It would
> allow a user to use a full power of queries.
>
> [1]
> http://demo.fuel-infra.org:8000/#cluster/874/logs/type:local;source:api;level:info
>
> On Fri, Jan 16, 2015 at 3:50 PM, Nikolay Markov 
> wrote:
>
>> It's also should be mentioned that these are several changes to do on
>> backend in order for UI to work faster, not on UI itself. For example,
>> these are:
>>
>> - Custom filters, as Vitaly mentioned
>> - Pagination of collections
>> - PATCH requests support
>> - Probably both short and /full representations for some entities
>>
>> On Fri, Jan 16, 2015 at 8:48 AM, Vitaly Kramskikh
>>  wrote:
>> > Folks,
>> >
>> > Currently Fuel UI can handle large amounts of nodes due to a recent
>> > refactoring - rendering and operations with nodes became much faster.
>> But
>> > that large amount of nodes also requires UX improvement, I'd love to
>> hear
>> > your ideas and opinions on these proposals:
>> >
>> > Introduce compact node representation and let users switch between
>> standart
>> > and compact view. Compact view will display only node name and status
>> and
>> > will allow to display 4-8 nodes in a row instead of only one.
>> > Currently it is only possible to filter node by names. Filtering feature
>> > could be extended to allow filtering by other parameters: status, roles,
>> > manufacturer, RAM, disk space. There are 2 options (I'd like to hear
>> which
>> > one you prefer):
>> >
>> > Form-based filter (beside a single input for name there will be
>> controls for
>> > other parameters)
>> > Query language-based filter (like one used in Gerrit)
>> >
>> > Add ability to add arbitrary tags with values to nodes and also allow
>> > filtering by them.
>> >
>> >
>> > --
>> > Vitaly Kramskikh,
>> > Software 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
>> >
>>
>>
>>
>> --
>> Best regards,
>> Nick Markov
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@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-dev] [Fuel] Support of warnings in Fuel UI

[Julia Aranovich]

Hi All,

First of all, I would like to inform you that support of warnings was added
on Settings tab in Fuel UI.
Now you can add 'message' attribute to setting restriction and it will be
displayed as a tooltip on the tab
<http://s4.postimg.org/hlxumo2sd/setting_warning.png> if restriction
condition is satisfied.

So, setting restriction should have the following format in openstack.yaml
<https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml>
file:

restrictions:
  - condition: "settings:common.libvirt_type.value != 'kvm'"
message: "KVM only is supported"

This format is also eligible for setting group restrictions and
restrictions of setting values (for setting with 'radio' type).

Please also note that message attribute can be also added to role
restrictions and will be displayed as a tooltip on Add Nodes screen.



And the second goal of my letter is to ask you to go through openstack.yaml
<https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml>
file
and add an appropriate messages for restrictions. It will make Fuel UI more
clear and informative.

Thank you in advance!

Julia

-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@mirantis.com 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev