Re: [openstack-dev] [fuel] Capacity table

[Vitaly Kramskikh]

If "new design" is the design you've proposed in the original email, then
no - we'll have to reopen the bug and then revert the change again.

2016-07-27 11:36 GMT+03:00 Dmitry Dmitriev :

> Hello Vitaly,
>
> Thank you for this answer.
> The main question here is the business logic.
> Do we have to use new design or don’t.
>
> With best regards, Dmitry
>
> On 26 Jul 2016, at 17:47, Vitaly Kramskikh 
> wrote:
>
> Hi, Dmitry,
>
> Your design seems to be similar to one of our attempts to fix this bug:
> https://review.openstack.org/#/c/280737/. Though this fix was reverted,
> because it led to the bug with a higher priority:
> https://bugs.launchpad.net/fuel/+bug/1556909. So your proposed design
> would lead to reopening of this bug.
>
> 2016-07-19 11:06 GMT+03:00 Dmitry Dmitriev :
>
>> Hello All!
>>
>> We have a very old bug about the Capacity table on the Dashboard tab of
>> environment in Fuel:
>>
>> https://bugs.launchpad.net/fuel/+bug/1375750
>>
>> Current design:
>>
>> https://drive.google.com/open?id=0Bxi_JFs365mBNy1WT0xQT253SWc
>>
>> It shows the full capacity (CPU/Memory/HDD) of all discovered by Fuel
>> nodes.
>>
>> New design:
>>
>> https://drive.google.com/open?id=0Bxi_JFs365mBaWZ0cUtla3N6aEU
>>
>> It contains compute node CPU/Memory capacity and Ceph disk capacity only.
>>
>> New design pros:
>> - cloud administrator can easily estimate all available resources for
>> cloud instances
>>
>> New design cons:
>> - if cloud doesn’t use Ceph then HDD value is zero
>>
>> What do you think about the new design?
>>
>> With best regards, Dmitry
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Capacity table

[Vitaly Kramskikh]

Hi, Dmitry,

Your design seems to be similar to one of our attempts to fix this bug:
https://review.openstack.org/#/c/280737/. Though this fix was reverted,
because it led to the bug with a higher priority:
https://bugs.launchpad.net/fuel/+bug/1556909. So your proposed design would
lead to reopening of this bug.

2016-07-19 11:06 GMT+03:00 Dmitry Dmitriev :

> Hello All!
>
> We have a very old bug about the Capacity table on the Dashboard tab of
> environment in Fuel:
>
> https://bugs.launchpad.net/fuel/+bug/1375750
>
> Current design:
>
> https://drive.google.com/open?id=0Bxi_JFs365mBNy1WT0xQT253SWc
>
> It shows the full capacity (CPU/Memory/HDD) of all discovered by Fuel
> nodes.
>
> New design:
>
> https://drive.google.com/open?id=0Bxi_JFs365mBaWZ0cUtla3N6aEU
>
> It contains compute node CPU/Memory capacity and Ceph disk capacity only.
>
> New design pros:
> - cloud administrator can easily estimate all available resources for
> cloud instances
>
> New design cons:
> - if cloud doesn’t use Ceph then HDD value is zero
>
> What do you think about the new design?
>
> With best regards, Dmitry
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge IRC channels

[Vitaly Kramskikh]

+1 for this, #fuel-ui should also be merged there I think.

2016-06-24 13:26 GMT+03:00 Vladimir Kozhukalov :

> Dear colleagues,
>
> We have a few IRC channels but the level of activity there is quite low.
>
> #fuel
> #fuel-dev
> #fuel-python
> #fuel-infra
>
> My suggestion is to merge all these channels into a single IRC channel
> #fuel.
> Other #fuel-* channels are to be deprecated.
>
> What do you think of this?
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing 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] [javascript] [infra] NPM Mirrors (IMPORTANT)

[Vitaly Kramskikh]

It seems this issue started to affect us on OpenStack infra about 13 hours
ago. The main 2 reasons of failing tests are "Unexpected end of
input"/"registry error parsing json" (example
<http://logs.openstack.org/19/315119/5/check/gate-fuel-ui-npm-run-lint/2622df4/console.html>)
and "Error: socket hang up" (example
<http://logs.openstack.org/04/318204/2/check/gate-fuel-ui-npm-run-lint/a390ea7/console.html>).
See https://review.openstack.org/#/c/315119/ for a long list of similar
failures (though almost every gate-fuel-ui-npm-run-lint run now fails).

What should we do?

2016-05-16 16:58 GMT+03:00 Michael Krotscheck :

> Hey there, Vitaly-
>
> I suspect that the issue you're encountering is actually a cross-atlantic
> lag, combined with the Mirror's AFS cache warming up. As of this morning,
> fuel-ui seems to be installing fine from dfw.rax, though you may run into
> similar issues with other mirrors until those caches warm up.
>
> Michael
>
> On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh 
> wrote:
>
>> Hi, Michael,
>>
>> I randomly get "error parsing json" for fuel-ui
>> <https://github.com/openstack/fuel-ui> project:
>> http://paste.openstack.org/show/496871/. Got such errors 2 times out of
>> 5.
>>
>> 2016-05-11 22:07 GMT+03:00 Michael Krotscheck :
>>
>>> Hello everyone!
>>>
>>> We've recently added NPM mirrors to our infrastructure, and are about to
>>> turn them on. Before that happens, however, we'd like to get a sanity check
>>> from impacted projects to make sure that we don't wedge your gate.
>>>
>>> If you are in charge of a project that invokes `npm install` during any
>>> of its gate jobs, then please invoke the following commands at your project
>>> root.
>>>
>>> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
>>> rm -rf ./node_modules/
>>> rm -rf ~/.npm/
>>> npm install
>>>
>>> If you encounter an error, put it in paste.openstack.org and reply to
>>> this thread. If not, great! Delete the .npmrc file and go on your merry way.
>>>
>>> Have a great day!
>>>
>>> Michael
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [javascript] [eslint-config-openstack] ECMAScript 6 / ECMAScript2015 rules.

[Vitaly Kramskikh]

As of now, I've created review requests to enable all the rules used for
Fuel UI except these:

http://eslint.org/docs/rules/object-shorthand
http://eslint.org/docs/rules/prefer-arrow-callback
http://eslint.org/docs/rules/prefer-spread

Enabling them will break valid ES5 code, and I didn't find a way to disable
them for ES5 code - even if env.es6 is false and parserOptions.ecmaVersion
is 5, ESLint applies these rules. So probably they should be enabled after
significant adoption of ES6.

2016-05-12 19:17 GMT+03:00 Michael Krotscheck :

> Fuel has already adopted ES6, and is moving to adopt
> eslint-config-openstack. To help them, Vitaly's started to propose language
> style rules for ES6, which are available to review at the below link:
>
>
> https://review.openstack.org/#/q/topic:es6+project:openstack/eslint-config-openstack
>
> Please take a moment to review these rules. As a reminder, approval for
> eslint-config-openstack requires that a rule receives five positive votes,
> with no negative ones.
>
> Have a great day!
>
> Michael
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

[Vitaly Kramskikh]

Hi, Michael,

I randomly get "error parsing json" for fuel-ui
<https://github.com/openstack/fuel-ui> project:
http://paste.openstack.org/show/496871/. Got such errors 2 times out of 5.

2016-05-11 22:07 GMT+03:00 Michael Krotscheck :

> Hello everyone!
>
> We've recently added NPM mirrors to our infrastructure, and are about to
> turn them on. Before that happens, however, we'd like to get a sanity check
> from impacted projects to make sure that we don't wedge your gate.
>
> If you are in charge of a project that invokes `npm install` during any of
> its gate jobs, then please invoke the following commands at your project
> root.
>
> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
> rm -rf ./node_modules/
> rm -rf ~/.npm/
> npm install
>
> If you encounter an error, put it in paste.openstack.org and reply to
> this thread. If not, great! Delete the .npmrc file and go on your merry way.
>
> Have a great day!
>
> Michael
>
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Newton Design Summit sessions planning

[Vitaly Kramskikh]

Folks,

I'd like to request workroom sessions swap.

I planned to lead a discussion of Fuel UI modularization on Wed
11.00-11.40, but at the same time there will be discussion of handling JS
dependencies of Horizon which I'd really like to attend.

So I request to swap my discussion with discussion of finalizing of HA
reference architecture with event-based control and fencing led by V.
Kuklin on Thu 11.00-11.40.

Do you have any objections?

2016-04-14 17:55 GMT+03:00 Alexey Shtokolov :

> Hi, +1 from my side.
>
> ---
> WBR, Alexey Shtokolov
>
> 2016-04-14 16:47 GMT+03:00 Evgeniy L :
>
>> Hi, no problem from my side.
>>
>> On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dear colleagues,
>>>
>>> I'd like to request workrooms sessions swap.
>>>
>>> We have a session about Fuel/Ironic integration and I'd like
>>> this session not to overlap with Ironic sessions, so Ironic
>>> team could attend Fuel sessions. At the same time, we have
>>> a session about orchestration engine and it would be great to
>>> invite there people from Mistral and Heat.
>>>
>>> My suggestion is as follows:
>>>
>>> Wed:
>>> 9:50 Astute -> Mistral/Heat/???
>>> Thu:
>>> 9.00 Fuel/Ironic/Ironic-inspector
>>>
>>> If there are any objections, please let me know asap.
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Fri, Apr 1, 2016 at 9:47 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
>>>> Dear colleagues,
>>>>
>>>> Looks like we have final version sessions layout [1]
>>>> for Austin design summit. We have 3 fishbows,
>>>> 11 workrooms, full day meetup.
>>>>
>>>> Here you can find some useful information about design
>>>> summit [2]. All session leads must read this page,
>>>> be prepared for their sessions (agenda, slides if needed,
>>>> etherpads for collaborative work, etc.) and follow
>>>> the recommendations given in "At the Design Summit" section.
>>>>
>>>> Here is Fuel session planning etherpad [3]. Almost all suggested
>>>> topics have been put there. Please put links to slide decks
>>>> and etherpads next to respective sessions. Here is the
>>>> page [4] where other teams publish their planning pads.
>>>>
>>>> If session leads want for some reason to swap their slots it must
>>>> be requested in this ML thread. If for some reason session lead
>>>> can not lead his/her session, it must be announced in this ML thread.
>>>>
>>>> Fuel sessions are:
>>>> ===
>>>> Fishbowls:
>>>> ===
>>>> Wed:
>>>> 15:30-16:10
>>>> 16:30:17:10
>>>> 17:20-18:00
>>>>
>>>> ===
>>>> Workrooms:
>>>> ===
>>>> Wed:
>>>> 9:00-9:40
>>>> 9:50-10:30
>>>> 11:00-11:40
>>>> 11:50-12:30
>>>> 13:50-14:30
>>>> 14:40-15:20
>>>> Thu:
>>>> 9:00-9:40
>>>> 9:50-10:30
>>>> 11:00-11:40
>>>> 11:50-12:30
>>>> 13:30-14:10
>>>>
>>>> ===
>>>> Meetup:
>>>> ===
>>>> Fri:
>>>> 9:00-12:30
>>>> 14:00-17:30
>>>>
>>>> [1]
>>>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/d59d38b7/attachment.pdf
>>>> [2] https://wiki.openstack.org/wiki/Design_Summit
>>>> [3] https://etherpad.openstack.org/p/fuel-newton-summit-planning
>>>> [4] https://wiki.openstack.org/wiki/Design_Summit/Planning
>>>>
>>>> Thanks.
>>>>
>>>> Vladimir Kozhukalov
>>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel][Nailgun] Random failures in unit tests

[Vitaly Kramskikh]

Igor,

We have UI and CLI integration tests which use fake mode of Nailgun, and we
can't avoid using fake threads for them. So I think we need to think how to
fix fake threads instead. There is a critical bug
<https://bugs.launchpad.net/fuel/+bug/1549750> which is the main reason of
randomly failing UI tests. To fix it, we need to fix fake threads behaviour.

2016-03-16 17:06 GMT+03:00 Igor Kalnitsky :

> Hey Fuelers,
>
> As you might know recently we encounter a lot of random test failures
> on CI, and they are still there (likely with a bit less probability).
> A nature of that random failures is actually not a random, they are
> happened because of so called fake threads.
>
> Fake threads, actually, ain't fake at all. They are native OS threads
> that are designed to emulate Astute behaviour (i.e. catch RPC call and
> respond with appropriate message). Since they are native threads and
> we use SQLAlchemy's scoped_session, fake threads are using a separate
> database session, hence - transaction. That leads to the following
> issues:
>
> * Races. We don't know when threads are switched, therefore, we don't
> know what's committed and what's not. Some Nailgun tests sends
> something via RPC (catched by fake threads) and immediately checks
> something. The issue is, we can't guarantee fake threads is already
> committed produced result. That could be avoided by waiting for
> 'ready' status of created nailgun task, however, it's better to simply
> do not use fake threads in that case and simply call appropriate
> Nailgun receiver's method directly in the test.
>
> * Deadlocks. It's incredibly hard to ensure the same order of database
> locks in test + business code on one hand and fake thread code on
> other hand. That's why we can (and we do) encounter deadlocks on CI,
> when test case waits for lock acquired by fake thread, and fake thread
> waits for lock acquired by test case.
>
> Fake threads are became a bottleneck of landing patches to master in
> time, and we can't ignore it anymore. We have ~190 tests that use fake
> threads, and fixing them all at once is a boring routine. So I kindly
> ask Nailgun contrubitors to fix them as soon as we face them. Let's
> file a bug on each file in CI, and quicly prepare a separate patch
> that removes fake thread from failed test.
>
> Thanks in advance,
> Igor
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Vitaly Kramskikh]

ing this topic in our couloirs before but I’d
>> like
>> to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>>
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can
>> deal
>> with logs much more effectively.
>>
>>
>> There may be more reasons bus I think even the already mentioned ones are
>>
>> enough to think about the following proposal:
>>
>> - Remove Logs tab from Fuel Web UI
>> - Remove logs support from Nailgun
>> - Create mechanism that allows to configure different log management
>> software, say Logstash, Loggly, etc
>>
>> - Choose a default software to install and provide a plugin for it from
>> the box
>>
>>
>>
>> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
>> develop anything new.
>>
>> And I'm +1 with the removal of log management from Fuel. As you said, it
>> can't scale...
>>
>> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
>> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>>
>>
>>
>>
>>
>> References
>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
>> 2. https://www.elastic.co/products/logstash
>>
>>
>> - romcheg
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>><http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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
>>
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vitaly Kramskikh]

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

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

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

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

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



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vitaly Kramskikh]

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

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

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

> Vitaly
>
> Thanks for bringing this up. Actually the spec has been on review for
> almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially,
> this is not introducing new DSL but replacing the existing one with more
> powerful extendable language which is being actively developed within
> OpenStack and is already a part of other projects (Murano, Mistral), which
> has much more contributors, can return not only boolean but any arbitrary
> collections. So it means that we want to deprecate current Expression
> language that you wrote and replace it with YAQL due to those reasons. You
> are not going to extend this Expression-based language in 3 weeks up to
> level of support of extensions, method overloading, return of arbitrary
> collections (e.g. we also want to calculate cross-depends and requires
> fields on the fly which require for it to return list of dicts) and support
> of this stuff on your own, are you?
>
> On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh  > wrote:
>
>> I think it's not a part of best practices to introduce changes like
>> https://review.openstack.org/#/c/279714/ (adding yet another DSL to the
>> project) without a blueprint and review and discussion of the spec.
>>
>> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov :
>>
>>> Fuelers,
>>>
>>> I would like to request a feature freeze exception for "Unlock settings
>>> tab" feature [0]
>>>
>>> This feature being combined with Task-based deployment [1] and
>>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We
>>> conducted a thorough redesign of this feature and splitted it into several
>>> granular changes [3]-[6] to allow users to change settings on deployed,
>>> partially deployed, stopped or erred clusters and further run redeployment
>>> using a particular graph (custom or calculated based on expected changes
>>> stored in DB) and with new parameters.
>>>
>>> We need 3 weeks after FF to finish this feature.
>>> Risk of not delivering it after 3 weeks is low.
>>>
>>> Patches on review or in progress:
>>> <https://review.openstack.org/#/c/284139/>
>>> https://review.openstack.org/#/c/284139/
>>> https://review.openstack.org/#/c/279714/
>>> https://review.openstack.org/#/c/286754/
>>> https://review.openstack.org/#/c/286783/
>>>
>>> Specs:
>>> https://review.openstack.org/#/c/286713/
>>> https://review.openstack.org/#/c/284797/
>>> https://review.openstack.org/#/c/282695/
>>> https://review.openstack.org/#/c/284250/
>>>
>>>
>>> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
>>> <https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab>[1]
>>> https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
>>> [2]
>>> https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
>>> [3]
>>> https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
>>> [4]
>>> https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
>>> [5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
>>> [6]
>>> https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database
>>>
>>> --
>>> ---
>>> WBR, Alexey Shtokolov
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> Mirantis, Inc.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsu

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

[Vitaly Kramskikh]

I think it's not a part of best practices to introduce changes like
https://review.openstack.org/#/c/279714/ (adding yet another DSL to the
project) without a blueprint and review and discussion of the spec.

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

> Fuelers,
>
> I would like to request a feature freeze exception for "Unlock settings
> tab" feature [0]
>
> This feature being combined with Task-based deployment [1] and
> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We
> conducted a thorough redesign of this feature and splitted it into several
> granular changes [3]-[6] to allow users to change settings on deployed,
> partially deployed, stopped or erred clusters and further run redeployment
> using a particular graph (custom or calculated based on expected changes
> stored in DB) and with new parameters.
>
> We need 3 weeks after FF to finish this feature.
> Risk of not delivering it after 3 weeks is low.
>
> Patches on review or in progress:
> <https://review.openstack.org/#/c/284139/>
> https://review.openstack.org/#/c/284139/
> https://review.openstack.org/#/c/279714/
> https://review.openstack.org/#/c/286754/
> https://review.openstack.org/#/c/286783/
>
> Specs:
> https://review.openstack.org/#/c/286713/
> https://review.openstack.org/#/c/284797/
> https://review.openstack.org/#/c/282695/
> https://review.openstack.org/#/c/284250/
>
>
> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
> <https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab>[1]
> https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
> [2]
> https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
> [3]
> https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
> [4]
> https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
> [5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
> [6]
> https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database
>
> --
> ---
> WBR, Alexey Shtokolov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vitaly Kramskikh]

The new repo has been created: https://github.com/openstack/fuel-ui. Please
move all change requests there. Fuel UI code in fuel-web repo is going to
be removed soon.

2016-02-26 19:53 GMT+07:00 Vladimir Kozhukalov :

> Dear colleagues,
>
> We are ready for moving UI javascript code to a separate git repository.
> Since now all review requests for fuel-web@master that are related to UI
> must be marked -2 and later abandoned. Once new project fuel-ui is created
> those changes should be backported to this new repository.
>
> Checklist:
>
>
>- Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
>- openstack-infra
>   - project-config https://review.openstack.org/#/c/260455 (ON REVIEW)
>   - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
>- fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
>- label jenkins slaves for the new job (ci team)
>- UI directory freeze (DONE)
>- prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
>- waiting for openstack-infra patches to be merged
>- .gitreview .gitignore MAINTAINERS (TODO)
>- rpm spec (TODO)
>- custom ci jobs (TODO)
>- fuel-main (TODO)
>- packaging ci (TODO)
>- remove old files (TODO)
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing 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

[Vitaly Kramskikh]

+1

2016-02-25 16:41 GMT+07:00 Sergey Kulanov :

> +1
>
> 2016-02-25 11:37 GMT+02:00 Alexander Kislitsky :
>
>> +1
>>
>> On Thu, Feb 25, 2016 at 12:32 PM, Bulat Gaifullin <
>> bgaiful...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> Regards,
>>> Bulat Gaifullin
>>> Mirantis Inc.
>>>
>>>
>>>
>>> On 24 Feb 2016, at 16:02, Aleksandr Didenko 
>>> wrote:
>>>
>>> +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 <http://www.mirantis.ru/>
>>>> www.mirantis.ru
>>>> vkuk...@mirantis.com
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Sergey
> DevOps Engineer
> IRC: SergK
> Skype: Sergey_kul
>
> __
> OpenStack Development Mailing List (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

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

[Vitaly Kramskikh]

We use HTTPS url for the title and HTTP url for the small link with (HTTP)
text near the title:



​

2016-02-12 17:09 GMT+07:00 Igor Kalnitsky :

> Vitaly,
>
> > Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon
> and every plugin link
>
> Why? And how do you handle it with link now?
>
> On Fri, Feb 12, 2016 at 11:15 AM, Vitaly Kramskikh
>  wrote:
> > Igor,
> >
> > Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon
> and
> > every plugin link, which would look quite ugly. We had all these options
> in
> > mind when we designed this change and decided to go with the current
> look.
> >
> > Seriously guys, I don't understand you concerns. After dismissing the
> > deployment result message, Horizon link is in the top block on the
> dashboard
> > - it's very hard to get lost.
> >
> > 2016-02-11 20:10 GMT+07:00 Igor Kalnitsky :
> >>
> >> Vitaly,
> >>
> >> What about adding some button with "Go" or "Visit" text? Somewhere on
> >> the right size of line? It'd be easy to understand what to click to
> >> visit the dashboard.
> >>
> >> - Igor
> >>
> >> On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh
> >>  wrote:
> >> > Roman,
> >> >
> >> > For with enabled SSL it still can be quite long as it contains FQDN.
> And
> >> > we
> >> > also need to change plugin link representation accordingly, which I
> >> > don't
> >> > fine acceptable. I think you just got used to the old interface where
> >> > the
> >> > link to Horizon was a part of deployment task result message. We've
> >> > merged
> >> > small style update to underline Horizon/plugin links, I think it would
> >> > be
> >> > enough to solve the issue.
> >> >
> >> > 2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko :
> >> >>
> >> >> Cannot we use display the same link we use in the title?
> >> >>
> >> >> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh 
> >> >> написав(ла):
> >> >>
> >> >> Hi, Roman,
> >> >>
> >> >> I think the only solution here is to underline the title so it would
> >> >> look
> >> >> like a link. I don't think it's a good idea to show full URL because:
> >> >>
> >> >> If SSL is enabled, there will be 2 links - HTTP and HTTPS.
> >> >> Plugins can provide their own links for their dashboards, and they
> >> >> would
> >> >> be shown using exactly the same representation which is used for
> >> >> Horizon.
> >> >> These links could be quite long.
> >> >>
> >> >>
> >> >> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :
> >> >>>
> >> >>> Whoops! I forgot to attach the link. Sorry!
> >> >>>
> >> >>> 1. http://i.imgur.com/8GaUtDq.png
> >> >>>
> >> >>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko 
> >> >>> > написав(ла):
> >> >>> >
> >> >>> > Hi fuelers!
> >> >>> >
> >> >>> > I’m not sure, if it’s my personal problem or the UX can be
> improved
> >> >>> > a
> >> >>> > little, but I’ve literary spend more than 5 minutes trying to
> figure
> >> >>> > out how
> >> >>> > to find a URL of Horizon. I’ve made a screenshot [1] and I suggest
> >> >>> > to add a
> >> >>> > full a link with the full URL in its test after "The OpenStack
> >> >>> > dashboard
> >> >>> > Horizon is now available". That would make things much more
> usable.
> >> >>> >
> >> >>> >
> >> >>> > - 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
> >&g

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

[Vitaly Kramskikh]

Igor,

Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon and
every plugin link, which would look quite ugly. We had all these options in
mind when we designed this change and decided to go with the current look.

Seriously guys, I don't understand you concerns. After dismissing the
deployment result message, Horizon link is in the top block on the
dashboard - it's very hard to get lost.

2016-02-11 20:10 GMT+07:00 Igor Kalnitsky :

> Vitaly,
>
> What about adding some button with "Go" or "Visit" text? Somewhere on
> the right size of line? It'd be easy to understand what to click to
> visit the dashboard.
>
> - Igor
>
> On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh
>  wrote:
> > Roman,
> >
> > For with enabled SSL it still can be quite long as it contains FQDN. And
> we
> > also need to change plugin link representation accordingly, which I don't
> > fine acceptable. I think you just got used to the old interface where the
> > link to Horizon was a part of deployment task result message. We've
> merged
> > small style update to underline Horizon/plugin links, I think it would be
> > enough to solve the issue.
> >
> > 2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko :
> >>
> >> Cannot we use display the same link we use in the title?
> >>
> >> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh 
> >> написав(ла):
> >>
> >> Hi, Roman,
> >>
> >> I think the only solution here is to underline the title so it would
> look
> >> like a link. I don't think it's a good idea to show full URL because:
> >>
> >> If SSL is enabled, there will be 2 links - HTTP and HTTPS.
> >> Plugins can provide their own links for their dashboards, and they would
> >> be shown using exactly the same representation which is used for
> Horizon.
> >> These links could be quite long.
> >>
> >>
> >> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :
> >>>
> >>> Whoops! I forgot to attach the link. Sorry!
> >>>
> >>> 1. http://i.imgur.com/8GaUtDq.png
> >>>
> >>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko 
> написав(ла):
> >>> >
> >>> > Hi fuelers!
> >>> >
> >>> > I’m not sure, if it’s my personal problem or the UX can be improved a
> >>> > little, but I’ve literary spend more than 5 minutes trying to figure
> out how
> >>> > to find a URL of Horizon. I’ve made a screenshot [1] and I suggest
> to add a
> >>> > full a link with the full URL in its test after "The OpenStack
> dashboard
> >>> > Horizon is now available". That would make things much more usable.
> >>> >
> >>> >
> >>> > - 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
> >>>
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >
> >
> >
> > --
> > 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
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

[Vitaly Kramskikh]

Roman,

For with enabled SSL it still can be quite long as it contains FQDN. And we
also need to change plugin link representation accordingly, which I don't
fine acceptable. I think you just got used to the old interface where the
link to Horizon was a part of deployment task result message. We've merged
small style update to underline Horizon/plugin links, I think it would be
enough to solve the issue.

2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko :

> Cannot we use display the same link we use in the title?
>
> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh 
> написав(ла):
>
> Hi, Roman,
>
> I think the only solution here is to underline the title so it would look
> like a link. I don't think it's a good idea to show full URL because:
>
>- If SSL is enabled, there will be 2 links - HTTP and HTTPS.
>- Plugins can provide their own links for their dashboards, and they
>would be shown using exactly the same representation which is used for
>Horizon. These links could be quite long.
>
>
> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :
>
>> Whoops! I forgot to attach the link. Sorry!
>>
>> 1. http://i.imgur.com/8GaUtDq.png
>>
>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko  написав(ла):
>> >
>> > Hi fuelers!
>> >
>> > I’m not sure, if it’s my personal problem or the UX can be improved a
>> little, but I’ve literary spend more than 5 minutes trying to figure out
>> how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to
>> add a full a link with the full URL in its test after "The OpenStack
>> dashboard Horizon is now available". That would make things much more
>> usable.
>> >
>> >
>> > - romcheg
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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://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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

[Vitaly Kramskikh]

Hi, Roman,

I think the only solution here is to underline the title so it would look
like a link. I don't think it's a good idea to show full URL because:

   - If SSL is enabled, there will be 2 links - HTTP and HTTPS.
   - Plugins can provide their own links for their dashboards, and they
   would be shown using exactly the same representation which is used for
   Horizon. These links could be quite long.


2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :

> Whoops! I forgot to attach the link. Sorry!
>
> 1. http://i.imgur.com/8GaUtDq.png
>
> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko  написав(ла):
> >
> > Hi fuelers!
> >
> > I’m not sure, if it’s my personal problem or the UX can be improved a
> little, but I’ve literary spend more than 5 minutes trying to figure out
> how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to
> add a full a link with the full URL in its test after "The OpenStack
> dashboard Horizon is now available". That would make things much more
> usable.
> >
> >
> > - 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

[Vitaly Kramskikh]

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

Re: [openstack-dev] [Fuel] [Fuel UI] UI text guidelines

[Vitaly Kramskikh]

Olga,

That's awesome! This document will help us a lot. Thanks for your work!

2016-01-29 17:01 GMT+03:00 Olga Gusarenko :

> Good Friday to everyone!
>
> This is just to inform you that UI text guidelines are now available in
> the Contributor Guide:
>
> http://docs.openstack.org/contributor-guide/ui-text-guidelines.html
>
> This will be interesting for designers and developers, as well as
> reviewers, who works on OpenStack user interfaces. Please follow these
> recommendations to ensure UI usability and consistency.
>
> Special thanks to Linette Williams and Gudrun Wolfgram for working on this!
>
> --
> Best regards,
> Olga Gusarenko
>
> Technical Writer | Mirantis, Kharkiv | 38, Lenin av., Kharkiv, Ukraine
> ogusare...@mirantis.com | skype: gusarenko.olga
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel][Plugins] How do avoid duplicated links in the dashboard?

[Vitaly Kramskikh]

Hi,

Sounds like a bug. I think we should prohibit adding duplicate links on
nailgun side, using link title + link url as a key.

I've created a bug: https://bugs.launchpad.net/fuel/+bug/1538209. I hope it
will be fixed by the HCF so that the fix will be included in 8.0.

2016-01-26 19:23 GMT+03:00 Simon Pasquier :

> Hi all,
>
> In the scope of the LMA plugins, we've played with the new ability to
> insert links in the Fuel dashboard. This works fine from the UI standpoint
> except that to avoid creating duplicate links we've come up with a solution
> that is intricate and brittle IMO.
> Basically we have an exec resource that sends a POST request to the Fuel
> API and creates a "sentinel" file on the local filesystem if it succeeds
> [1]. If the Puppet manifest is re-executed later on, the exec resource
> won't be applied again if that file exists.
> The problem arises when the node that created the link is re-provisioned
> or replaced since it will generate duplicated links eventually.
> Have someone find a better way to manage this?
>
> Regards,
> Simon
>
> [1]
> https://github.com/openstack/fuel-plugin-elasticsearch-kibana/blob/b85348aa964964f47dad1b08438e2d803ff20544/deployment_scripts/puppet/manifests/provision_services.pp#L38-L43
>
> __
> OpenStack Development Mailing 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-dev] [Fuel] nova-network removal

[Vitaly Kramskikh]

Folks,

We have a request on review which prohibits creating new envs with
nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks away
from HCF, and I think this is too late for such a change. What do you
think? Should we proceed and remove nova-network support in 8.0, which is
deprecated since 7.0?

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Nailgun] Deadlocks and random test failures

[Vitaly Kramskikh]

Alexander,

Thanks for the response.

As for tasks hanging bug, I removed "deadlock" from its title: there is
another exception, which I didn't find due to huge number of traces from
deadlock detector.

As for random test failures bugs, I totally agree we should focus on them.
Just look at this: https://review.openstack.org/#/c/262183/ - I ran
"recheck" 5 times, rebased on master 1 time and still no luck: sometimes I
get -1 from Jenkins, sometimes from Fuel CI. I think this is a Critical
issue.

2015-12-30 16:39 GMT+03:00 Alexander Kislitsky :

> Hi, guys.
>
> Igor is absolutelly right - there are no deadlocks. We have only warnings
> from detector, but they caused by difference between actual locking order
> in the code and allowed by detector. It is annoying, but detection is used
> only in development environment, thus it is not high bug.
>
> When DB deadlock occurs we have ShareLock exception in the logs and it
> raised before detector warning. So we always have deadlock exception in the
> logs if it occurs.
> I think tests failures are caused by another issue. As I can see we have a
> set of random failures in the tests now and bugs on it:
>
> https://bugs.launchpad.net/fuel/+bug/1437232
> https://bugs.launchpad.net/fuel/+bug/1502908
> https://bugs.launchpad.net/fuel/+bug/1518268
> https://bugs.launchpad.net/fuel/+bug/1521966
>
> We should focus on fixing these bugs. Could you please help us with
> detection of the root cause of UI tests failures? May be we have another
> floating bug in tests.
>
> On Wed, Dec 30, 2015 at 4:11 PM, Igor Kalnitsky 
> wrote:
>
>> Hey Vitaly,
>>
>> Are you the problem is in deadlock? I see the deadlock detecter
>> traceback, but not an actual deadlock.
>>
>> I'm not sure could it be a reason for failure or not, it's better to
>> ask Alexander Kislitsky.
>>
>> Thanks,
>> Igor
>>
>> On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
>>  wrote:
>> > Hi,
>> >
>> > We have a long-living issue with deadlocks in nailgun which used to
>> almost
>> > harmless and caused rare test failures. But test failures become more
>> > frequent and today there is ~20% probability that they will fail on a
>> > working code, which is really annoying. Moreover, a few weeks ago it
>> started
>> > to affect UI functional tests: cluster reset task may hang, so this
>> issue
>> > now may affect real deployments.
>> >
>> > I think we need to do something with it ASAP.
>> >
>> > --
>> > 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
>>
>
>
> __
> OpenStack Development Mailing 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-dev] [Fuel] [Nailgun] Deadlocks and random test failures

[Vitaly Kramskikh]

Hi,

We have a long-living issue with deadlocks in nailgun which used to almost
harmless and caused rare test failures. But test failures become more
frequent and today there is ~20% probability that they will fail on a
working code, which is really annoying. Moreover, a few weeks ago it
started to affect UI functional tests: cluster reset task may hang
<https://bugs.launchpad.net/fuel/+bug/1529613>, so this issue now may
affect real deployments.

I think we need to do something with it ASAP.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge Freeze for cutting stable/8.0 branch

[Vitaly Kramskikh]

Aleksandra,

What are "base packages"? Can we merge to fuel-web?

2015-12-24 18:01 GMT+03:00 Aleksandra Fedorova :

> Hi, everyone,
>
> we merged all versioning patches so now Fuel master is versioned as Fuel
> 9.0.
>
> Merge freeze is lifted.
>
> Please note:
>
> * Fuel master is now open but only for changes which are still
> compatible with 8.0 base repositories.
>
> All Base OS and OpenStack packages including those that are Fuel
> dependencies are currently copied from 8.0 repo and freezed. Please
> don't yet merge Fuel changes which require update in base packages.
>
> * All bug fixes needs to be merged in master first and then
> cherry-picked to stable/8.0 branch
>
> On Thu, Dec 24, 2015 at 3:40 PM, Roman Vyalov 
> wrote:
> > Aleksandra,
> > we dont have problems with inconsistent 9.0 repositories. But we found
> the
> > problem with process of building our ISO[0].
> > It floating bug, but we found the main problem and solve it today
> >
> > [0] https://bugs.launchpad.net/fuel/+bug/1529073
> >
> > On Thu, Dec 24, 2015 at 5:14 AM, Aleksandra Fedorova
> >  wrote:
> >>
> >> Hi, here is the status update:
> >>
> >> - we created stable/8.0 branch in all repositories;
> >> - Fuel CI [1] is updated with 8.0 triggers and jobs, fuel-library
> >> tests are working on pre-SCF ISO image still;
> >> - 8.0 ISO builds are switched to stable/8.0 branch, see [2] for the
> first
> >> run;
> >> - development focus in Launchpad has been switched to mitaka(9.0) series
> >> [3]
> >>
> >> If you file a bug for 8.0 release, please make sure you explicitly
> >> target it to 8.0.x series additionally to the mitaka series which it
> >> gets by default.
> >>
> >> Remaining tasks:
> >>
> >>   due to several issues caused by pre-SCF merge rush, we don't yet
> >> have a working ISO for version bumps patches [4]
> >>
> >> Therefore we are still in Merge Freeze, as we need to stabilize master
> >> before moving forward.
> >>
> >> Latest blocker for the merge - inconsistent 9.0 mirrors. Build team
> >> will look into it, and I'll post an update with more information.
> >>
> >> [1] https://ci.fuel-infra.org
> >> [2]
> https://ci.fuel-infra.org/view/ISO/job/8.0-community.all/185/console
> >> [3] https://launchpad.net/fuel/mitaka
> >> [4] https://review.openstack.org/#/q/topic:8.0-scf
> >>
> >> On Wed, Dec 23, 2015 at 10:48 AM, Aleksandra Fedorova
> >>  wrote:
> >> > Hi Fuelers,
> >> >
> >> > SCF has been declared [1] and we start creating stable/8.0 branch in
> >> > all projects.
> >> >
> >> > Please don't merge anything both to master and to stable/8.0 until we
> >> > verify Infra and CI readiness.
> >> >
> >> > List of projects affected:
> >> >
> >> >   fuel-main
> >> >   fuel-agent
> >> >   fuel-astute
> >> >   fuel-library
> >> >   fuel-menu
> >> >   fuel-ostf
> >> >   fuel-qa
> >> >   fuel-upgrade
> >> >   fuel-web
> >> >   shotgun
> >> >   python-fuelclient
> >> >   network-checker
> >> >   fuel-nailgun-agent
> >> >   fuel-mirror
> >> >
> >> > Use #fuel-infra or #fuel-dev IRC channels for questions.
> >> >
> >> > [1]
> >> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082939.html
> >> >
> >> > --
> >> > Aleksandra Fedorova
> >> > Fuel CI Team Lead
> >> > bookwar
> >>
> >>
> >>
> >> --
> >> Aleksandra Fedorova
> >> CI Team Lead
> >> bookwar
> >>
> >>
> ______
> >> OpenStack Development Mailing 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
> >
>
>
>
> --
> Aleksandra Fedorova
> CI Team Lead
> bookwar
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Vitaly Kramskikh]

>> The things I want to notice are:
> >>> >>>>
> >>> >>>> * Currently we aren't tied up to PostgreSQL 9.3.
> >>> >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by
> using a
> >>> >>>> set of JSON operations.
> >>> >>>
> >>> >>> I'm curious and have just a small side question: does that mean
> Fuel
> >>> >>> is
> >>> >>> only going to be able to run with PostgreSQL?
> >>> >>>
> >>> >>> I also see
> >>> >>>
> >>> >>>
> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql,
> >>> >>> maybe it's related?
> >>> >>>
> >>> >>> Thanks!
> >>> >>>
> >>> >>> --
> >>> >>> Julien Danjou
> >>> >>> // Free Software hacker
> >>> >>> // https://julien.danjou.info
> >>> >>
> >>> >>
> >>> >>
> __
> >>> >> OpenStack Development Mailing 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
> >>
> >>
> >>
> >>
> >> --
> >> 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
>
>
>
> --
> Aleksandra Fedorova
> CI Team Lead
> bookwar
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel][Ubuntu bootstrap] WebUI notification

[Vitaly Kramskikh]

Hi,

I really don't like setting the error message as the default one in the DB
schema and consider it as a last resort solution. If possible update the
message to error one just before you start to build the image.

2015-12-15 18:48 GMT+03:00 Artur Svechnikov :

> Hi folks,
> Recently was introduced special notification about absented bootstrap
> image.
>
> Currently this notification is sent from fuel-bootstrap-cli. It means that
> error message will not be sent when failure occurs before first building
> (like in [1]). I think it will be better to set error message on WebUI by
> default through fixtures and then remove it if first build is successful.
>
> Please share your opinions about this issue.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1526351
>
> Best regards,
> Svechnikov Artur
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

[Vitaly Kramskikh]

Igor,

2015-12-15 13:14 GMT+03:00 Igor Kalnitsky :

> Hey Vitaly,
>
> I agree that having a lot of logic (receiving auth token, creating
> payload and doing post request) in RPM post_install section is a huge
> overhead, and definitely it's not a way to go. We have to find better
> solution, and I think it should be done declaratively (via some YAML).
>
> Moreover, I'd like to see the same approach for cluster's dashboard. I
> see no reason why YAML + custom formatting wouldn't be enough.
>

Cluster-level links building logic is more complex in case of absolute url:
the dashboards can be located on a separate IP or VIP in case of multiple
nodes, it may use HTTPS or not and this may depend on the plugins settings
and/or number of nodes, etc. If we could cover all the cases by YAML
description, that would be perfect, but I don't think that's possible.


>
> - Igor
>
> On Tue, Dec 15, 2015 at 11:53 AM, Vitaly Kramskikh
>  wrote:
> > Hi,
> >
> > As you may know, in Fuel 8.0 we've implemented blueprint
> > external-dashboard-links-in-fuel-dashboard. It will allow plugins to add
> > links to their dashboards to the Fuel UI after deployment. As link
> > construction logic could be rather complex (what IP should be used -
> > public_vip or a separate public IP, should HTTPS be used, etc), we
> decided
> > to create a new API handler with auth exepmtion for POST requests
> > (/api/clusters/:id/plugin_links), which should be used from
> post-deployment
> > tasks of plugins. Relative links (without a protocol and a hostname) are
> > treated relative to public_vip (or SSL hostname in case of enabled SSL
> for
> > Horizon). Here are the examples of such post-deployment tasks: for
> absolute
> > url and for relative url. For me this approach was designed during 7.0
> > development cycle and looks fine to me and some other python developers.
> >
> > But by the end of the development cycle the we figured out that we also
> need
> > to cover the case for plugins which install their dashboard on the master
> > node. We decided to go with the same approach and add same API handler
> for
> > plugins (/api/plugins/:id/plugin_links), but without auth exemption. It
> > should be used from post_install.sh script to create links. But the
> logic of
> > the script appeared to be pretty complex:
> >
> > It needs to fork (as post_install is run before the plugin registration
> > process)
> > It needs to extract login/password from /etc/fuel/astute.yaml to access
> API
> > (so in case they are outdated this approach won't work; it won't also be
> > possible to request actual credentials from the user as it's a fork)
> > It needs to obtain a new Keystone token
> > Using this token, it should poll /api/plugins and look for the plugin
> with
> > the needed name until it appears (after registration process)
> > After the plugin is registered, script should construct a url using the
> > found id and send a POST request to add a link.
> >
> > Registering a plugin-level link shouldn't be that complex and we need to
> > think for a better approach. Do you have any ideas?
> >
> > I have one: unlike cluster-level links, plugin-level links don't need
> custom
> > construction logic as they are always relative to the master node IP and
> use
> > the same protocol, so that they can be specified in plugin metadata. We
> also
> > can use metadata describe cluster-level links in 2 most frequent cases:
> > relative to public_vips (Horizon plugins case) and for plugins which
> provide
> > only one role with public_ip_required=true and limits.max=1 (monitoring
> > solutions case). For more complex cases plugins will still use the API to
> > create the links manually.
> >
> >
> > --
> > 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
>



-- 
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-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

[Vitaly Kramskikh]

Hi,

As you may know, in Fuel 8.0 we've implemented blueprint
external-dashboard-links-in-fuel-dashboard
<https://blueprints.launchpad.net/fuel/+spec/external-dashboard-links-in-fuel-dashboard>.
It will allow plugins to add links to their dashboards to the Fuel UI after
deployment. As link construction logic could be rather complex (what IP
should be used - public_vip or a separate public IP, should HTTPS be used,
etc), we decided to create a new API handler with auth exepmtion for POST
requests (/api/clusters/:id/plugin_links), which should be used from
post-deployment tasks of plugins. Relative links (without a protocol and a
hostname) are treated relative to public_vip (or SSL hostname in case of
enabled SSL for Horizon). Here are the examples of such post-deployment
tasks: for absolute url
<https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/absolute-dashboard-link.pp>
and for relative url
<https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/relative-dashboard-link.pp>.
For me this approach was designed during 7.0 development cycle and looks
fine to me and some other python developers.

But by the end of the development cycle the we figured out that we also
need to cover the case for plugins which install their dashboard on the
master node. We decided to go with the same approach and add same API
handler for plugins (/api/plugins/:id/plugin_links), but without auth
exemption. It should be used from post_install.sh script to create links.
But the logic of the script appeared to be pretty complex
<https://review.openstack.org/#/c/251881/12/examples/fuel_plugin_example_v4/post_install.sh>
:

   - It needs to fork (as post_install is run before the plugin
   registration process)
   - It needs to extract login/password from /etc/fuel/astute.yaml to
   access API (so in case they are outdated this approach won't work; it won't
   also be possible to request actual credentials from the user as it's a fork)
   - It needs to obtain a new Keystone token
   - Using this token, it should poll /api/plugins and look for the plugin
   with the needed name until it appears (after registration process)
   - After the plugin is registered, script should construct a url using
   the found id and send a POST request to add a link.

Registering a plugin-level link shouldn't be that complex and we need to
think for a better approach. Do you have any ideas?

I have one: unlike cluster-level links, plugin-level links don't need
custom construction logic as they are always relative to the master node IP
and use the same protocol, so that they can be specified in plugin
metadata. We also can use metadata describe cluster-level links in 2 most
frequent cases: relative to public_vips (Horizon plugins case) and for
plugins which provide only one role with public_ip_required=true and
limits.max=1 (monitoring solutions case). For more complex cases plugins
will still use the API to create the links manually.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vitaly Kramskikh]

onents should use the same input data structure like this
>> [0],
>> >>>> i.e. a flat list of fully independent repositories (see an example
>> below).
>> >>>> First repo in the list is supposed to be a base OS repo (i.e.
>> contains base
>> >>>> packages like libc).
>> >>>>
>> >>>> [
>> >>>>  {
>> >>>> type: deb,
>> >>>> url: some-url,
>> >>>> section: some-section,
>> >>>> suite: some-suite,
>> >>>> priority: some-priority
>> >>>>   },
>> >>>>   {
>> >>>> type: deb,
>> >>>> url: another-url,
>> >>>> section: another-section,
>> >>>> suite: another-suite,
>> >>>> priority: another-priority
>> >>>>   },
>> >>>> ...
>> >>>> ]
>> >>>>
>> >>>> I'd like to focus on the fact that these repositories should be
>> defined
>> >>>> independently (no base url, no base suite, etc.) That makes little
>> sense to
>> >>>> speculate about consistency of a particular repository. We only
>> should talk
>> >>>> about consistency of the whole list of repositories together.
>> >>>>
>> >>>> I'll try to explain. In the real world we usually deal with sets of
>> >>>> repositories which look like this:
>> >>>>
>> >>>> http://archive.ubuntu.com/ubuntu/dists/trusty/
>> >>>> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/
>> >>>> http://archive.ubuntu.com/ubuntu/dists/trusty-security/
>> >>>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/
>> >>>>
>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/
>> >>>>
>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/
>> >>>>
>> >>>> As you can see these repositories have common hosts and base suites
>> and it
>> >>>> instills us to think that repositories should not be defined
>> separately
>> >>>> which is wrong. This special case does not break the whole approach.
>> It is
>> >>>> just a special case. Repositories are nothing more than just sets of
>> >>>> packages that can depend on each other forming a tree when taken
>> together.
>> >>>> Package relation does matter, not repository location, not suite
>> name.
>> >>>> Parsing package tree for a set of repositories we can easily figure
>> out
>> >>>> whether this set is consistent or not (e.g. python-packetary allows
>> to do
>> >>>> this).
>> >>>>
>> >>>> Taking into account the above, I'd say UI should allow a user to
>> define
>> >>>> repositories independently not forcing to use special patterns like
>> suite +
>> >>>> suite-updates + suite-security, not forcing repositories to be
>> located on
>> >>>> the same host. That means we should modify fuel-menu bootstrap
>> section which
>> >>>> currently allows a user to define a base url that is then used to
>> form a
>> >>>> group of repos (base, base-updates, base-security). Besides, it
>> contradicts
>> >>>> to our use case when we put mosX.Y locally on the master node while
>> >>>> mosX.Y-updates and mosX.Y-security are supposed to be available
>> online.
>> >>>>
>> >>>> What do you guys think of that?
>> >>>>
>> >>>>
>> >>>> [0]
>> >>>>
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
>> >>>>
>> >>>>
>> >>>> Vladimir Kozhukalov
>> >>>>
>> >>>>
>> __
>> >>>> OpenStack Development Mailing List (not for usage questions)
>> >>>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Kind Regards,
>> >>> Fedor Zhadaev
>> >>>
>> >>> Skype: zhadaevfm
>> >>> IRC: fzhadaev
>> >>>
>> >>>
>> __
>> >>> OpenStack Development Mailing 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
>> >
>> >
>> >
>> > --
>> > Aleksandra Fedorova
>> > CI Team Lead
>> > bookwar
>> >
>> >
>> __
>> > OpenStack Development Mailing 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

[Vitaly Kramskikh]

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



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

[Vitaly Kramskikh]

Roman,

Sorry for breaking all the stuff again. I've got suggestion to change this
from one of the core reviewers.

Fortunately, separation of Fuel UI is already in progress (Vladimir
Kozhukalov may want to provide extra info here), but it won't guarantee
protection from similar issues in future. What we really need is to run
fuelclient functional tests against every change in nailgun.

2015-11-23 22:56 GMT+07:00 Roman Prykhodchenko :

> Folks.
>
> This happened again. Nailgun’s API was silently changed [1] breaking
> python-fuelclient and everything else that was relying on it.
>
> I feel like this is the point when just discussing the issue is not enough
> so I call for a vote: Let’s separate Nailgun from Fuel UI and put them into
> different repositories now.
>
> Please cast your votes (either +1 or -1) to this thread. You can also
> provide your reasoning and more thoughts.
>
>
> - romcheg
>
>
> 1. https://review.openstack.org/#/c/240234/
>
> 26 жовт. 2015 р. о 11:11 Sebastian Kalinowski 
> написав(ла):
>
> 2015-10-23 11:36 GMT+02:00 Igor Kalnitsky :
>
>> Roman, Vitaly,
>>
>> You're both saying right things, and you guys bring a sore topic up again.
>>
>> The thing is that Nailgun's API isn't the best one.. but we're trying
>> to improve it step-by-step, from release to release. We have so many
>> things to reconsider and to fix that it'd require a huge effort to
>> make backward compatible changes and support it. So we decided ignore
>> backward compatibility for clients for awhile and consider our API as
>> unstable.
>>
>> I agree with Roman that such changes must not be made secretly, and we
>> should at least announce about them. Moreover, every core must think
>> about consequences before approving them.
>>
>> So I propose to do the following things when backward incompatible
>> change to API is required:
>>
>> * Announce this change in openstack-dev ML.
>> * Wait 1 week before approving it, so anyone can prepare.
>> * Change author has to work with QA in order make sure they are
>> prepared for this change.
>>
>> Any thoughts?
>>
>
>
> +1.
>
> Although there is one thing that you didn't mention (but probably everyone
> know about it)
> is to solve the issue with fuelclient not beign tested against changes in
> nailgun.
> We need not only run it for every change in nailgun (or for only those
> that touch files under "api"
> dir) but also cover more endpoints with fuelclient tests against real API,
> not mocks, to discover
> such issues earlier.
>
>
>>
>> Thanks,
>> Igor
>>
>> On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh
>>  wrote:
>> > JFYI: (re-)start of this discussion was instigated by merge of this
>> change
>> > (and here is revert).
>> >
>> > And this is actually not the first time when we make backward
>> incompatible
>> > changes in our API. AFAIR, the last time it was also about the network
>> > configuration handler. We decided not to consider our API frozen, make
>> the
>> > changes and break backward compatibility. So now is the time to
>> reconsider
>> > this.
>> >
>> > API backward compatibility is a must for good software, but we also
>> need to
>> > understand that introducing API versioning is not that easy and will
>> > increase efforts needed to make new changes in nailgun.
>> >
>> > I'd go this way:
>> >
>> > Estimate the priority of introducing API versioning - maybe we have
>> other
>> > things we should invest our resources to
>> > Estimate all the disadvantages this decision might have
>> > Fix all the issues in the current API (like this one)
>> > Implement API versioning support (yes, we don't have this mechanism
>> yet, so
>> > we can't just "bump API version" like Sergii suggested in another
>> thread)
>> > Consider the current API as frozen v1, so backward incompatible changes
>> (or
>> > maybe all the changes?) should go to v2
>> >
>> >
>> > 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko :
>> >>
>> >> Hi folks,
>> >>
>> >> I’d like to touch the aspect of Fuel development process that seems to
>> be
>> >> as wrong as possible. That aspect is how we change the API.
>> >>
>> >> The issue is that in Fuel anyone can change API at any point of time
>> >> without even warning the rest of the same component’s team. R

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

[Vitaly Kramskikh]

Evgeniy,

That's also a good point. Due to all these issues and need to significantly
change Nailgun for this feature we decided to move it out of 8.0 and come
back to it in the next release so that we can design and implement
everything properly.

2015-11-23 16:49 GMT+07:00 Evgeniy L :

> Hi,
>
> I have several comments, just to make sure, that we are on the same page
> here.
> Current API calls for provisioning/deployment are used by developers and
> fuel hackers,
> and by design there was removed all validation. So shouldn't there be some
> more
> user friendly API calls which have validation? For example we don't run
> any pre
> deployment checks and network validation, you can even ask to deploy
> offline nodes.
> As result novice user can easily break her/his cluster.
>
> Thanks,
>
> On Fri, Nov 13, 2015 at 11:46 AM, Julia Aranovich  > wrote:
>
>> 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
>>
>>
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

[Vitaly Kramskikh]

+1 for "refuel" to trigger Fuel CI only, awesome idea. "recheck" will
trigger both.

2015-11-20 21:12 GMT+07:00 Sergey Vasilenko :

>
> On Fri, Nov 20, 2015 at 4:00 PM, Alexey Shtokolov  > wrote:
>
>> Probably we should use another keyword for Fuel CI to prevent an extra
>> load on the infrastructure? For example "refuel" or smth like this?
>
>
> IMHO we should have ability to restart each one of two deployment tests.
> Often happens, that one test passed, but another fails while ENV setting
> up. Restart both tests for this case does not required.
>
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/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-dev] [Fuel][UI] Fuel UI switched to a new build/module system

[Vitaly Kramskikh]

Hi,

I'd like to inform you that Fuel UI migrated from require.js to webpack. It
will give us lots of benefits like significant improvement of developer
experience and will allow us to easily separate Fuel UI from Nailgun. For
more information please read the spec
<https://github.com/openstack/fuel-specs/blob/master/specs/8.0/webpack.rst>.

For those who use Nailgun in fake mode, it means that they need to take
some extra actions to make Fuel UI work - since we don't have anymore an
uncomressed UI version which compiles itself in the browser (and this
allowed us to resolve huge amount of tech debt - we have to support only
one environment). You need to run npm install to fetch new modules and
proceed with one of 2 possible ways:

   - If you don't plan to modify Fuel UI, it would be better just to
   compile Fuel UI by running gulp build - after that compiled UI will be
   served by Nailgun as usual. Don't forget to rerun npm install && gulp
   build after fetching new changes.
   - If you plan to modify Fuel UI, there is another option - use a
   development server. It watches for changes and files and automatically
   recompiles Fuel UI (using incremental compilation, which is usually much
   faster than gulp build) and triggers refresh in browser. You can run it
   via gulp dev-server.

If you have issues with the new code, feel free to contact us in #fuel-ui
or #fuel-dev channels.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Vitaly Kramskikh]

Hi,

I think having both compatibility and incompatibility lists is a good idea.
I think we need just to show a warning if users pick options which are not
in compatibility list and disable options which are in incompatibility
list. We also need to be able to provide a message in case of
incompatibility: the current implementation of the wizard supports custom
messages in the wizard config and they are quite useful.

2015-11-02 16:16 GMT+07:00 Evgeniy L :

> Hi,
>
> The main reason why I think we should get all of the three states is we
> don't know exactly if those plugins (which developer didn't specify) are
> compatible or not, so we should not make any assumptions and prevent
> the user from enabling any plugins she/he wants. The best we can do here
> is to provide all of the information plugin developer knows, directly to
> the user,
> without us in the middle who make decisions based on incomplete data.
>
> So lets ask plugin developer to specify a set of components which he tested
> his plugin with. Plus a list of components which he tested with and he is
> sure
> that those are not going to working together.
>
> On UI we can show explicitly, that this combination is tested and approved
> to
> be working, another combination is not working for sure (plugin developers
> tested
> it and explicitly specified), and there will be a lot of combination which
> are going
> to work together without problems, but we should say the user, that the
> developer
> didn't test it and he should test and use it carefully.
>
> Thanks,
>
> On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
> wrote:
>
>> 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
>>
>
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Vitaly Kramskikh]

a-docs>
> (area-docs tag)
>
> Partners bugs: all
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-partners>
> /open
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-partners>
> (area-partners tag)
> MOS bugs in Fuel project: all
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-mos>
> /open
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-mos>
> (area-mos tag)
> MOS linux bugs in Fuel project: all
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-linux>
> /open
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-linux>
> (area-linux tag)
> Plugins bugs in Fuel project: all
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-plugins>
> /open
> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-plugins>
> (area-plugins tag)
>
> Feel free to remove bugs from one area and add to another. Please don't
> assign one bug to several areas and please don't leave a bug without any
> areas.
>

Why not? It's easily possible that a fix for a bug requires changes both in
UI and nailgun, or in nailgun and library.


>
> Here some assumptions that I used:
> - shell scripts like virtualbox scripts and fuel-migrate I've marked with
> area-library tag. Sorry, library guys.
> - bugs about movement repo ci jobs to OpenStack infra I've marked with
> area related to that repo.
> - bugs about fuel-web repo decomposition I've marked with area-build tag.
>
> I'll be able to share much more interesting reports for every area and
> highlight important stuff as soon as we start using these tags on daily
> basis. I hope you'll support my initiative.
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

[Vitaly Kramskikh]

JFYI: (re-)start of this discussion was instigated by merge of this change
<https://review.openstack.org/#/c/232021/> (and here is revert
<https://review.openstack.org/#/c/238030/>).

And this is actually not the first time when we make backward incompatible
changes in our API. AFAIR, the last time it was also about the network
configuration handler. We decided not to consider our API frozen, make the
changes and break backward compatibility. So now is the time to reconsider
this.

API backward compatibility is a must for good software, but we also need to
understand that introducing API versioning is not that easy and will
increase efforts needed to make new changes in nailgun.

I'd go this way:

   - Estimate the priority of introducing API versioning - maybe we have
   other things we should invest our resources to
   - Estimate all the disadvantages this decision might have
   - Fix all the issues in the current API (like this one
   <https://bugs.launchpad.net/fuel/+bug/1496630>)
   - Implement API versioning support (yes, we don't have this mechanism
   yet, so we can't just "bump API version" like Sergii suggested in another
   thread)
   - Consider the current API as frozen v1, so backward incompatible
   changes (or maybe all the changes?) should go to v2


2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko :

> Hi folks,
>
> I’d like to touch the aspect of Fuel development process that seems to be
> as wrong as possible. That aspect is how we change the API.
>
> The issue is that in Fuel anyone can change API at any point of time
> without even warning the rest of the same component’s team. Relying on this
> kind of API is basically impossible. We constantly have problems when even
> components of Fuel stop working due to unexpected changes in the API.
> Thinking about another software that must be integrated with Fuel is hardly
> possible with the current approach.
>
> As for a grown-up project there is a strong need for Fuel in general and
> for Nailgun in particular to work on a policy for making changes to their
> APIs. Living in OpenStack ecosystem we must at least take a look how it’s
> done in its components and try to do something similar. After working with
> Nova, Keystone, Ironic and other components I would propose to start with
> the following: let’s not make any changes to the API. Instead, let’s create
> a new version of Nailgun’s API that will appear in Fuel 8.0 and make all
> the changes there. That is the thing that will instantaneously make lives
> of other components much easier, if we make it now.
>
> After doing the essential part let’s think about how we are going to live
> with that in the future. There are several APIs in Fuel, the rest of the
> email is only touching Nailgun’s REST API. I can see the things somehow
> like the following:
>
>  - Introduce API documentation by embedding Swagger and Swagger UI.
>The current approach when we leave API docs for documentation team is
> not effective. Swagger generates the documentation and resolves this issue.
>  - After releasing a version of Fuel, it’s API is called stable and frozen
> for any changes, unless they allign API to the documentation or
> documentation to the API.
>  - All changes to a stable APIs must be backported to the stable version
> of Fuel that introduced the corresponding API.
>  - In order to guarantee that a stable API is not changed, Jenkins jobs
> should make automatic checks for every new patch set
>
> Details about all the above mentioned proposals can be discussed in
> separate threads so this one will stay uncluttered. I'd like to also summon
> those OpenStack folks, who tried to resolve the same issue and ask them
> about any common solutions in the ecosystem.
>
>
> - 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Vitaly Kramskikh]

Sergii,

Let's move this discussion to the thread "[Fuel] Changing APIs and API
versioning". We need to have this mechanism regardless of our decision on
API versioning.

2015-10-21 20:31 GMT+07:00 Sergii Golovatiuk :

> Vitaliy,
>
> Why do merge API changes without:
>
> 1. Fixing documentation?
> 2. bumping API version?
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Oct 21, 2015 at 3:08 PM, Vitaly Kramskikh  > wrote:
>
>> Hi,
>>
>> It's yet another time we broke fuelclient by merging a change
>> <https://review.openstack.org/#/c/232021/> in fuel-web repo. Since we
>> are considering moving Fuel UI to a separate repo, and we need to run UI
>> functional tests against changes in nailgun anyway, I think we should start
>> to change our CI so it could run tests from another repo against changes in
>> another repo.
>>
>> Can it be done?
>>
>> --
>> 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
>
>


-- 
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-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Vitaly Kramskikh]

Hi,

It's yet another time we broke fuelclient by merging a change
<https://review.openstack.org/#/c/232021/> in fuel-web repo. Since we are
considering moving Fuel UI to a separate repo, and we need to run UI
functional tests against changes in nailgun anyway, I think we should start
to change our CI so it could run tests from another repo against changes in
another repo.

Can it be done?

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

[Vitaly Kramskikh]

+1, that would allow to install plugins from Fuel UI

2015-10-09 15:53 GMT+07:00 Sergii Golovatiuk :

> +1 to Roman.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko 
> 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  написав(ла):
>>
>> 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 
>> 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://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
>
>


-- 
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-dev] [Fuel][UI] Bower is gone

[Vitaly Kramskikh]

Hi folks,

We used Bower to manage client-side dependencies of Fuel UI, but since
today they are managed by NPM which is already used to manage server-side
dependencies. This change reduces complexity of Fuel UI and is also a
preparation for some important changes.

For those who use fake mode for development, this change means that you
don't need to run "gulp bower" anymore after pulling latest changes, just
"npm install" is enough.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL for master node API

[Vitaly Kramskikh]

FYI: There is Strict-Transport-Security
<https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security> header which
can also be useful here (unless we want to make SSL for master node
optional)

2015-08-04 15:07 GMT+03:00 Vladimir Sharshov :

> Hi,
>
> +1 to 2nd solution too.
>
> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> +1 to 2nd solution, in this case old environments will work without
>> additional
>> actions. Agents for new environments, CLI and UI will use SSL.
>> But probably for UI we will have to perform redirect on JS level.
>>
>> Thanks,
>>
>> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Hi guys,
>>> in overall movement of Fuel to use secure sockets we think about
>>> wrapping master node UI and API calls to SSL. But there are next caveat:
>>>
>>> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
>>> little. But if it will be rewritten in 7.0 and HTTPS on master node will be
>>> forced by default, it will break upgrade from previous releases to 7.0 due
>>> fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
>>> default and fuel-nailgun-agent on all environments won't upgraded, so it
>>> won't be able to connect to master node after upgrade. It breaks seamless
>>> upgrade procedure.
>>>
>>> What options I see there:
>>> 1. We can forcedly enable SSL for master node and rewrite clients in 7.0
>>> to be able to work over it. In release notes for 7.0 we will write
>>> forewarning that clients which want to upgrade master node from previous
>>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
>>> all deployed environments.
>>>
>>> 2. We can have both SSL and non-SSL versions enabled by default and
>>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
>>> availability and be able to work in plain HTTP for legacy mode. So, for all
>>> new environments SSL will be used by default and for old ones plain HTTP
>>> will continue to work too. Master node upgrade will not be broken in this
>>> case.
>>>
>>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
>>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
>>> releases. It is just postponed version of first clause, so it doesn't seems
>>> valid for me, actually.
>>>
>>> I would be really glad to hear what you think about this. Thank you in
>>> advance.
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)

[Vitaly Kramskikh]

+1 to Stanislav's proposal.

2015-07-27 3:05 GMT+03:00 Stanislav Makar :

> Hello
> I went through LP-1464656 and I see that it covers two things:
> 1. Bad pg num calculation algorithm.
> 2. Add the possibility to set pg num via GUI.
>
> First is the most important and a BUG by itself, second is nice to have
> feature and no more.
> Hence we should split it into a bug and a feature.
>
> As the main part is a bug it does not impact FF at all.
>
> My +1 to close bad pg num calculation algorithm as a bug and postpone
> specifying pg_num via GUI to the next release.
>
> /All the best
> Stanislav Makar
> +1 for FFE
> Given how borken pg_num calculations are now, this is essential to the
> ceph story and there is no point in testing ceph at scale with out it.
>
> The only work-around for not having this is to delete all of the pools by
> hand after deployment and calculate the values by hand, and re-create the
> pools by hand. The story from that alone makes it high on the UX scale,
> which means we might as well fix it as a bug.
>
> The scope of impact is limited to only ceph, the testing plan needs more
> detail, and we are still comming to turns with some of the data format to
> process between nailgun calculating and puppet consuming.
>
> We would need about 1.2 week to get these landed.
>
> On Fri, Jul 24, 2015 at 3:51 AM Konstantin Danilov 
> wrote:
>
>> Team,
>>
>> I would like to request an exception from the Feature Freeze for [1]
>> fix. It requires changes in
>> fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already
>> tested, I'm fixing UT now.
>> BP - [4]
>>
>> Code has backward-compatibility mode. I need one more week to finish it.
>> Also
>> I'm asking someone to be an assigned code-reviewer for this ticket to
>> speed-up
>> review process.
>>
>> Thanks
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1464656
>> [2] https://review.openstack.org/#/c/204814
>> [3] https://review.openstack.org/#/c/204811
>> [4] https://review.openstack.org/#/c/203062
>>
>> --
>> Kostiantyn Danilov aka koder.ua
>> Principal software engineer, Mirantis
>>
>> skype:koder.ua
>> http://koder-ua.blogspot.com/
>> http://mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] version.yaml in the context of packages

[Vitaly Kramskikh]

Vladimir,

2015-07-24 20:21 GMT+03:00 Vladimir Kozhukalov :

> Dear colleagues,
>
> Although we are focused on fixing bugs during next few weeks I still have
> to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this
> file when all-inclusive ISO image was the only way of delivering Fuel. We
> had to have somewhere the information about SHA commits for all Fuel
> related git repos. But everything is changing and we are close to flexible
> package based delivery approach. And this file is becoming kinda fifth
> wheel.
>
> Here is how version.yaml looks like
>
> VERSION:
>   feature_groups:
> - mirantis
>   production: "docker"
>   release: "7.0"
>   openstack_version: "2015.1.0-7.0"
>   api: "1.0"
>   build_number: "82"
>   build_id: "2015-07-23_10-59-34"
>   nailgun_sha: "d1087923e45b0e6d946ce48cb05a71733e1ac113"
>   python-fuelclient_sha: "471948c26a8c45c091c5593e54e6727405136eca"
>   fuel-agent_sha: "bc25d3b728e823e6154bac0442f6b88747ac48e1"
>   astute_sha: "b1f37a988e097175cbbd14338286017b46b584c3"
>   fuel-library_sha: "58d94955479aee4b09c2b658d90f57083e668ce4"
>   fuel-ostf_sha: "94a483c8aba639be3b96616c1396ef290dcc00cd"
>   fuelmain_sha: "68871248453b432ecca0cca5a43ef0aad6079c39"
>
>
> Let's go through this file.
>
> 1) *feature_groups* - This is, in fact, runtime parameter rather then
> build one, so we'd better store it in astute.yaml or other runtime config
> file.
>
This parameter must be available in nailgun - there is code in nailgun and
UI which relies on this parameter.

> 2) *production* - It is always equal to "docker" which means we deploy
> docker containers on the master node. Formally it comes from one of
> fuel-main variables, which is set into "docker" by default, but not a
> single job in CI customizes this variable. Looks like it makes no sense to
> have this.
>
This parameter can be set to other values when used for fake UI and
functional tests for UI and fuelclient.

> 3) *release *- It is the number of Fuel release. Frankly, don't need this
> because it is nothing more than the version of fuel meta package [1].
>
It is shown on UI.

> 4) *openstack_version *- It is just an extraction from openstack.yaml [2].
> 5) *api *- It is 1.0 currently. And we still don't have other versions of
> API. Frankly, it contradicts to the common practice to make several
> different versions available at the same time. And a user should be able to
> ask API which versions are currently available.
> 6) *build_number *and *build_id *- These are the only parameters that
> relate to the build process. But let's think if we actually need these
> parameters if we switch to package based approach. RPM/DEB repositories are
> going to become the main way of delivering Fuel, not ISO. So, it also makes
> little sense to put store them, especially if we upgrade some of the
> packages.
> 7) *X_sha* - This does not even require any explanation. It should be rpm
> -qa instead.
>

> I am raising this topic, because it is kind of blocker for switching to
> package based upgrades. Our current upgrade script assumes we have this
> file version.yaml in the tarball and we put this new file instead of old
> one during upgrade. But this file could not be packaged into rpm because it
> can only be built together with ISO.
>
>
> [1]
> https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec
> [2]
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing 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 Vladimir Kozhukalov to core reviewers of fuel-main

[Vitaly Kramskikh]

+1

2015-07-24 1:56 GMT+03:00 Sergey Vasilenko :

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


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel][plugin] Plugin depends on another plugin

[Vitaly Kramskikh]

Daniel,

Yes, it doesn't work in 6.1 release. My question is: are you OK if we
support your case in 7.0 using the approach I described?

2015-07-21 14:13 GMT+03:00 Daniel Depaoli :

>
>
> On Tue, Jul 21, 2015 at 12:02 PM, Vitaly Kramskikh <
> vkramsk...@mirantis.com> wrote:
>
>> Hi, currently it's not possible to handle cases like this. The expression
>> parser by default expects every key in the expression to exist, otherwise
>> it throws an error. But it also supports non-strict mode, in which
>> non-existent keys are treated as null value. We can add support for
>> enabling this mode in 7.0, so it will look like this:
>>
>> restrictions:
>> - condition: "settings:fuel-plugin-node-js == null or
>> settings:fuel-plugin-node-js.metadata.enabled == false"
>>   strict: false
>>   action: "disable"
>>   message: "Node JS must be present and enabled"
>>
>> Will this work for you?
>>
>
> No this solution unfortunately doesn't work if the nodejs plugin is not
> present. But thanks anyway!
>
>>
>> 2015-07-21 11:30 GMT+03:00 Daniel Depaoli 
>> :
>>
>>> Hi all! I'm writing a fuel plugin that depends on another plugin, in
>>> particular one plugin install node-js and the other plugin install a
>>> software that uses nodejs.
>>> What i did is to add a condition in environment_config.yaml:
>>> ```
>>> *restrictions:*
>>> *- condition: "settings:fuel-plugin-node-js.metadata.enabled ==
>>> false"*
>>> *action: "disable"*
>>> *message: "Node JS must be present and enabled"*
>>> *```*
>>> This work if fuel-plugin-node-js is present, but doesn't work otherwise.
>>> So I tried with:
>>> ```
>>> *- condition: "settings:fuel-plugin-node-js
>>> and settings:fuel-plugin-node-js.metadata.enabled == false"*
>>> *```*
>>> but with the same result: it works only if the first plugin is present.
>>>
>>> Can you help me?
>>>
>>> --
>>> 
>>> Daniel Depaoli
>>> CREATE-NET Research Center
>>> Smart Infrastructures Area
>>> Junior Research Engineer
>>> 
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> 
> Daniel Depaoli
> CREATE-NET Research Center
> Smart Infrastructures Area
> Junior Research Engineer
> 
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [fuel][plugin] Plugin depends on another plugin

[Vitaly Kramskikh]

Hi, currently it's not possible to handle cases like this. The expression
parser by default expects every key in the expression to exist, otherwise
it throws an error. But it also supports non-strict mode, in which
non-existent keys are treated as null value. We can add support for
enabling this mode in 7.0, so it will look like this:

restrictions:
- condition: "settings:fuel-plugin-node-js == null or
settings:fuel-plugin-node-js.metadata.enabled == false"
  strict: false
  action: "disable"
  message: "Node JS must be present and enabled"

Will this work for you?

2015-07-21 11:30 GMT+03:00 Daniel Depaoli :

> Hi all! I'm writing a fuel plugin that depends on another plugin, in
> particular one plugin install node-js and the other plugin install a
> software that uses nodejs.
> What i did is to add a condition in environment_config.yaml:
> ```
> *restrictions:*
> *- condition: "settings:fuel-plugin-node-js.metadata.enabled ==
> false"*
> *action: "disable"*
> *message: "Node JS must be present and enabled"*
> *```*
> This work if fuel-plugin-node-js is present, but doesn't work otherwise.
> So I tried with:
> ```
> *- condition: "settings:fuel-plugin-node-js
> and settings:fuel-plugin-node-js.metadata.enabled == false"*
> *```*
> but with the same result: it works only if the first plugin is present.
>
> Can you help me?
>
> --
> 
> Daniel Depaoli
> CREATE-NET Research Center
> Smart Infrastructures Area
> Junior Research Engineer
> 
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Packaged Fuel and "Feature Groups"

[Vitaly Kramskikh]

Hi,

Yes, it is possible to change the value of feature_groups after master node
installation. Currently it affects only availability of a few options in
Fuel UI.

2015-06-18 17:11 GMT+03:00 Aleksandra Fedorova :

> Hi, everyone,
>
> could you please clarify a bit about how FEATURE_GROUPS [1] parameter
> is handled in Fuel.
>
> Currently we have it specified at ISO build stage, while from the
> description of it it looks like it is just a UI switch which doesn't
> change anything deep inside the code.
>
> Can it be changed at master node deployment stage, after master node
> deployment?
>
> Can we use exactly the same nailgun package to install all the
> different "flavors" just by changing configuration parameter after
> package installation?
>
> [1]
> https://ci.fuel-infra.org/job/merged-fuel-specs/Fuel_Development_Specs_build_results/specs/5.1/feature-groups.html#feature-groups
>
> --
> Aleksandra Fedorova
> Fuel Devops Engineer
> bookwar
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI

[Vitaly Kramskikh]

Samuel,

There are plans to solve this:

1) Add a flag/field to control declaration so it can have multiple values:

  ntp_list:
*multiple_values: true*
value:
  - "1.1.1.1"
  - "2.2.2.2"
label: "NTP server list"
description: "List of upstream NTP servers"
type: "text"

Now we use one input with comma-separated values to enter DNS and NTP
servers which is hacky. This proposal with also solve your issue, but won't
help for Simon's case (as there are groups of 2 fields).

2) For complex controls we plan to implement support for JS parts of plugins
<https://blueprints.launchpad.net/fuel/+spec/ui-plugins>, so you can
implement configuration UI of any complexity by providing custom JS.
repo_setup control in 6.1 is a great example of a complex control.

For 6.1 I suggest you to use current DNS/NTP approach (comma separated
values) or Simon's approach (though I'd use action: hide instead of action:
disable)


2015-05-07 17:36 GMT+03:00 Simon Pasquier :

> Hello Samuel,
> As far as I know, this isn't possible unfortunately. For our own needs, we
> ended up adding a fixed-size list with all items but the first one
> disabled. When you enter something in the first input box, it enabled the
> second box and so on (see [1]). In any case, this would be a good
> addition...
> BR,
> Simon
> [1]
> https://github.com/stackforge/fuel-plugin-elasticsearch-kibana/blob/master/environment_config.yaml#L21
>
> On Thu, May 7, 2015 at 3:37 PM, Samuel Bartel  > wrote:
>
>> Hi all,
>>
>>
>>
>> I am working on two plugins for fuel : logrotate and cinder-netapp (to
>> add multibackend feature)
>>
>> In this two plugins I face the same problem. Is it possible in the
>> environment yaml config describing the fields to display for the plugin in
>> the UI to have some dynamic element.
>>
>> I explain my need. I would like to be able to add additional element by
>> clicking on a “+” button as the IP range for network tab in order to be
>> able to:
>>
>> -add new log file to manage for the logrorate instead of having a static
>> list
>>
>> -add extra netapp filer/volume instead ofbeing able to setup only one for
>> the cinder netapp in a multibackend scope.
>>
>> For the cinder netapp for example, I would be able to access to the
>> netapp server hostname with:
>>
>> $::fuel_settings[‘cinder_netapp’][0][‘netapp_server_hostname’]  #for the
>> first one
>>
>> $::fuel_settings[‘cinder_netapp’][1][‘netapp_server_hostname’]  #for the
>> second  one
>>
>> And so on.
>>
>>
>>
>> Can we do that with the actual plugin feature.  If not is it planned to
>> add such a feature?
>>
>>
>>
>> Regards,
>>
>>
>> Samuel
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

[Vitaly Kramskikh]

So, there is no objections and Julia is now a core reviewer for fuel-web.
Congratulations!

2015-05-05 16:17 GMT+03:00 Vitaly Kramskikh :

> Thanks for voting. If nobody has objections by tomorrow, Julia will get +2
> rights for fuel-web.
>
> 2015-05-05 15:30 GMT+03:00 Dmitry Pyzhov :
>
>> +1
>>
>> On Tue, May 5, 2015 at 1:06 PM, Evgeniy L  wrote:
>>
>>> +1
>>>
>>> On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski <
>>> skalinow...@mirantis.com> wrote:
>>>
>>>> +1
>>>>
>>>> 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski 
>>>> :
>>>>
>>>>> +1, indeed Julia's reviews are very thorough.
>>>>>
>>>>> P.
>>>>>
>>>>> On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I'd like to nominate Julia Aranovich
>>>>> > <http://stackalytics.com/report/users/jkirnosova> for fuel-web
>>>>> > <https://github.com/stackforge/fuel-web> core team. Julia's reviews
>>>>> are
>>>>> > always thorough and have decent quality. She is one of the top
>>>>> > contributors and reviewers in fuel-web repo (mostly for JS/UI stuff).
>>>>> >
>>>>> > Please vote by replying with +1/-1.
>>>>> >
>>>>> > --
>>>>> > 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
>>>>>
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

[Vitaly Kramskikh]

Thanks for voting. If nobody has objections by tomorrow, Julia will get +2
rights for fuel-web.

2015-05-05 15:30 GMT+03:00 Dmitry Pyzhov :

> +1
>
> On Tue, May 5, 2015 at 1:06 PM, Evgeniy L  wrote:
>
>> +1
>>
>> On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski <
>> skalinow...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski :
>>>
>>>> +1, indeed Julia's reviews are very thorough.
>>>>
>>>> P.
>>>>
>>>> On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
>>>> > Hi,
>>>> >
>>>> > I'd like to nominate Julia Aranovich
>>>> > <http://stackalytics.com/report/users/jkirnosova> for fuel-web
>>>> > <https://github.com/stackforge/fuel-web> core team. Julia's reviews
>>>> are
>>>> > always thorough and have decent quality. She is one of the top
>>>> > contributors and reviewers in fuel-web repo (mostly for JS/UI stuff).
>>>> >
>>>> > Please vote by replying with +1/-1.
>>>> >
>>>> > --
>>>> > 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
>>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
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-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

[Vitaly Kramskikh]

Hi,

I'd like to nominate Julia Aranovich
<http://stackalytics.com/report/users/jkirnosova> for fuel-web
<https://github.com/stackforge/fuel-web> core team. Julia's reviews are
always thorough and have decent quality. She is one of the top contributors
and reviewers in fuel-web repo (mostly for JS/UI stuff).

Please vote by replying with +1/-1.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [UI] New design + Bootstrap 3

[Vitaly Kramskikh]

There is no reason, just a markup demo.
Added a sample deployment failure message to the nodes page.
As for settings or networks page, they should look pretty much the same and
most likely we won't create a markup demo for these pages as they are
mostly built from standard controls.

2015-03-23 21:03 GMT+03:00 Andrew Woodward :

> Looks good, a couple of things:
>
> Is there a reason that the nodes near to top didn't render in the role
> group?
> Can you render a message like deployment failure, or deployment success?
> Can you render the networks or settings page?
>
> On Mon, Mar 23, 2015 at 10:36 AM, Vitaly Kramskikh
>  wrote:
> > Hi,
> >
> > We're working on migrating Fuel UI from Bootstrap 2 to Bootstrap 3 and
> > changing the design. It's mostly upgrade of styles and markup, but we
> also
> > plan to implement some changes which are frequently requested (like
> making
> > action buttons always available on top of the page). Here is markup for 3
> > pages:
> >
> > Environment list
> > Nodes tab
> > Actions tab
> >
> > What do you think about the new design? Your feedback is welcome.
> >
> > --
> > 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
> >
>
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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-dev] [Fuel] [UI] New design + Bootstrap 3

[Vitaly Kramskikh]

Hi,

We're working on migrating Fuel UI from Bootstrap 2 to Bootstrap 3 and
changing the design. It's mostly upgrade of styles and markup, but we also
plan to implement some changes which are frequently requested (like making
action buttons always available on top of the page). Here is markup for 3
pages:

   - Environment list <http://94.127.68.84/files/fuel/>
   - Nodes tab <http://94.127.68.84/files/fuel/nodes.html>
   - Actions tab <http://94.127.68.84/files/fuel/actions.html>

What do you think about the new design? Your feedback is welcome.
-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Network verification status flag

[Vitaly Kramskikh]

Hi Przemek,

Thanks for detailed description of the issues you faced.

+1 for this approach, let's keep pure-UI implementation for 6.1 - it will
work for 99% of the cases.


2015-02-26 21:35 GMT+07:00 Przemyslaw Kaminski :

> Hello,
>
> Recently I've been asked to implement Python side of a simple feature:
> before deployment tell the UI user that network verification for current
> cluster configuration has not been performed. Moreover, on the UI side
> it's possible to do network checking on usaved cluster data -- in that
> case treat is as no network checking was performed. Unfortunately it
> turned out to be not at all that simple to implement on the backend and
> I'll try to explain why.
>
> I ended up with the implementation [1] that added a tri-valued flag to
> the Cluster model. What's surprising I got stuck at the idempotency test
> of network configuration: I've sent a GET request on network config,
> then sent a PUT with the received data and asserted that nothing
> changed. What's strange in about 1/4 cases this test failed because some
> ips got assigned differently. I wasn't able to explain why (I had other
> tasks to do and this one was somewhat of a side-project). BTW, it turned
> out that we have at least 2 functions that are used to deeply compare 2
> objects, both unnecessary IMHO as there are 3rd party libs for this,
> like [3].
>
> Another issue was that network configuration PUT returns a task while
> actually there is no asynchronicity there at all, it's just a huge
> validator that executes everything synchronously. This was already
> heavily commented in [2] and it's proposed to remove that task
> completely. Moreover Nova and Neutron backends returned different
> statuses albeit their verification code was almost the same. A
> unification of these 2 handlers was proposed in [1].
>
> Another issue is that we have to somehow invalidate the flag that says
> cluster verification is done. It is not difficult to overwrite the save
> method for Cluster so that any change in cluster invalidates network
> checking. But it's not that simple. First of all -- not all cluster's
> changes should invalidate the network checking. Second -- not only
> cluster changes invalidate that -- adding nodes to cluster, for example,
> invalidates network checking too. Adding triggers all over the code that
> check this don't seem to be a good solution.
>
> So what I proposed is to instead of having a simple flag like in [1] to
> actually store the whole JSON object with serialized network
> configuration. The UI, upon deployment, will ask the API about cluster
> and there we will return an additional key called 'network_status_check'
> that is 'failed', 'passed' or 'not_performed'. The API will determine
> that flag by getting that saved JSON object and comparing it with a
> freshly serialized object. This way we don't need to alter the flag upon
> save or anything, we just compute if it was changed on demand.
>
> I guess this change grew out so big that it requires a blueprint and can
> be done for 7.0. The feature can be implemented on the UI side only that
> covers most (but not all of) the problems and is "good enough" for 6.1.
>
> [1] https://review.openstack.org/153556
> [2]
>
> https://review.openstack.org/#/c/137642/15/nailgun/nailgun/api/v1/handlers/network_configuration.py
> [3] https://github.com/inveniosoftware/dictdiffer
>
> P.
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] [UI] Sorting and filtering of node list

[Vitaly Kramskikh]

I think all these operations for nodes (grouping, sorting, filtering) can
be done on the backend, but we can do it completely on the UI side and
shouldn't wait for backend implementation. We can switch to it after it
becomes available.

2015-02-17 19:44 GMT+07:00 Sergey Vasilenko :

> +1, sorting is should be...
>
> Paginating may be too, but not activated by default.
>
>
> /sv
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/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

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Vitaly Kramskikh]

 other tasks
> > that do verification. When all is OK verify_networks calls RPC's
> > 'verify_networks_resp' method and returns a 'ready' status and at
> > that point I can inject code to also set the DB column in cluster
> > saying that network verification was OK for the saved
> > configuration. Adding other tasks should in no way affect this
> > behavior since they're just subtasks of this task -- or am I
> > wrong?
> >
> >
> > It is not that smooth, but in general yes - it can be done when
> > state of verify_networks is changed. But lets say we have
> > some_settings_verify task? Would be it valid to add one more field
> > on cluster model, like some_settings_status?
>
> Well, why not? Cluster deployment is a task and it's status is saved
> in cluster colum and not fetched from tasks. As you see the logic of
> network task verification is not simply based on ready/error status
> reading but more subtle. What other settings you have in mind? I guess
> when we have more of them one can create a separate table to keep
> them, but for now I don't see a point in doing this.
>
> P.
>
> >
> >
> >
> >
> >
> >
> __
> >
> >
> OpenStack Development Mailing 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
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

[Vitaly Kramskikh]

+1 for removing "changes" attribute. It's useless now. If there are no
plans to add something else there, let's remove it.

2015-01-26 11:39 GMT+03:00 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Vitaly Kramskikh]

Evgeniy,

Yes, we shouldn't delete tasks, but for now it is the only way to mark
verification results as obsolete and remove them. When we implement this
new field, we can easily get rid of task deletion in favour of setting this
field.

2015-01-16 15:58 GMT+03:00 Evgeniy L :

> Hi,
>
> 1) +1 for warning
>
> 2) I don't think that we should delete tasks, it's a history which can be
> useful,
> for example for stats feature, also it's useful for debugging, but each
> task
> should have created_at and updated_at fields, and from api you will be able
> to get the latest tasks for specific env.
>
> Thanks,
>
> On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh  > wrote:
>
>> Folks,
>>
>> I want to discuss possibility to add network verification status field
>> for environments. There are 2 reasons for this:
>>
>> 1) One of the most frequent reasons of deployment failure is wrong
>> network configuration. In the current UI network verification is completely
>> optional and sometimes users are even unaware that this feature exists. We
>> can warn the user before the start of deployment if network check failed of
>> wasn't performed.
>>
>> 2) Currently network verification status is partially tracked by status
>> of the last network verification task. Sometimes its results become stale,
>> and the UI removes the task. There are a few cases when the UI does this,
>> like changing network settings, adding a new node, etc (you can grep
>> "removeFinishedNetworkTasks" to see all the cases). This definitely should
>> be done on backend.
>>
>> What is your opinion on this?
>>
>> --
>> 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
>>
>>
>
> ______
> OpenStack Development Mailing 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-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes

[Vitaly Kramskikh]

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:

   1. 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.
   2. 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):
  1. Form-based filter (beside a single input for name there will be
  controls for other parameters)
  2. Query language-based filter (like one used in Gerrit)
  3. 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

[openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Vitaly Kramskikh]

Folks,

I want to discuss possibility to add network verification status field for
environments. There are 2 reasons for this:

1) One of the most frequent reasons of deployment failure is wrong network
configuration. In the current UI network verification is completely
optional and sometimes users are even unaware that this feature exists. We
can warn the user before the start of deployment if network check failed of
wasn't performed.

2) Currently network verification status is partially tracked by status of
the last network verification task. Sometimes its results become stale, and
the UI removes the task. There are a few cases when the UI does this, like
changing network settings, adding a new node, etc (you can grep
"removeFinishedNetworkTasks" to see all the cases). This definitely should
be done on backend.

What is your opinion on this?

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

Re: [openstack-dev] [Fuel] Support of warnings in Fuel UI

[Vitaly Kramskikh]

I also want to add that there is also a short form
<http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#restrictions>
for this:

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

There are also a few restrictions in existing openstack.yaml like this:

  volumes_lvm:
label: "Cinder LVM over iSCSI for volumes"
restrictions:
  - "settings:storage.volumes_ceph.value == true or
settings:common.libvirt_type.value == 'vcenter'"

The restriction above is actually 2 restrictions for 2 unrelated things and
it should be separated like this:

restrictions:
  - "settings:storage.volumes_ceph.value == true": "This stuff
cannot be used with Ceph"
  - "settings:common.libvirt_type.value == 'vcenter'": "This
stuff cannot be used with vCenter"

So please add these messages for your features to improve Fuel UX.

2014-12-18 10:56 GMT+01:00 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
>
>

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

As I said, it is not flexible and restrictive. What if there are some other
"backends" for anything appear? What to do if I want to write a plugin that
just adds some extra styles to the UI? Invent a new structures/flags on
demand? That's not viable.

I still think "enableness" of plugin is the root of all issues with your
approach. With your approach we lose single source of truth (cluster
attributes/settings tab) we'll need to search for strange solutions like
these groups/flags.

2014-12-17 12:33 GMT+01:00 Evgeniy L :
>
> Vitaly, what do you think about that?
>
> On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L  wrote:
>>
>> Hi,
>>
>> I don't agree with many of your statements but, I would like to
>> continue discussion about really important topic i.e. UI flow, my
>> suggestion was to add groups, for plugin in metadata.yaml plugin
>> developer can have description of the groups which it belongs to:
>>
>> groups:
>>   - id: storage
>> subgroup:
>>   - id: cinder
>>
>> With this information we can show a new option on UI (wizard),
>> if option is selected, it means that plugin is enabled, if plugin belongs
>> to several groups, we can use OR statement.
>>
>> The main point is, for environment creation we must specify
>> ids of plugins. Yet another reason for that is plugins multiversioning,
>> we must know exactly which plugin with which version
>> is used for environment, and I don't see how "conditions" can help
>> us with it.
>>
>> Thanks,
>>
>>>
>>>>
>>>>
>> On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>>
>>>
>>>
>>> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>>>
>>>>
>>>>
>>>> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
>>>> vkramsk...@mirantis.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> First let me describe what our plans for the nearest release. We want
>>>>>> to deliver
>>>>>> role as a simple plugin, it means that plugin developer can define
>>>>>> his own role
>>>>>> with yaml and also it should work fine with our current approach when
>>>>>> user can
>>>>>> define several fields on the settings tab.
>>>>>>
>>>>>> Also I would like to mention another thing which we should probably
>>>>>> discuss
>>>>>> in separate thread, how plugins should be implemented. We have two
>>>>>> types
>>>>>> of plugins, simple and complicated, the definition of simple - I can
>>>>>> do everything
>>>>>> I need with yaml, the definition of complicated - probably I have to
>>>>>> write some
>>>>>> python code. It doesn't mean that this python code should do
>>>>>> absolutely
>>>>>> everything it wants, but it means we should implement stable,
>>>>>> documented
>>>>>> interface where plugin is connected to the core.
>>>>>>
>>>>>> Now lets talk about UI flow, our current problem is how to get the
>>>>>> information
>>>>>> if plugins is used in the environment or not, this information is
>>>>>> required for
>>>>>> backend which generates appropriate tasks for task executor, also this
>>>>>> information can be used in the future if we decide to implement
>>>>>> plugins deletion
>>>>>> mechanism.
>>>>>>
>>>>>> I didn't come up with a some new solution, as before we have two
>>>>>> options to
>>>>>> solve the problem:
>>>>>>
>>>>>> # 1
>>>>>>
>>>>>> Use conditional language which is currently used on UI, it will look
>>>>>> like
>>>>>> Vitaly described in the example [1].
>>>>>> Plugin developer should:
>>>>>>
>>>>>> 1. describe at least one element for UI, which he will be able to use
>>>>>> in task
>>>>>>
>>>>>> 2. add condition which is written in our own programming language
>>>>>>
>>>

Re: [openstack-dev] [Fuel] Building Fuel plugins with UI part

[Vitaly Kramskikh]

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

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

2014-12-10 19:31 GMT+03:00 Evgeniy L :

>
>
> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh  > wrote:
>
>>
>>
>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>
>>> Hi,
>>>
>>> First let me describe what our plans for the nearest release. We want to
>>> deliver
>>> role as a simple plugin, it means that plugin developer can define his
>>> own role
>>> with yaml and also it should work fine with our current approach when
>>> user can
>>> define several fields on the settings tab.
>>>
>>> Also I would like to mention another thing which we should probably
>>> discuss
>>> in separate thread, how plugins should be implemented. We have two types
>>> of plugins, simple and complicated, the definition of simple - I can do
>>> everything
>>> I need with yaml, the definition of complicated - probably I have to
>>> write some
>>> python code. It doesn't mean that this python code should do absolutely
>>> everything it wants, but it means we should implement stable, documented
>>> interface where plugin is connected to the core.
>>>
>>> Now lets talk about UI flow, our current problem is how to get the
>>> information
>>> if plugins is used in the environment or not, this information is
>>> required for
>>> backend which generates appropriate tasks for task executor, also this
>>> information can be used in the future if we decide to implement plugins
>>> deletion
>>> mechanism.
>>>
>>> I didn't come up with a some new solution, as before we have two options
>>> to
>>> solve the problem:
>>>
>>> # 1
>>>
>>> Use conditional language which is currently used on UI, it will look like
>>> Vitaly described in the example [1].
>>> Plugin developer should:
>>>
>>> 1. describe at least one element for UI, which he will be able to use in
>>> task
>>>
>>> 2. add condition which is written in our own programming language
>>>
>>> Example of the condition for LBaaS plugin:
>>>
>>> condition: settings:lbaas.metadata.enabled == true
>>>
>>> 3. add condition to metadata.yaml a condition which defines if plugin is
>>> enabled
>>>
>>> is_enabled: settings:lbaas.metadata.enabled == true
>>>
>>> This approach has good flexibility, but also it has problems:
>>>
>>> a. It's complicated and not intuitive for plugin developer.
>>>
>> It is less complicated than python code
>>
>
> I'm not sure why are you talking about python code here, my point
> is we should not force developer to use this conditions in any language.
>
> But that's how current plugin-like stuff works. There are various tasks
which are run only if some checkboxes are set, so stuff like Ceph and
vCenter will need conditions to describe tasks.

> Anyway I don't agree with the statement there are more people who know
> python than "fuel ui conditional language".
>
>
>> b. It doesn't cover case when the user installs 3rd party plugin
>>> which doesn't have any conditions (because of # a) and
>>> user doesn't have a way to disable it for environment if it
>>> breaks his configuration.
>>>
>> If plugin doesn't have conditions for tasks, then it has invalid metadata.
>>
>
> Yep, and it's a problem of the platform, which provides a bad interface.
>
Why is it bad? It plugin writer doesn't provide plugin name or version,
then metadata is invalid also. It is plugin writer's fault that he didn't
write metadata properly.

>
>
>>
>>> # 2
>>>
>>> As we discussed from the very beginning after user selects a release he
>>> can
>>> choose a set of plugins which he wants to be enabled for environment.
>>> After that we can say that plugin is enabled for the environment and we
>>> send
>>> tasks related to this plugin to task executor.
>>>
>>> >> My approach also allows to eliminate "enableness" of plugins which
>>> will cause UX issues and issues like you described above. vCenter and Ceph
>>> also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
>>> provides backends for Cinder and Glance which can be used simultaneously or
>>> only one of them can be used.
>>>
>>> Both of described plugins have enabled/disabled state, vCenter is enabled
>

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

or inexperienced user. Just imagine: a new user which barely knows
   about OpenStack chooses a name for the environment, OS release and then he
   needs to choose plugins. Really?

My proposal for "complex" plugin interface: there should be python classes
with exactly the same fields from yaml files: plugin name, version, etc.
But condition for cluster deletion and for tasks which are written in DSL
in case of "simple" yaml config should become methods which plugin writer
can make as complex as he wants.

>
> [1]
> https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf
>
> On Sun, Nov 30, 2014 at 3:12 PM, Vitaly Kramskikh  > wrote:
>
>>
>>
>> 2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak :
>>
>>>
>>>>- environment_config.yaml should contain exact config which will be
>>>>mixed into cluster_attributes. No need to implicitly generate any 
>>>> controls
>>>>like it is done now.
>>>>
>>>>  Initially i had the same thoughts and wanted to use it the way it is,
>>> but now i completely agree with Evgeniy that additional DSL will cause a lot
>>> of problems with compatibility between versions and developer experience.
>>>
>> As far as I understand, you want to introduce another approach to
>> describe UI part or plugins?
>>
>>> We need to search for alternatives..
>>> 1. for UI i would prefer separate tab for plugins, where user will be
>>> able to enable/disable plugin explicitly.
>>>
>> Of course, we need a separate page for plugin management.
>>
>>> Currently settings tab is overloaded.
>>> 2. on backend we need to validate plugins against certain env before
>>> enabling it,
>>>and for simple case we may expose some basic entities like
>>> network_mode.
>>> For case where you need complex logic - python code is far more flexible
>>> that new DSL.
>>>
>>>>
>>>>- metadata.yaml should also contain "is_removable" field. This
>>>>field is needed to determine whether it is possible to remove installed
>>>>plugin. It is impossible to remove plugins in the current 
>>>> implementation.
>>>>This field should contain an expression written in our DSL which we 
>>>> already
>>>>use in a few places. The LBaaS plugin also uses it to hide the checkbox 
>>>> if
>>>>Neutron is not used, so even simple plugins like this need to utilize 
>>>> it.
>>>>This field can also be autogenerated, for more complex plugins plugin
>>>>writer needs to fix it manually. For example, for Ceph it could look 
>>>> like
>>>>"settings:storage.volumes_ceph.value == false and
>>>>settings:storage.images_ceph.value == false".
>>>>
>>>> How checkbox will help? There is several cases of plugin removal..
>>>
>> It is not a checkbox, this is condition that determines whether the
>> plugin is removable. It allows plugin developer specify when plguin can be
>> safely removed from Fuel if there are some environments which were created
>> after the plugin had been installed.
>>
>>> 1. Plugin is installed, but not enabled for any env - just remove the
>>> plugin
>>> 2. Plugin is installed, enabled and cluster deployed - forget about it
>>> for now..
>>> 3. Plugin is installed and only enabled - we need to maintain state of
>>> db consistent after plugin is removed, it is problematic, but possible
>>>
>> My approach also allows to eliminate "enableness" of plugins which will
>> cause UX issues and issues like you described above. vCenter and Ceph also
>> don't have "enabled" state. vCenter has hypervisor and storage, Ceph
>> provides backends for Cinder and Glance which can be used simultaneously or
>> only one of them can be used.
>>
>>> My main point that plugin is enabled/disabled explicitly by user, after
>>> that we can decide ourselves can it be removed or not.
>>>
>>>>
>>>>- For every task in tasks.yaml there should be added new
>>>>"condition" field with an expression which determines whether the task
>>>>should be run. In the current implementation tasks are always run for
>>>>specified roles. For example, vCenter plugin can have a few tasks with
>>>>conditions like "settings:common.libvirt_type.value =

Re: [openstack-dev] [Fuel][Nailgun]Problems with auto-reloading

[Vitaly Kramskikh]

I don't even remember if/when autoreloading worked correctly. +1 for
disabling this feature.

2014-12-02 16:23 GMT+03:00 Roman Prykhodchenko 
:

> Hi folks,
>
> today we encountered a problem caused by auto-reload feature and our
> code-organisation.
> The problem is that web.py tries reloading modules at some point and while
> it does that it expects that modules could be reloaded in any order without
> raising any errors.
>
> Unfortunately for Nailgun that condition is not satisfied in at least one
> place. That place is SQLAlchemy models which are placed in different
> modules. If web.py tries to reload any model’s module, say
> notifications.py, before reloading base module, Notifications will try
> registering itself in the old Base’s MetaData which already contain info
> about the appropriate table and that causes errors like "Table
> 'notifications' is already defined for this MetaData instance. Specify
> 'extend_existing=True' to redefine options and columns on an existing Table
> object.” That problem happens on every request that touches database.
>
> There are several possible solutions for this problem:
>
> - Disable autoreload even in Debug mode, because tests always run in that
> mode and that’s the cause these failures occure
>   - Someone might need that so a command line option or config parameter
> for autoreload
> - Re-organise code to guarantee correct reloading order
> - Enable extention of existing tables in metadata, but I’m not sure what
> will be other consequences for that.
>
>
> - romcheg
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Dmitry,

2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko :

> Vitaly,
>
> It's there a document or spec or a wiki page that describes the current
> status of this discussion in the context of the whole pluggable
> architecture design?
>
There is a spec for the current implementation
<https://github.com/stackforge/fuel-specs/blob/master/specs/6.0/cinder-neutron-plugins-in-fuel.rst>.
Here I'm trying to propose changes which allow to turn more complex things
like Ceph and vCenter into plugins. That's it.

> Jumping into this thread without having the whole picture is hard. Knowing
> what is already agreed, what is implemented so far, and having a structured
> summary of points of disagreement with pro and contra arguments would help
> a lot.
>
Well, there is a problem with "pro and contra arguments" because currently
the discussion looks like "Your proposal is wrong and complicated and
stuff, but I still don't have my own proposal". So I think it could be a
better idea to wait for proposal from Evgeniy and then we'll be able to
make a list of pro and contra arguments.


> On Nov 28, 2014 9:48 AM, "Vitaly Kramskikh" 
> wrote:
>
>> Folks,
>>
>> Please participate in this discussion. We already have a few meetings on
>> this topic and there is still no decision. I understand entry level is
>> pretty high, but please find some time for this.
>>
>> Evgeniy,
>>
>> Responses inline:
>>
>> 2014-11-28 20:03 GMT+03:00 Evgeniy L :
>>
>>> >> Yes, but is already used in a few places. I want to notice once
>>> again - even a simple LBaaS plugin with a single checkbox needed to utilize
>>> this functionality.
>>>
>>> Yes, but you don't need to specify it in each task.
>>>
>> Just by adding conditions to tasks we will be able to pluginize all
>> current functionality that can be pluginized. On the other hand, 1 line
>> will be added to task definition and you are concerned about this that much
>> that you want to create a separate interface for "complex" plugins. Am I
>> right?
>>
>>>
>>> >> So, you're still calling this interface complicated. Ok, I'm looking
>>> forward to seeing your proposal about dealing with complex plugins.
>>>
>>> All my concerns were related to simple plugins and that we should
>>> find a way not to force a plugin developer to do this copy-paste work.
>>>
>> I don't understand what copy-paste work you are talking about. Copying
>> conditions from tasks to is_removable? Yes, it will be so in most cases,
>> but not always, so we need to give a plugin writer a way to define
>> is_removable manually. If you are talking about copypasting conditions
>> between tasks (though I don't understand why we need a few tasks with the
>> same conditions), YAML links can be used - we use them a lot in
>> openstack.yaml.
>>
>>>
>>> >> If you have several checkboxes, then it is a complex plugin with
>>> complex configuration ...
>>>
>>> Here we need a definition of s simple plugins, in the current
>>> release with simple plugins you can define some fields on the UI (not a
>>> single checkbox) and run several tasks if plugin is enabled.
>>>
>> Ok, we can define simple plugin as a plugin which doesn't require
>> modification of generated YAML files at all. But with proposed approach
>> there is no need to somehow separate "simple" and "complex" plugins.
>>
>>>
>>> Thanks,
>>>
>>>>
>>> On Fri, Nov 28, 2014 at 7:01 PM, Vitaly Kramskikh <
>>> vkramsk...@mirantis.com> wrote:
>>>
>>>> Evgeniy,
>>>>
>>>> Responses inline:
>>>>
>>>> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>>>>
>>>>> Hi Vitaly,
>>>>>
>>>>> I agree with you that conditions can be useful in case of complicated
>>>>> plugins, but
>>>>> at the same time in case of simple cases it adds a huge amount of
>>>>> complexity.
>>>>> I would like to avoid forcing user to know about any conditions if he
>>>>> wants
>>>>> to add several text fields on the UI.
>>>>>
>>>>> I have several reasons why we shouldn't do that:
>>>>> 1. conditions are described with yet another language with it's own
>>>>> syntax
>>>>>
>>>> Yes, but is already used in a few places. I want to not

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak :

>
>>- environment_config.yaml should contain exact config which will be
>>mixed into cluster_attributes. No need to implicitly generate any controls
>>like it is done now.
>>
>>  Initially i had the same thoughts and wanted to use it the way it is,
> but now i completely agree with Evgeniy that additional DSL will cause a lot
> of problems with compatibility between versions and developer experience.
>
As far as I understand, you want to introduce another approach to describe
UI part or plugins?

> We need to search for alternatives..
> 1. for UI i would prefer separate tab for plugins, where user will be able
> to enable/disable plugin explicitly.
>
Of course, we need a separate page for plugin management.

> Currently settings tab is overloaded.
> 2. on backend we need to validate plugins against certain env before
> enabling it,
>and for simple case we may expose some basic entities like network_mode.
> For case where you need complex logic - python code is far more flexible
> that new DSL.
>
>>
>>- metadata.yaml should also contain "is_removable" field. This field
>>is needed to determine whether it is possible to remove installed plugin.
>>It is impossible to remove plugins in the current implementation.
>>This field should contain an expression written in our DSL which we 
>> already
>>use in a few places. The LBaaS plugin also uses it to hide the checkbox if
>>Neutron is not used, so even simple plugins like this need to utilize it.
>>This field can also be autogenerated, for more complex plugins plugin
>>writer needs to fix it manually. For example, for Ceph it could look like
>>"settings:storage.volumes_ceph.value == false and
>>settings:storage.images_ceph.value == false".
>>
>> How checkbox will help? There is several cases of plugin removal..
>
It is not a checkbox, this is condition that determines whether the plugin
is removable. It allows plugin developer specify when plguin can be safely
removed from Fuel if there are some environments which were created after
the plugin had been installed.

> 1. Plugin is installed, but not enabled for any env - just remove the
> plugin
> 2. Plugin is installed, enabled and cluster deployed - forget about it for
> now..
> 3. Plugin is installed and only enabled - we need to maintain state of db
> consistent after plugin is removed, it is problematic, but possible
>
My approach also allows to eliminate "enableness" of plugins which will
cause UX issues and issues like you described above. vCenter and Ceph also
don't have "enabled" state. vCenter has hypervisor and storage, Ceph
provides backends for Cinder and Glance which can be used simultaneously or
only one of them can be used.

> My main point that plugin is enabled/disabled explicitly by user, after
> that we can decide ourselves can it be removed or not.
>
>>
>>- For every task in tasks.yaml there should be added new "condition"
>>field with an expression which determines whether the task should be run.
>>In the current implementation tasks are always run for specified roles. 
>> For
>>example, vCenter plugin can have a few tasks with conditions like
>>"settings:common.libvirt_type.value == 'vcenter'" or
>>"settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar
>>approach will be used in implementation of Granular Deployment feature.
>>
>> I had some thoughts about using DSL, it seemed to me especially helpfull
> when you need to disable part of embedded into core functionality,
> like deploying with another hypervisor, or network dirver (contrail for
> example). And DSL wont cover all cases here, this quite similar to
> metadata.yaml, simple cases can be covered by some variables in tasks (like
> group, unique, etc), but complex is easier to test and describe in python.
>
Could you please provide example of such conditions? vCenter and Ceph can
be turned into plugins using this approach.

Also, I'm not against python version of plugins. It could look like a
python class with exactly the same fields form YAML files, but conditions
will be written in python.

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


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Folks,

Please participate in this discussion. We already have a few meetings on
this topic and there is still no decision. I understand entry level is
pretty high, but please find some time for this.

Evgeniy,

Responses inline:

2014-11-28 20:03 GMT+03:00 Evgeniy L :

> >> Yes, but is already used in a few places. I want to notice once again
> - even a simple LBaaS plugin with a single checkbox needed to utilize this
> functionality.
>
> Yes, but you don't need to specify it in each task.
>
Just by adding conditions to tasks we will be able to pluginize all current
functionality that can be pluginized. On the other hand, 1 line will be
added to task definition and you are concerned about this that much that
you want to create a separate interface for "complex" plugins. Am I right?

>
> >> So, you're still calling this interface complicated. Ok, I'm looking
> forward to seeing your proposal about dealing with complex plugins.
>
> All my concerns were related to simple plugins and that we should
> find a way not to force a plugin developer to do this copy-paste work.
>
I don't understand what copy-paste work you are talking about. Copying
conditions from tasks to is_removable? Yes, it will be so in most cases,
but not always, so we need to give a plugin writer a way to define
is_removable manually. If you are talking about copypasting conditions
between tasks (though I don't understand why we need a few tasks with the
same conditions), YAML links can be used - we use them a lot in
openstack.yaml.

>
> >> If you have several checkboxes, then it is a complex plugin with
> complex configuration ...
>
> Here we need a definition of s simple plugins, in the current
> release with simple plugins you can define some fields on the UI (not a
> single checkbox) and run several tasks if plugin is enabled.
>
Ok, we can define simple plugin as a plugin which doesn't require
modification of generated YAML files at all. But with proposed approach
there is no need to somehow separate "simple" and "complex" plugins.

>
> Thanks,
>
>>
> On Fri, Nov 28, 2014 at 7:01 PM, Vitaly Kramskikh  > wrote:
>
>> Evgeniy,
>>
>> Responses inline:
>>
>> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>>
>>> Hi Vitaly,
>>>
>>> I agree with you that conditions can be useful in case of complicated
>>> plugins, but
>>> at the same time in case of simple cases it adds a huge amount of
>>> complexity.
>>> I would like to avoid forcing user to know about any conditions if he
>>> wants
>>> to add several text fields on the UI.
>>>
>>> I have several reasons why we shouldn't do that:
>>> 1. conditions are described with yet another language with it's own
>>> syntax
>>>
>> Yes, but is already used in a few places. I want to notice once again -
>> even a simple LBaaS plugin with a single checkbox needed to utilize this
>> functionality.
>>
>>> 2. the language is not documented (solvable)
>>>
>> It is documented:
>> http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax
>>
>>> 3. complicated interface will lead to a lot of bugs for the end user,
>>> and it will be
>>> a Fuel team's problem
>>>
>> So, you're still calling this interface complicated. Ok, I'm looking
>> forward to seeing your proposal about dealing with complex plugins.
>>
>>> 4. in case of several checkboxes you'll have to write a huge conditions
>>> with
>>> a lot of "and" statements and it'll be really easy to forget about
>>> some of them
>>>
>> If you have several checkboxes, then it is a complex plugin with complex
>> configuration, so I see no problem here. There will be many more places
>> where you can "forget" stuff.
>>
>>>
>>> As result in simple cases plugin developer will have to specify the same
>>> condition of every task in tasks.yaml file, add it to metadata.yaml.
>>> If you add new checkbox, you should go through all of this files,
>>> add "and lbaas:new_checkbox_name" statement.
>>>
>> Once again, in simple cases checkbox and the conditions (one for task and
>> one for is_removable) can be easily pregenerated by FPB, so plugin
>> developer has to do nothing more. If you add a new checkbox which doesn't
>> affect plugin removeability and tasks, you have to change nothing in plugin
>> metadata.
>>
>>>
>>> Thanks,
>>>
>>> O

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Evgeniy,

Responses inline:

2014-11-28 18:31 GMT+03:00 Evgeniy L :

> Hi Vitaly,
>
> I agree with you that conditions can be useful in case of complicated
> plugins, but
> at the same time in case of simple cases it adds a huge amount of
> complexity.
> I would like to avoid forcing user to know about any conditions if he wants
> to add several text fields on the UI.
>
> I have several reasons why we shouldn't do that:
> 1. conditions are described with yet another language with it's own syntax
>
Yes, but is already used in a few places. I want to notice once again -
even a simple LBaaS plugin with a single checkbox needed to utilize this
functionality.

> 2. the language is not documented (solvable)
>
It is documented:
http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax

> 3. complicated interface will lead to a lot of bugs for the end user, and
> it will be
> a Fuel team's problem
>
So, you're still calling this interface complicated. Ok, I'm looking
forward to seeing your proposal about dealing with complex plugins.

> 4. in case of several checkboxes you'll have to write a huge conditions
> with
> a lot of "and" statements and it'll be really easy to forget about
> some of them
>
If you have several checkboxes, then it is a complex plugin with complex
configuration, so I see no problem here. There will be many more places
where you can "forget" stuff.

>
> As result in simple cases plugin developer will have to specify the same
> condition of every task in tasks.yaml file, add it to metadata.yaml.
> If you add new checkbox, you should go through all of this files,
> add "and lbaas:new_checkbox_name" statement.
>
Once again, in simple cases checkbox and the conditions (one for task and
one for is_removable) can be easily pregenerated by FPB, so plugin
developer has to do nothing more. If you add a new checkbox which doesn't
affect plugin removeability and tasks, you have to change nothing in plugin
metadata.

>
> Thanks,
>
> On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh  > wrote:
>
>> Folks,
>>
>> In the 6.0 release we'll support simple plugins for Fuel. The current
>> architecture allows to create only very simple plugins and doesn't allow to
>> "pluginize" complex features like Ceph, vCenter, etc. I'd like to propose
>> some changes to make it possible. They are subtle enough and the plugin
>> template still can be autogenerated by Fuel Plugin Builder. Here they are:
>>
>>
>> https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf
>>
>>1. environment_config.yaml should contain exact config which will be
>>mixed into cluster_attributes. No need to implicitly generate any controls
>>like it is done now.
>>2. metadata.yaml should also contain "is_removable" field. This field
>>is needed to determine whether it is possible to remove installed plugin.
>>It is impossible to remove plugins in the current implementation.
>>This field should contain an expression written in our DSL which we 
>> already
>>use in a few places. The LBaaS plugin also uses it to hide the checkbox if
>>Neutron is not used, so even simple plugins like this need to utilize it.
>>This field can also be autogenerated, for more complex plugins plugin
>>writer needs to fix it manually. For example, for Ceph it could look like
>>"settings:storage.volumes_ceph.value == false and
>>settings:storage.images_ceph.value == false".
>>3. For every task in tasks.yaml there should be added new "condition"
>>field with an expression which determines whether the task should be run.
>>In the current implementation tasks are always run for specified roles. 
>> For
>>example, vCenter plugin can have a few tasks with conditions like
>>"settings:common.libvirt_type.value == 'vcenter'" or
>>"settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar
>>approach will be used in implementation of Granular Deployment feature.
>>
>> These simple changes will allow to write much more complex plugins. What
>> do you think?
>> --
>> Vitaly Kramskikh,
>> Software Engineer,
>> Mirantis, Inc.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Folks,

In the 6.0 release we'll support simple plugins for Fuel. The current
architecture allows to create only very simple plugins and doesn't allow to
"pluginize" complex features like Ceph, vCenter, etc. I'd like to propose
some changes to make it possible. They are subtle enough and the plugin
template still can be autogenerated by Fuel Plugin Builder. Here they are:

https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf

   1. environment_config.yaml should contain exact config which will be
   mixed into cluster_attributes. No need to implicitly generate any controls
   like it is done now.
   2. metadata.yaml should also contain "is_removable" field. This field is
   needed to determine whether it is possible to remove installed plugin. It
   is impossible to remove plugins in the current implementation. This
   field should contain an expression written in our DSL which we already use
   in a few places. The LBaaS plugin also uses it to hide the checkbox if
   Neutron is not used, so even simple plugins like this need to utilize it.
   This field can also be autogenerated, for more complex plugins plugin
   writer needs to fix it manually. For example, for Ceph it could look like
   "settings:storage.volumes_ceph.value == false and
   settings:storage.images_ceph.value == false".
   3. For every task in tasks.yaml there should be added new "condition"
   field with an expression which determines whether the task should be run.
   In the current implementation tasks are always run for specified roles. For
   example, vCenter plugin can have a few tasks with conditions like
   "settings:common.libvirt_type.value == 'vcenter'" or
   "settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar
   approach will be used in implementation of Granular Deployment feature.

These simple changes will allow to write much more complex plugins. What do
you think?
-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Separate code freeze for repos

[Vitaly Kramskikh]

There is a proposal to consider a repo as stable if there are no
high/critical bugs and there were no such new bugs with this priority for
the last 3 days. I'm ok with it.

2014-11-14 17:16 GMT+03:00 Igor Kalnitsky :

> Guys,
>
> The idea of separate unfreezing is cool itself, but we have to define
> some rules how to define that fuel-web is stable. I mean, in fuel-web
> we have different projects, so when Fuel UI is stable, the
> fuel_upgrade or Nailgun may be not.
>
> - Igor
>
> On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
>  wrote:
> > Evgeniy,
> >
> > That means that the stable branch can be created for some repos earlier.
> For
> > example, fuel-web repo seems not to have critical issues for now and I'd
> > like master branch of that repo to be opened for merging various stuff
> which
> > shouldn't go to 6.0 and do not wait until all other repos stabilize.
> >
> > 2014-11-14 16:42 GMT+03:00 Evgeniy L :
> >>
> >> Hi,
> >>
> >> >> There was an idea to make a separate code freeze for repos
> >>
> >> Could you please clarify what do you mean?
> >>
> >> I think we should have a way to merge patches for the next
> >> release event if it's code freeze for the current.
> >>
> >> Thanks,
> >>
> >> On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
> >>  wrote:
> >>>
> >>> Folks,
> >>>
> >>> There was an idea to make a separate code freeze for repos, but we
> >>> decided not to do it. Do we plan to try it this time? It is really
> painful
> >>> to maintain multi-level tree of dependent review requests and wait for
> a few
> >>> weeks until we can merge new stuff in master.
> >>>
> >>> --
> >>> Vitaly Kramskikh,
> >>> Software Engineer,
> >>> Mirantis, Inc.
> >>>
> >>> _______
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Vitaly Kramskikh,
> > Software Engineer,
> > Mirantis, Inc.
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Separate code freeze for repos

[Vitaly Kramskikh]

Evgeniy,

That means that the stable branch can be created for some repos earlier.
For example, fuel-web repo seems not to have critical issues for now and
I'd like master branch of that repo to be opened for merging various stuff
which shouldn't go to 6.0 and do not wait until all other repos stabilize.

2014-11-14 16:42 GMT+03:00 Evgeniy L :

> Hi,
>
> >> There was an idea to make a separate code freeze for repos
>
> Could you please clarify what do you mean?
>
> I think we should have a way to merge patches for the next
> release event if it's code freeze for the current.
>
> Thanks,
>
> On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh  > wrote:
>
>> Folks,
>>
>> There was an idea to make a separate code freeze for repos, but we
>> decided not to do it. Do we plan to try it this time? It is really painful
>> to maintain multi-level tree of dependent review requests and wait for a
>> few weeks until we can merge new stuff in master.
>>
>> --
>> Vitaly Kramskikh,
>> Software Engineer,
>> Mirantis, Inc.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Separate code freeze for repos

[Vitaly Kramskikh]

Folks,

There was an idea to make a separate code freeze for repos, but we decided
not to do it. Do we plan to try it this time? It is really painful to
maintain multi-level tree of dependent review requests and wait for a few
weeks until we can merge new stuff in master.

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] fuel-library merge policy and Fuel CI

[Vitaly Kramskikh]

Aleksandra,

As you may know, there is a randomly failing nailgun unit test in fuel-web
repo, which fails for the major part of review requests. It's been
happening for a few days. But I need to merge some stuff and cannot wait
for the fix of this well known issue. So for every request with -1 from
Fuel CI I write an explanation why I decided to merge the request. Are you
ok with this? Here is an example: https://review.openstack.org/#/c/131079/

2014-10-28 23:10 GMT+07:00 Aleksandra Fedorova :

> Hi everyone,
>
> with recent disruption in our CI process I'd like to discuss again the
> issues in our merge workflow.
>
> See the summary at the end.
>
>
> As a starting point, here is the list of patches which were merged
> into fuel-library repository without "Verified +1" label from Fuel CI:
>
>
> https://review.openstack.org/#/q/project:stackforge/fuel-library+AND+status:merged+AND+NOT+label:Verified%252B1%252Cuser%253Dfuel-ci,n,z
>
> And the list of merged patches with explicit "Verified -1" label:
>
>
> https://review.openstack.org/#/q/project:stackforge/fuel-library+AND+status:merged+AND+label:Verified-1%252Cuser%253Dfuel-ci,n,z
>
> There are two common reasons I know why these patchsets exist:
>
> Case 1: "Who cares about CI anyway".
>
> Case 2: These patches can not pass CI because of some real reason,
> which makes Fuel CI result irrelevant.
>
> I am not sure, if i need to comment on the first one, but please just
> remember: CI is not a devops playground made to disrupt your otherwise
> clean and smooth development process. It is an extremely critical
> service, providing the clear reference point for all the work we do.
> And we all know how important the reference point is [1].
>
> So let's move on to the Case 2 and talk about our CI limitations and
> what could possibly make the test result irrelevant.
>
> 1) Dependencies.
>
> Let's say you have a chain of dependent patchsets and none of them
> could pass the CI on its own. How do you merge it?
>
> Here is the trick: the "leaf", i.e. last, topmost patch in the chain
> should pass the CI.
>
> The test we run for this patchset automatically pulls all dependencies
> involved. Which makes Fuel CI result for this patchset perfectly
> relevant for the whole chain.
>
> 2) Environment.
>
> Fuel CI test environment usually uses slightly outdated version of
> Fuel iso image and fuel-main code. Therefore it happens that you write
> and test your patch against latest code via custom iso builds and it
> works, but it can not pass CI. Does it make test results irrelevant?
> No. It makes them even more valuable.
>
> CI environment can be broken and can be outdated. This is the part of
> the process. To deal with these situations we first need to fix the
> environment, then run tests, and then merge the code.
>
> And it helps if you contact devops team in advance  and inform us that
> you soon will need the ISO with this particular features.
>
> 3) ?
>
> Please add your examples and let's deal with them one by one.
>
>
> Summary:
>
> I'd like to propose the following merge policy:
>
> 1. any individual patchset MUST have +1 from Fuel CI;
>
> 2. any chain of dependent patchsets MUST have +1 from Fuel CI for the
> topmost patch;
>
> 3. for all exceptional cases the person who does the merge MUST
> explicitly contact devops team, and make sure that there will be
> devops engineer available who will run additional checks before or
> right after the merge. The very same person who does the merge also
> MUST be available for some time after the merge to help the devops
> engineer to deal with the test failures if they appear.
>
>
>
> [1]
> http://www.youtube.com/watch?feature=player_embedded&v=QkCQ_-Id8zI#t=211
>
>
> --
> Aleksandra Fedorova
> Fuel Devops Engineer
> bookwar
>
> --
> You received this message because you are subscribed to the Google Groups
> "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fuel-core-team+unsubscr...@mirantis.com.
> For more options, visit https://groups.google.com/a/mirantis.com/d/optout.
>



-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Pluggable framework in Fuel: first prototype ready

[Vitaly Kramskikh]

r node): fuel --install-plugin 
>>>3. How are we planning to distribute fuel plugin builder and its
>>>updates? Ideally, it should be available externally (outside of master
>>>node). I don't want us to repeat the same mistake as we did with Fuel
>>>client, which doesn't seem to be usable as an external dependency.
>>>4. How do we handle errors?
>>>   - What happens if an error occurs during plugin installation?
>>>   - What happens if an error occurs during plugin execution? Does
>>>   it (should it?) fail the deployment? Will we show user an error 
>>> message
>>>   with the name of plugin that failed?
>>>   5. Shall we consider a separate place in UI (tab) for plugins?
>>>Settings tab seems to be overloaded.
>>>6. When are we planning to focus on the 2 plugins which were
>>>identified as must-haves for 6.0? Cinder & LBaaS
>>>
>>> Once again, great job guys!
>>>
>>> Thanks,
>>> Roman
>>>
>>> On Fri, Oct 17, 2014 at 9:32 AM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
>>>> Thanks, Evgeny, excellent work!
>>>> Roman, I believe we are "green" with the feature. Watch yourself.
>>>>
>>>> Mike Scherbakov
>>>> #mihgen
>>>> On Oct 17, 2014 8:25 PM, "Evgeniy L"  wrote:
>>>>
>>>>> Hi guys, here are the videos from the demo
>>>>>
>>>>> Part 1
>>>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXUGY1QVYyX3NLTWc/view
>>>>>
>>>>> Part 2
>>>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXWkRmV05fT1VEQkk/view
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

[Vitaly Kramskikh]

+1

2014-10-13 20:53 GMT+07:00 Evgeniy L :

> Hi everyone!
>
> I would like to propose Igor Kalnitsky as a core reviewer on the
> Fuel-web team. Igor has been working on openstack patching,
> nailgun, fuel upgrade and provided a lot of good reviews [1]. In
> addition he's also very active in IRC and mailing list.
>
> Can the other core team members please reply with your votes
> if you agree or disagree.
>
> Thanks!
>
> [1]
> http://stackalytics.com/?project_type=stackforge&release=juno&module=fuel-web
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Vitaly Kramskikh]

+1

2014-10-10 16:35 GMT+07:00 Vladimir Kuklin :

> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this
> imposes a requirement of increasing amount of core reviewers. I would like
> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
> reviewers. As you know, they have been participating actively in
> development, design and code review of the majority of project components
> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
> 2] (not to mention being just brilliant engineers and nice people).
>
> Please, reply to my message if you agree or disagree separately for Bogdan
> and Sergii (this is mandatory for existing core-reviewers).
>
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> <http://stackalytics.com/?project_type=stackforge&module=fuel-library>
> [2] http://stackalytics.com/report/contribution/fuel-library/180
> <http://stackalytics.com/?project_type=stackforge&module=fuel-library>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Evgeniy,

Yes, the plugin management page should be a separate page. As for
dependency on releases, I meant that some plugin can work only on Ubuntu
for example, so for different releases different plugins could be available.

And please confirm that you also agree with the flow: the user install a
plugin, then he enables it on the plugin management page, and then he
creates an environment and on the first step he can uncheck some plugins
which he doesn't want to use in that particular environment.

2014-10-09 20:11 GMT+07:00 Evgeniy L :

> Hi,
>
> Vitaly, I like the idea of having separate page, but I'm not sure if it
> should be on releases page.
> Usually a plugin is not release specific, usually it's environment
> specific and you can have
> different set of plugins for different environments.
>
> Also I don't think that we should enable plugins by default, user should
> enable plugin if he wants
> it to be installed.
>
> Thanks,
>
> On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh 
> wrote:
>
>> Let me propose another approach. I agree with most of Dmitry's statements
>> and it seems in MVP we need plugin management UI where we can enable
>> installed plugins. It should be a separate page. If you want to create
>> environment with a plugin, enable the plugin on this page and create a new
>> environment. You can also disable and uninstall plugins using that page (if
>> there is no environments with the plugin enabled).
>>
>> The main reason why I'm against Evgeniy's 2nd approach (explicitly
>> enabling plugins in the wizard) is that we need to add a step where we
>> choose the plugins. This step should be added right after choice of
>> environment name and release, because options on the next steps and even
>> steps could be added from plugins. And this is complete disaster for UX.
>> Imagine a new user which uses Fuel for the first time and has to decide
>> which plugins he will use right after giving a name to an environment.
>>
>> So I think if we implement plugin management page and make user
>> explicitly and globally enable installed plugins there we can implement
>> Evgeniy's 2nd approach, but in a slightly different way. I think we need to
>> use all enabled plugins for new environments by default and let user to
>> uncheck some of them, so they won't be used for that particular
>> environment. I think the checkboxes should be right on the first pane under
>> release selectbox (it makes sense because different releases could have
>> different plugins available). These checkboxes should be hidden by default
>> and only appear after user clicks a button named like "customize used
>> plugins". I think we should use the word "use" here instead of "enable" as
>> we "enable" plugins on the plugin management page.
>>
>> The plugin management page and explicit enabling of plugins are also
>> required for plugins with an UI part as we need to preload it when UI loads
>> and not when the wizard opens as the plugin can contain mixins for the
>> wizard.
>>
>> What do you think?
>>
>> 2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko :
>>
>>> I don't like how this discussion is framed. The initial premise that we
>>> have
>>> only two controversial options to choose from is lazy. If there is no
>>> consensus, we should look for more options, not for a popular vote.
>>>
>>> Secondly, current level of UX is not negotiable. You can't take
>>> something that
>>> we already have and that works (and current Fuel UI is the best out
>>> there by a
>>> wide margin), and make it worse just to add a new feature. Even
>>> something as
>>> important as plugins must be an incremental improvement.
>>>
>>> With that premise, lets decompose the problem.
>>>
>>> 1. There are two levels of settings related to any plugin: a) first you
>>> have to
>>> enable enable the plugin itself; b) when the plugin is enabled, it may
>>> expose
>>> additional settings.
>>>
>>> - How can it be acceptable to have all plugins always enabled in all
>>>   environments? Do you really trust all plugin writers to carefully
>>> check for
>>>   plugin-specific options and ensure there is zero impact on an
>>> environment if
>>>   none of its options are enabled?
>>>
>>> - If all your plugins are enabled everywhere, you can't uninstall any of
>>> them
>>>   because all environments you deployed would become unmanageabl

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

 a checkbox to
> enable
>   their plugin. They only should provide name and description of the
> plugin.
>   Plugin engine should be able to produce a catalogue of installed
> plugins, and
>   UI should generate enable checkboxes from that catalogue.
>
> - If a plugin doesn't affect any available environment configuration
> options
>   outside of the settings tab (i.e. setup wizard, network settings, node
> roles,
>   disk & nic configuration), there's no reason to limit it to setup
> wizard, the
>   "enable" checkbox and whatever other options it has should all be
> present in
>   the settings page.
>
> - Do we have any plugins in 6.0 that have to be present in setup wizard
> because
>   they affect UI outside of settings page? I'm not aware of any.
>
> If so, lets start by representing all plugin settings in the settings
> page. But
> leave the room in the metadata to force some or all of plugin's settings to
> show up in the setup wizard (or even to present plugin configuration
> options
> differently in the wizard than in the settings).
>
> Just my $2,
> -DmitryB
>
> On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov 
> wrote:
> > Vitaly,
> >
> > Once again, as a plugin developer I don't care about how Sahara or
> Murano is
> > implemented. I don't care about checkboxes, either. I just want one
> simple
> > command to run on target nodes and I should be provided with the simplest
> > possible interface to:
> > 1) Write this command in some YAML and don't care about anything else
> > 2) Enable my plugin for particular environment and see if it's really
> > enabled both on UI and CLI (and through pure API by simple field
> checking)
> >
> > If it provides some separate service - this doesn't change anything, I
> just
> > need it to be listed somewhere in "plugins" inside cluster data to know
> that
> > it'll be executed.
> >
> > How will it work with your approach?
> >
> > 08 Окт 2014 г. 20:00 пользователь "Vitaly Kramskikh"
> >  написал:
> >
> >> Hi, responses inline.
> >>
> >> 2014-10-08 21:09 GMT+07:00 Evgeniy L :
> >>>
> >>> Hi,
> >>>
> >>> Vitaly, I understand your concerns about UX.
> >>> But there are technical problems and statements which affect
> >>> plugin developer and makes his live more complicated.
> >>>
> >>> My opinion is we definitely should know, if plugin is disabled
> >>> or if it's enabled for specific environment.
> >>>
> >>> 1. plugin developer defines tasks, like "I want the script to be
> >>> executed on nodes with controller role" and I don't think that
> >>> he expects this task to be run on all of the nodes, also
> >>> I don't think that we want ask plugin developer to parse
> >>> yaml with bash in order to understand if his plugin is enabled,
> >>> it's a bad design
> >>
> >> Bash script shouldn't be even run if the conditions to run it are not
> met.
> >> I described above how it could be done.
> >>>
> >>> 2. there will be no way to uninstall the plugin, because all of the
> >>> plugins are enabled on the environments, even if user doesn't
> >>> use them
> >>
> >> Well, this is the only issue that I see with the first approach and I
> >> still don't know how to solve it.
> >>>
> >>> Also I don't think that it's a good interface, to ask plugin developr
> >>> to include checkbox in each plugin.
> >>>
> >> It should be included only in plugins which affect the installation. For
> >> example, if OSTF was a plugin it wouldn't need such a checkbox. We can
> also
> >> make kind of plugin bootstrap or a sample plugin whcih will include a
> single
> >> control.
> >>>
> >>> The second solution is discussed because it's the most explicit
> >>> way to solve described problem.
> >>>
> >>> Let's try to figure out the solution which will work well for user
> >>> and for plugin developer.
> >>>
> >>> For example, for each plugin generate section on UI with checkbox
> >>> Like:
> >>
> >> Well, first Nikolay disliked need for a checkbox for any plugin and now
> >> you want to autogenerate a section. Why woudn't we give plugin writers
> >> abilit

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Hi, responses inline.

2014-10-08 21:09 GMT+07:00 Evgeniy L :

> Hi,
>
> Vitaly, I understand your concerns about UX.
> But there are technical problems and statements which affect
> plugin developer and makes his live more complicated.
>
> My opinion is we definitely should know, if plugin is disabled
> or if it's enabled for specific environment.
>
> 1. plugin developer defines tasks, like "I want the script to be
> executed on nodes with controller role" and I don't think that
> he expects this task to be run on all of the nodes, also
> I don't think that we want ask plugin developer to parse
> yaml with bash in order to understand if his plugin is enabled,
> it's a bad design
>
Bash script shouldn't be even run if the conditions to run it are not met.
I described above how it could be done.

> 2. there will be no way to uninstall the plugin, because all of the
> plugins are enabled on the environments, even if user doesn't
> use them
>
Well, this is the only issue that I see with the first approach and I still
don't know how to solve it.

> Also I don't think that it's a good interface, to ask plugin developr
> to include checkbox in each plugin.
>
> It should be included only in plugins which affect the installation. For
example, if OSTF was a plugin it wouldn't need such a checkbox. We can also
make kind of plugin bootstrap or a sample plugin whcih will include a
single control.

> The second solution is discussed because it's the most explicit
> way to solve described problem.
>
> Let's try to figure out the solution which will work well for user
> and for plugin developer.
>
> For example, for each plugin generate section on UI with checkbox
> Like:
>
Well, first Nikolay disliked need for a checkbox for any plugin and now you
want to autogenerate a section. Why woudn't we give plugin writers ability
to describe the controls themselves? For example, LBaaS would require a
single checkbox in "Additional Services" section.

>
> GlusterFS [ ] - disable all of the fields for the section
> Here is some description of the section, which we can take from
> description field.
>
> IP address [127.0.0.1] - this field provides plugin developer
>
> If plugin is set, we add env <-> plugin relation, if it's unset, we
> delete it.
> Also when user checks the checkbox, UI will be able to retrieve
> attributes which plugin provides. But it's not so easy todo, I'm not
> sure if we can do it with hooks, but it's possible with some separate
> model and handlers.
>
> Thanks,
>
> On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh  > wrote:
>
>> Nikolay,
>>
>> Currently every thing that can be turned into a plugin (Ceph, vCenter,
>> Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
>> controls) for the settings tab. Why change this approach for plugins? The
>> settings tab (cluster attributes) currently is a SSOT
>> <http://en.wikipedia.org/wiki/Single_Source_of_Truth>, and you want to
>> ruin it for no reason.
>>
>> Of course it makes no sense to generate anything. Checkboxes on the
>> settings tab can be added using simple YAML mixin and if you want to check
>> this checkbox to determine whether to perform some action or not and don't
>> want to write any python code, try to add to plugin's YAML "restrictions"
>> section which we already have for the settings tab, the wizard and roles.
>>
>> 2014-10-08 14:50 GMT+07:00 Nikolay Markov :
>>
>>> >>> Right now we already have like 2 types of plugins (extensions),
>>> classified by usage of settings tab:
>>> >>> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
>>> or hypervisor (lvm/qemu/vmware)
>>> >>> 2. Self-contained service that just needs to be installed (sahara,
>>> murano, zabbix)
>>>
>>> That's not quite right. In 6.0 and after that there will be a lot of
>>> small plugins which only modify some config and/or install some
>>> package. There is nothing to configure here, and I as a plugin
>>> developer don't even want to know anything about checkboxes on UI. I
>>> just want two things: role to execute my command on and command
>>> itself. That's one small YAML.
>>>
>>> And autogenerating checkboxes for such plugins on UI is bad, because
>>> explicit is better than implicit (and all our settings are explicitly
>>> defined in openstack.yaml).
>>>
>>> On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak 
>&g

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

So they should be implemented like Murano or Sahara and provide a checkbox
in "Additional Services" section of the settings tab and the wizard

2014-10-08 19:57 GMT+07:00 Nikolay Markov :

> Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
> they should do is  installing a package and modify a couple of config files
> (run a shell command).
> These ones have nothing to do with UI or any checkboxes, aren't they?
> 08 Окт 2014 г. 12:49 пользователь "Vitaly Kramskikh" <
> vkramsk...@mirantis.com> написал:
>
> Nikolay,
>>
>> Currently every thing that can be turned into a plugin (Ceph, vCenter,
>> Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
>> controls) for the settings tab. Why change this approach for plugins? The
>> settings tab (cluster attributes) currently is a SSOT
>> <http://en.wikipedia.org/wiki/Single_Source_of_Truth>, and you want to
>> ruin it for no reason.
>>
>> Of course it makes no sense to generate anything. Checkboxes on the
>> settings tab can be added using simple YAML mixin and if you want to check
>> this checkbox to determine whether to perform some action or not and don't
>> want to write any python code, try to add to plugin's YAML "restrictions"
>> section which we already have for the settings tab, the wizard and roles.
>>
>> 2014-10-08 14:50 GMT+07:00 Nikolay Markov :
>>
>>> >>> Right now we already have like 2 types of plugins (extensions),
>>> classified by usage of settings tab:
>>> >>> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
>>> or hypervisor (lvm/qemu/vmware)
>>> >>> 2. Self-contained service that just needs to be installed (sahara,
>>> murano, zabbix)
>>>
>>> That's not quite right. In 6.0 and after that there will be a lot of
>>> small plugins which only modify some config and/or install some
>>> package. There is nothing to configure here, and I as a plugin
>>> developer don't even want to know anything about checkboxes on UI. I
>>> just want two things: role to execute my command on and command
>>> itself. That's one small YAML.
>>>
>>> And autogenerating checkboxes for such plugins on UI is bad, because
>>> explicit is better than implicit (and all our settings are explicitly
>>> defined in openstack.yaml).
>>>
>>> On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak 
>>> wrote:
>>> > If there is no checkboxes (read configuration) and plugin is installed
>>> - all
>>> > deployment tasks will be applied
>>> > to every environment, but why do you think that there will be no
>>> checkboxes
>>> > in most cases?
>>> >
>>> > Right now we already have like 2 types of plugins (extensions),
>>> classified
>>> > by usage of settings tab:
>>> > 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
>>> > hypervisor (lvm/qemu/vmware)
>>> > 2. Self-contained service that just needs to be installed (sahara,
>>> murano,
>>> > zabbix)
>>> >
>>> > In 1st case you need to provide shared configuration storage (like
>>> cluster
>>> > attributes right now), in order for plugin
>>> > to be able to exclude part of core workflow from running (not
>>> installing
>>> > swift for example).
>>> > In case if the plugin is self-contained entity, like Sahara, Murano
>>> right
>>> > now - checkboxes would be simply required.
>>> > It works this way right now, and it doesnot look like huge overhead.
>>> >
>>> > So what do you think, will it work or no?
>>> >
>>> > On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov 
>>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Frankly speaking, I'm not sure on how 1st approach will even work.
>>> >> What if plugin doesn't provide any checkboxes (and in most cases it
>>> >> won't)? How should we determine in serializer, which plugins should be
>>> >> applied while generating astute.yaml and tasks.yaml? Should we
>>> >> autogenerate some stuff for plugins which are not even enabled and do
>>> >> needless work?
>>> >>
>>> >> This looks too complicated for me from the backend side, and option
>>> >> with enabling/disabling plugins in wizard for specific environme

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
<http://en.wikipedia.org/wiki/Single_Source_of_Truth>, and you want to ruin
it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML "restrictions"
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov :

> >>> Right now we already have like 2 types of plugins (extensions),
> classified by usage of settings tab:
> >>> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
> or hypervisor (lvm/qemu/vmware)
> >>> 2. Self-contained service that just needs to be installed (sahara,
> murano, zabbix)
>
> That's not quite right. In 6.0 and after that there will be a lot of
> small plugins which only modify some config and/or install some
> package. There is nothing to configure here, and I as a plugin
> developer don't even want to know anything about checkboxes on UI. I
> just want two things: role to execute my command on and command
> itself. That's one small YAML.
>
> And autogenerating checkboxes for such plugins on UI is bad, because
> explicit is better than implicit (and all our settings are explicitly
> defined in openstack.yaml).
>
> On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak 
> wrote:
> > If there is no checkboxes (read configuration) and plugin is installed -
> all
> > deployment tasks will be applied
> > to every environment, but why do you think that there will be no
> checkboxes
> > in most cases?
> >
> > Right now we already have like 2 types of plugins (extensions),
> classified
> > by usage of settings tab:
> > 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
> > hypervisor (lvm/qemu/vmware)
> > 2. Self-contained service that just needs to be installed (sahara,
> murano,
> > zabbix)
> >
> > In 1st case you need to provide shared configuration storage (like
> cluster
> > attributes right now), in order for plugin
> > to be able to exclude part of core workflow from running (not installing
> > swift for example).
> > In case if the plugin is self-contained entity, like Sahara, Murano right
> > now - checkboxes would be simply required.
> > It works this way right now, and it doesnot look like huge overhead.
> >
> > So what do you think, will it work or no?
> >
> > On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov 
> wrote:
> >>
> >> Hi,
> >>
> >> Frankly speaking, I'm not sure on how 1st approach will even work.
> >> What if plugin doesn't provide any checkboxes (and in most cases it
> >> won't)? How should we determine in serializer, which plugins should be
> >> applied while generating astute.yaml and tasks.yaml? Should we
> >> autogenerate some stuff for plugins which are not even enabled and do
> >> needless work?
> >>
> >> This looks too complicated for me from the backend side, and option
> >> with enabling/disabling plugins in wizard for specific environment (we
> >> can invent mechanism to disable them on env which is not deployed yet,
> >> besides, for API it's just one PUT) is MUCH simpler and much more
> >> obvious, as I see.
> >>
> >>
> >>
> >> On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
> >>  wrote:
> >> > Hi,
> >> >
> >> > I would go with the 1st approach. The thing I don't like in the 2nd
> >> > approach
> >> > is that we have to make the user enable plugin twice. For example, we
> >> > have
> >> > to enable Ceph as a plugin and then add Ceph role to nodes and choose
> >> > what
> >> > we want to store in Ceph (images, objects). Why we would need to
> >> > explicitly
> >> > enable Ceph plugin? Let's always show plugin options in wizard and
> >> > settings
> >> > tab, and if the user just doesn't want to enable Ceph, he would just
> >> > leave
> >> > all the checkboxes unchecked. The 2nd approach would also lead to some
> >> > kind
> >> > of inconsistency in case the user enable

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Hi,

I would go with the 1st approach. The thing I don't like in the 2nd
approach is that we have to make the user enable plugin twice. For example,
we have to enable Ceph as a plugin and then add Ceph role to nodes and
choose what we want to store in Ceph (images, objects). Why we would need
to explicitly enable Ceph plugin? Let's always show plugin options in
wizard and settings tab, and if the user just doesn't want to enable Ceph,
he would just leave all the checkboxes unchecked. The 2nd approach would
also lead to some kind of inconsistency in case the user enabled Ceph
plugin but left all the Ceph-related checkboxes unchecked and didn't add
Ceph nodes.

2014-10-07 21:17 GMT+07:00 Evgeniy L :

> Hi,
>
> We had a meeting today about plugins on UI, as result of the meeting
> we have two approaches and this approaches affect not only UX but
> plugins itself.
>
> *1st - disable/enable plugin on settings tab*
>
>1. user installs the plugin
>2. creates a cluster
>3. configures and enables/disables plugins on settings tab
>
> For user it will look like Ceph plugin checkboxes on settings tab,
> if he enables checkbox, then we pass the parameter to orchestrator
> as `true`.
>
> Cons:
>
>- plugin developer should define a checkbox in each plugin (for plugin
>disabling/enabling)
>- on the backend we have to enable all of the plugins for environment,
>because user can define any name for his checkbox and we won't be able to
>find it and make appropriate mapping plugin <-> env
>- since all of the plugins are always "enabled" we have to run tasks
>for all of the plugins, and each plugin should parse astute.yaml in order
>to figure out if it's required to run task current script
>
> Pros:
>
>- it won't require additional setting or step for wizard
>- user will be able to disable plugin after environment creation
>
> *2nd - enable plugins in wizard*
>
>1. user installs the plugin
>2. now he can choose specific plugins for his environment in wizard
>3. after cluster is created, he can configure additional parameters on
>settings tab, if plugin provides any
>
> Cons:
>
>- user won't be able to disable plugin after cluster is created
>- additional step or configuration subcategory in wizard
>
> Pros:
>
> On backend we always know which plugin is disabled and which is enabled.
>
>
>
>- it means we don't provide settings for plugins which are disabled
>- we don't run tasks on slaves if it's not required
>
> Thanks,
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed

[Vitaly Kramskikh]

We had a short discussion and decided to implement this feature for 5.1 in
this way:

   1. Do not store credentials at all even in browser
   2. Do not implement specific handling of auth errors
   3. Make the form hidden by default; it can be shown by clicking a button
   4. There will be a short description

It will look like this:

http://i.imgur.com/0Uwx0M5.png

http://i.imgur.com/VF1skHw.png

I think we'll change the button text to "Provide Credentials" and the
description to "If you changed the credentials after deployment, you need
to provide new ones to run the checks. The credentials won't be stored
anywhere.". Your suggestions are welcome.


2014-07-12 2:54 GMT+04:00 David Easter :

> I think showing this only upon failure is good – if the user is also given
> the option to sore the credentials in the browser.  That way, you only have
> to re-enter the credentials once if you want convenience, or do it every
> time if you want improved security.
>
> One downside would be that if you don’t cache the credentials, you’ll have
> to “fail” the auth every time to be given the chance to re-enter the
> credentials.  It may not be obvious that clicking “run tests” will then let
> you enter new credentials.   I was thinking that having a button you can
> press to enter the credentials would make it more obvious, but wouldn’t
> reduce the number of clicks… I.e. either run tests and fail or click “Enter
> credentials” and enter new ones.  The “Enter credential” option would
> obviously be a little faster…
>
> - David J. Easter
>   Director of Product Management,   Mirantis, Inc.
>
> From: Mike Scherbakov 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, July 11, 2014 at 2:36 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after
> password is changed
>
> I'm wondering if we can show all these windows ONLY if there is authz
> failure with existing credentials from Nailgun.
> So the flow would be: user clicks on "Run tests" button, healthcheck tries
> to access OpenStack and fails. It shows up text fields to enter
> tenant/user/pass with the message similar to "Default administrative
> credentials to OpenStack were changed since the deployment time. Please
> provide current credentials so HealthCheck can access OpenStack and run
> verification tests."
>
> I think it should be more obvious this way...
>
> Anyone, it must be a choice for a user, if he wants to store creds in a
> browser.
>
>
> On Fri, Jul 11, 2014 at 8:50 PM, Vitaly Kramskikh  > wrote:
>
>> Hi,
>>
>> In the current implementation we store provided credentials in browser
>> local storage. What's your opinion on that? Maybe we shouldn't store new
>> credentials at all even in browser? So users have to enter them manually
>> every time they want to run OSTF.
>>
>>
>> 2014-06-25 13:47 GMT+04:00 Dmitriy Shulyak :
>>
>> It is possible to change everything so username, password and tenant
>>> fields
>>>
>>> Also this way we will be able to run tests not only as admin user
>>>
>>>
>>> On Wed, Jun 25, 2014 at 12:29 PM, Vitaly Kramskikh <
>>> vkramsk...@mirantis.com> wrote:
>>>
>>>> Dmitry,
>>>>
>>>> Fields or field? Do we need to provide password only or other
>>>> credentials are needed?
>>>>
>>>>
>>>> 2014-06-25 13:02 GMT+04:00 Dmitriy Shulyak :
>>>>
>>>> Looks like we will stick to #2 option, as most reliable one.
>>>>>
>>>>> - we have no way to know that openrc is changed, even if some scripts
>>>>> relies on it - ostf should not fail with auth error
>>>>> - we can create ostf user in post-deployment stage, but i heard that
>>>>> some ceilometer tests relied on admin user, also
>>>>>   operator may not want to create additional user, for some reasons
>>>>>
>>>>> So, everybody is ok with additional fields on HealthCheck tab?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 20, 2014 at 8:17 PM, Andrew Woodward 
>>>>> wrote:
>>>>>
>>>>>> The openrc file has to be up to date for some of the HA scripts to
>>>>>> work, we could just source that.
>>>>>>
>>>>>> On Fri, Jun 20, 

Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed

[Vitaly Kramskikh]

Hi,

In the current implementation we store provided credentials in browser
local storage. What's your opinion on that? Maybe we shouldn't store new
credentials at all even in browser? So users have to enter them manually
every time they want to run OSTF.


2014-06-25 13:47 GMT+04:00 Dmitriy Shulyak :

> It is possible to change everything so username, password and tenant fields
>
> Also this way we will be able to run tests not only as admin user
>
>
> On Wed, Jun 25, 2014 at 12:29 PM, Vitaly Kramskikh <
> vkramsk...@mirantis.com> wrote:
>
>> Dmitry,
>>
>> Fields or field? Do we need to provide password only or other credentials
>> are needed?
>>
>>
>> 2014-06-25 13:02 GMT+04:00 Dmitriy Shulyak :
>>
>> Looks like we will stick to #2 option, as most reliable one.
>>>
>>> - we have no way to know that openrc is changed, even if some scripts
>>> relies on it - ostf should not fail with auth error
>>> - we can create ostf user in post-deployment stage, but i heard that
>>> some ceilometer tests relied on admin user, also
>>>   operator may not want to create additional user, for some reasons
>>>
>>> So, everybody is ok with additional fields on HealthCheck tab?
>>>
>>>
>>>
>>>
>>> On Fri, Jun 20, 2014 at 8:17 PM, Andrew Woodward 
>>> wrote:
>>>
>>>> The openrc file has to be up to date for some of the HA scripts to
>>>> work, we could just source that.
>>>>
>>>> On Fri, Jun 20, 2014 at 12:12 AM, Sergii Golovatiuk
>>>>  wrote:
>>>> > +1 for #2.
>>>> >
>>>> > ~Sergii
>>>> >
>>>> >
>>>> > On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin 
>>>> wrote:
>>>> >>
>>>> >> +1 to Mike. Let the user provide actual credentials and use them in
>>>> place.
>>>> >>
>>>> >>
>>>> >> On Fri, Jun 20, 2014 at 2:01 AM, Mike Scherbakov
>>>> >>  wrote:
>>>> >>>
>>>> >>> I'm in favor of #2. I think users might not want to have their
>>>> password
>>>> >>> stored in Fuel Master node.
>>>> >>> And if so, then it actually means we should not save it when user
>>>> >>> provides it on HealthCheck tab.
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Jun 19, 2014 at 8:05 PM, Vitaly Kramskikh
>>>> >>>  wrote:
>>>> >>>>
>>>> >>>> Hi folks,
>>>> >>>>
>>>> >>>> We have a bug which prevents OSTF from working if user changes a
>>>> >>>> password which was using for the initial installation. I skimmed
>>>> through the
>>>> >>>> comments and it seems there are 2 viable options:
>>>> >>>>
>>>> >>>> Create a separate user just for OSTF during OpenStack installation
>>>> >>>> Provide a field for a password in UI so user could provide actual
>>>> >>>> password in case it was changed
>>>> >>>>
>>>> >>>> What do you guys think? Which options is better?
>>>> >>>>
>>>> >>>> --
>>>> >>>> Vitaly Kramskikh,
>>>> >>>> Software Engineer,
>>>> >>>> Mirantis, Inc.
>>>> >>>>
>>>> >>>> ___
>>>> >>>> OpenStack-dev mailing list
>>>> >>>> OpenStack-dev@lists.openstack.org
>>>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Mike Scherbakov
>>>> >>> #mihgen
>>>> >>>
>>>> >>>
>>>> >>> ___
>>>> >>> OpenStack-dev mailing list
>>>> >>> OpenStack-dev@lists.openstack.org
>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Andrey Danin

Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed

[Vitaly Kramskikh]

Dmitry,

Fields or field? Do we need to provide password only or other credentials
are needed?


2014-06-25 13:02 GMT+04:00 Dmitriy Shulyak :

> Looks like we will stick to #2 option, as most reliable one.
>
> - we have no way to know that openrc is changed, even if some scripts
> relies on it - ostf should not fail with auth error
> - we can create ostf user in post-deployment stage, but i heard that some
> ceilometer tests relied on admin user, also
>   operator may not want to create additional user, for some reasons
>
> So, everybody is ok with additional fields on HealthCheck tab?
>
>
>
>
> On Fri, Jun 20, 2014 at 8:17 PM, Andrew Woodward  wrote:
>
>> The openrc file has to be up to date for some of the HA scripts to
>> work, we could just source that.
>>
>> On Fri, Jun 20, 2014 at 12:12 AM, Sergii Golovatiuk
>>  wrote:
>> > +1 for #2.
>> >
>> > ~Sergii
>> >
>> >
>> > On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin 
>> wrote:
>> >>
>> >> +1 to Mike. Let the user provide actual credentials and use them in
>> place.
>> >>
>> >>
>> >> On Fri, Jun 20, 2014 at 2:01 AM, Mike Scherbakov
>> >>  wrote:
>> >>>
>> >>> I'm in favor of #2. I think users might not want to have their
>> password
>> >>> stored in Fuel Master node.
>> >>> And if so, then it actually means we should not save it when user
>> >>> provides it on HealthCheck tab.
>> >>>
>> >>>
>> >>> On Thu, Jun 19, 2014 at 8:05 PM, Vitaly Kramskikh
>> >>>  wrote:
>> >>>>
>> >>>> Hi folks,
>> >>>>
>> >>>> We have a bug which prevents OSTF from working if user changes a
>> >>>> password which was using for the initial installation. I skimmed
>> through the
>> >>>> comments and it seems there are 2 viable options:
>> >>>>
>> >>>> Create a separate user just for OSTF during OpenStack installation
>> >>>> Provide a field for a password in UI so user could provide actual
>> >>>> password in case it was changed
>> >>>>
>> >>>> What do you guys think? Which options is better?
>> >>>>
>> >>>> --
>> >>>> Vitaly Kramskikh,
>> >>>> Software Engineer,
>> >>>> Mirantis, Inc.
>> >>>>
>> >>>> ___
>> >>>> OpenStack-dev mailing list
>> >>>> OpenStack-dev@lists.openstack.org
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Mike Scherbakov
>> >>> #mihgen
>> >>>
>> >>>
>> >>> ___
>> >>> OpenStack-dev mailing list
>> >>> OpenStack-dev@lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Andrey Danin
>> >> ada...@mirantis.com
>> >> skype: gcon.monolake
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Andrew
>> Mirantis
>> Ceph community
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed

[Vitaly Kramskikh]

Hi folks,

We have a bug <https://bugs.launchpad.net/fuel/+bug/1281838> which prevents
OSTF from working if user changes a password which was using for the
initial installation. I skimmed through the comments and it seems there are
2 viable options:

   1. Create a separate user just for OSTF during OpenStack installation
   2. Provide a field for a password in UI so user could provide actual
   password in case it was changed

What do you guys think? Which options is better?

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

[Vitaly Kramskikh]

Hi Jaromir,

2014/1/13 Jaromir Coufal 

> So what we can do at the moment (until there is some way to specify which
> node to remove) is to inform user, which nodes were removed in the end...
> at least.
>
> In the future, I'd like to enable user to have both ways available - just
> decrease number and let system to decide which nodes are going to be
> removed for him (but at least inform in advance which nodes are the chosen
> ones). Or, let user to choose by himself.
>

I think the functionality to choose which node is allocated for each role
is needed to. I didn't realize how/if it is possible from the wireframes.

For example, I have 3 racks. I want to allocate 1 node from each rack for
Controller and make other nodes Computes and then make each rack a separate
availability zone. In this case I need to specify which exact node will
become Controller.

Is it possible to do this?

-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] [i18n] Internationalization of Fuel 4.0 UI

[Vitaly Kramskikh]

Folks,

We are glad to announce that we've finished internationalization of Fuel UI
and now it can be easily localized. This is an example of environment
network settings tab localized to Chinese:


[image: Встроенное изображение 2] 

These changes are available in the current master branch and also will be
available in the upcoming 4.0 release.

Contributions are welcome! If you want to contribute translations, please
start by reading these
guidelines.
Fuel UI is a Backbone.js-based application which interacts directly with
Fuel REST API server (nailgun). Internationalization is done using i18next
library . To setup a development environment, use this
doc .
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev