Re: [openstack-dev] [fuel] Capacity table
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 <dmdmitr...@mirantis.com>: > 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 <vkramsk...@mirantis.com> > 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 <dmdmitr...@mirantis.com>: > >> 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
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 <dmdmitr...@mirantis.com>: > 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
+1 for this, #fuel-ui should also be merged there I think. 2016-06-24 13:26 GMT+03:00 Vladimir Kozhukalov <vkozhuka...@mirantis.com>: > 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)
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 <krotsch...@gmail.com>: > 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 <vkramsk...@mirantis.com> > 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 <krotsch...@gmail.com>: >> >>> 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.
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 <krotsch...@gmail.com>: > 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)
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 <krotsch...@gmail.com>: > 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
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 <ashtoko...@mirantis.com>: > Hi, +1 from my side. > > --- > WBR, Alexey Shtokolov > > 2016-04-14 16:47 GMT+03:00 Evgeniy L <e...@mirantis.com>: > >> 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
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 <ikalnit...@mirantis.com>: > 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
lt; >> mailto:spasqu...@mirantis.com <spasqu...@mirantis.com>>) >> wrote: >> >> Hello Roman, >> >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me < >> mailto:m...@romcheg.me <m...@romcheg.me>>> >> wrote: >> >> >> Fuelers, >> >> I remember we’ve discussing 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
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 <vkramsk...@mirantis.com>: > 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 <vkozhuka...@mirantis.com>: > >> 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
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 <vkuk...@mirantis.com>: > 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 <vkramsk...@mirantis.com > > 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 <ashtoko...@mirantis.com>: >> >>> 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. >> >> ___
Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab
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 <ashtoko...@mirantis.com>: > 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
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 <vkozhuka...@mirantis.com>: > 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
+1 2016-02-25 16:41 GMT+07:00 Sergey Kulanov <skula...@mirantis.com>: > +1 > > 2016-02-25 11:37 GMT+02:00 Alexander Kislitsky <akislit...@mirantis.com>: > >> +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 <adide...@mirantis.com> >>> wrote: >>> >>> +1 >>> >>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin <vkuk...@mirantis.com> >>> 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
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 <ikalnit...@mirantis.com>: > 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 > <vkramsk...@mirantis.com> 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 <m...@romcheg.me>: > >> > >> Cannot we use display the same link we use in the title? > >> > >> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh <vkramsk...@mirantis.com> > >> написав(ла): > >> > >> 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 <m...@romcheg.me>: > >>> > >>> Whoops! I forgot to attach the link. Sorry! > >>> > >>> 1. http://i.imgur.com/8GaUtDq.png > >>> > >>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko <m...@romcheg.me> > написав(ла): > >>> > > >>> > 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 > &g
Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard
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 <ikalnit...@mirantis.com>: > 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 > <vkramsk...@mirantis.com> 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 <ikalnit...@mirantis.com>: > >> > >> 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 > >> <vkramsk...@mirantis.com> 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 <m...@romcheg.me>: > >> >> > >> >> Cannot we use display the same link we use in the title? > >> >> > >> >> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh <vkramsk...@mirantis.com> > >> >> написав(ла): > >> >> > >> >> 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 <m...@romcheg.me>: > >> >>> > >> >>> Whoops! I forgot to attach the link. Sorry! > >> >>> > >> >>> 1. http://i.imgur.com/8GaUtDq.png > >> >>> > >> >>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko <m...@romcheg.me> > >> >>> > написав(ла): > >> >>> > > >> >>> > 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: > >> >>&
Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard
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 <m...@romcheg.me>: > Cannot we use display the same link we use in the title? > > 9 лют. 2016 р. о 14:14 Vitaly Kramskikh <vkramsk...@mirantis.com> > написав(ла): > > 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 <m...@romcheg.me>: > >> Whoops! I forgot to attach the link. Sorry! >> >> 1. http://i.imgur.com/8GaUtDq.png >> >> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko <m...@romcheg.me> написав(ла): >> > >> > 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] [Fuel UI] Node role list grouping
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 <bdobre...@mirantis.com>: > 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
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 <ogusare...@mirantis.com>: > 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?
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 <spasqu...@mirantis.com>: > 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
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
[openstack-dev] [Fuel] [Nailgun] Deadlocks and random test failures
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] [Nailgun] Deadlocks and random test failures
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 <akislit...@mirantis.com>: > 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 <ikalnit...@mirantis.com> > 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 >> <vkramsk...@mirantis.com> 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
Re: [openstack-dev] [Fuel] Merge Freeze for cutting stable/8.0 branch
Aleksandra, What are "base packages"? Can we merge to fuel-web? 2015-12-24 18:01 GMT+03:00 Aleksandra Fedorova <afedor...@mirantis.com>: > 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 <rvya...@mirantis.com> > 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 > > <afedor...@mirantis.com> 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 > >> <afedor...@mirantis.com> 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][Ubuntu bootstrap] WebUI notification
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 <asvechni...@mirantis.com>: > 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] PostgreSQL 9.3 and JSON operations
.@danjou.info > > > >>> >> wrote: > >>> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote: > >>> >>> > >>> >>>> 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
[openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0
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] [Plugins] Ways to improve plugin links handling in 9.0
Igor, 2015-12-15 13:14 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>: > 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 > <vkramsk...@mirantis.com> 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
Re: [openstack-dev] [Fuel] Multiple repos UX
se places to provide the same UX. By that I mean
>> that
>> >>>> these components 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
___ > >>> OpenStack Development Mailing 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] [Fuel UI] Support of separate provisioning is blocked by backend issues
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 <e...@mirantis.com>: > 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 <jkirnos...@mirantis.com > > 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] Changing APIs and API versioning
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 <m...@romcheg.me>: > 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 <skalinow...@mirantis.com> > написав(ла): > > 2015-10-23 11:36 GMT+02:00 Igor Kalnitsky <ikalnit...@mirantis.com>: > >> 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 >> <vkramsk...@mirantis.com> 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 <m...@romcheg.me>: >> >> >> >> 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
Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs
+1 for "refuel" to trigger Fuel CI only, awesome idea. "recheck" will trigger both. 2015-11-20 21:12 GMT+07:00 Sergey Vasilenko <svasile...@mirantis.com>: > > On Fri, Nov 20, 2015 at 4:00 PM, Alexey Shtokolov <ashtoko...@mirantis.com > > 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
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
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 <e...@mirantis.com>: > 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 <apopov...@mirantis.com> > 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.
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] [CI] Running fuelclient tests against review requests for fuel-web repo
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 <sgolovat...@mirantis.com>: > 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 <vkramsk...@mirantis.com > > 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
Re: [openstack-dev] [Fuel] Changing APIs and API versioning
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 <m...@romcheg.me>: > 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
[openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo
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
+1, that would allow to install plugins from Fuel UI 2015-10-09 15:53 GMT+07:00 Sergii Golovatiuk <sgolovat...@mirantis.com>: > +1 to Roman. > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko <m...@romcheg.me> > wrote: > >> I’d say even if it will be a separate service it’s better to proxy >> requests through Nailgun’s API to have a single entry point. >> >> 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com> написав(ла): >> >> Hi, >> >> +1, but I think it's better to spawn separate service, instead of adding >> it to Nailgun. >> >> Thanks, >> >> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me> >> wrote: >> >>> Folks, >>> >>> it’s time to speak about Fuel Plugins and the way they are managed. >>> >>> Currently we have some methods in Fuel Client that allow to install, >>> remove and do some other things to plugins. Everything looks great except >>> that functionality requires Fuel Client to be installed on a master node >>> and be running under a root user. It’s time for us to grow up and realize >>> that nothing can require Fuel Client to be installed on a specific computer >>> and of course we cannot require root permissions for any actions. >>> >>> I’d like to move all that code to Nailgun, utilizing mules and hide it >>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and >>> I’d like to ask Fuel Enhancements subgroup of developers to take a close >>> look at it. >>> >>> >>> 1. https://bugs.launchpad.net/fuel/+bug/1504338 >>> >>> >>> - romcheg >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://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
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
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 vshars...@mirantis.com: Hi, +1 to 2nd solution too. On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L e...@mirantis.com 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] version.yaml in the context of packages
Vladimir, 2015-07-24 20:21 GMT+03:00 Vladimir Kozhukalov vkozhuka...@mirantis.com: 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] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)
+1 to Stanislav's proposal. 2015-07-27 3:05 GMT+03:00 Stanislav Makar sma...@mirantis.com: 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 kdani...@mirantis.com 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] Nominating Vladimir Kozhukalov to core reviewers of fuel-main
+1 2015-07-24 1:56 GMT+03:00 Sergey Vasilenko svasile...@mirantis.com: +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
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 daniel.depa...@create-net.org: 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][plugin] Plugin depends on another plugin
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 daniel.depa...@create-net.org: 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 daniel.depa...@create-net.org : 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] Packaged Fuel and Feature Groups
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 afedor...@mirantis.com: 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
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 spasqu...@mirantis.com: 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 samuel.bartel@gmail.com 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
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 vkramsk...@mirantis.com: 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 dpyz...@mirantis.com: +1 On Tue, May 5, 2015 at 1:06 PM, Evgeniy L e...@mirantis.com 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 pkamin...@mirantis.com : +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
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 dpyz...@mirantis.com: +1 On Tue, May 5, 2015 at 1:06 PM, Evgeniy L e...@mirantis.com 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 pkamin...@mirantis.com: +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
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
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 xar...@gmail.com: 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 vkramsk...@mirantis.com 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
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
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 pkamin...@mirantis.com: 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
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 svasile...@mirantis.com: +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
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
+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 jkirnos...@mirantis.com: 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: - node_name_list - Changed interfaces configuration on the following nodes: - node_name_list - 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 jkirnos...@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
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 e...@mirantis.com: 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 vkramsk...@mirantis.com 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] [nailgun] [UI] network_check_status fleild for environments
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-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes
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
Re: [openstack-dev] [Fuel] Support of warnings in Fuel UI
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 jkirnos...@mirantis.com: 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 jkirnos...@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
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 e...@mirantis.com: Vitaly, what do you think about that? On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L e...@mirantis.com 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 e...@mirantis.com: 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 e...@mirantis.com: 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
Re: [openstack-dev] [Fuel] Building Fuel plugins with UI part
Hi, The only thing I don't really like is that we need fuel-web code to build plugin. But we have can do nothing with it, as typical UI plugin by design is tightly coupled with the core. If plugin want to reuse core libraries, utils, controls then it has to declare them as dependencies and if there would be a build error if these files weren't found by r.js. I created the first version of spec https://review.openstack.org/#/c/141761/1 where described my vision of build process. You can comment on it there. Some responses inline: 2014-12-15 14:48 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: On 12/15/2014 02:26 PM, Anton Zemlyanov wrote: The building of the UI plugin has several things I do not like 1) I need to extract the UI part of the plugin and copy/symlink it to fuel-web This is required, the UI part should live somewhere in statics/js. This directory is served by nginx and symlinking/copying is I think the best way, far better than adding new directories to nginx configuration. I think Anton is talking not about serving, but building the plugin. Yes, to build the UI part of plugin you need to extract its UI part and move/symlink it to static/plugins/plugin_name before you can run the build. 2) I have to run grunt build on the whole fuel-web This shouldn't at all be necessary. Yes, it is not necessary. Actually you don't have if you add another task or option for grunt build to not build the main project. It can be achieved by removing these lines https://github.com/stackforge/fuel-web/blob/master/nailgun/Gruntfile.js#L45-L48. 3) I have to copy files back to original location to pack them Shouldn't be necessary. 4) I cannot easily switch between development/production versions (no way to easily change entry point) Development/production versions should only differ by serving raw/compressed files. The compressed files should be published by the plugin author. On my development machine I use different ports of nginx to serve original and compressed versions of UI. It's configuration is pretty straightforward. The only way to install plugin is `fuel plugins --install`, no matter development or production, so even development plugins should be packed to tar.gz The UI part should be working immediately after symlinking somewhere in the statics/js directory imho (and after API is aware of the new pugin but). P. Anton On Mon, Dec 15, 2014 at 3:30 PM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: First of all, compiling of statics shouldn't be a required step. No one does this during development. For production-ready plugins, the compiled files should already be included in the GitHub repos and installation of plugin should just be a matter of downloading it. The API should then take care of informing the UI what plugins are installed. The npm install step is mostly one-time. The grunt build step for the plugin should basically just compile the staticfiles of the plugin and not the whole project. Besides with one file this is not extendable -- for N plugins we would build 2^N files with all possible combinations of including the plugins? :) P. On 12/15/2014 11:35 AM, Anton Zemlyanov wrote: My experience with building Fuel plugins with UI part is following. To build a ui-less plugin, it takes 3 seconds and those commands: git clone https://github.com/AlgoTrader/test-plugin.git cd ./test-plugin fpb --build ./ When UI added, build start to look like this and takes many minutes: git clone https://github.com/AlgoTrader/test-plugin.git git clone https://github.com/stackforge/fuel-web.git cd ./fuel-web git fetch https://review.openstack.org/stackforge/fuel-web refs/changes/00/112600/24 git checkout FETCH_HEAD cd .. mkdir -p ./fuel-web/nailgun/static/plugins/test-plugin cp -R ./test-plugin/ui/* ./fuel-web/nailgun/static/plugins/test-plugin cd ./fuel-web/nailgun npm install npm update grunt build --static-dir=static_compressed cd ../.. rm -rf ./test-plugin/ui mkdir ./test-plugin/ui cp -R ./fuel-web/nailgun/static_compressed/plugins/test-plugin/* ./test-plugin/ui cd ./test-plugin fpb --build ./ I think we need something not so complex and fragile Anton ___ 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
Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format
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 vkramsk...@mirantis.com wrote: 2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com: - 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 On Sun, Nov 30, 2014 at 3:12 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: 2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com: - environment_config.yaml should contain exact config which will be mixed
Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format
2014-12-10 19:31 GMT+03:00 Evgeniy L e...@mirantis.com: 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 e...@mirantis.com: 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 when vCenter is selected as hypervisor. Ceph is enabled when it's selected as a backend for Cinder or Glance. Nope, Ceph for Volumes can be used without Ceph for Images. Both of these plugins can also have some granular tasks which are enabled by various checkboxes (like VMware vCenter for volumes). How would you determine whether tasks which installs VMware vCenter for volumes should run? Why nope? I have Cinder OR Glance. Oh, I missed it. So there are 2 checkboxes, how would you determine enableness? It can be easily handled in deployment script. I don't know much about the status of granular deployment blueprint, but AFAIK that's what we are going to get rid of. If you don't like the idea of having Ceph/vCenter checkboxes on the first page, I can suggest as an idea (research is required) to define groups like Storage Backend, Network Manager and we will allow plugin developer to embed his option in radiobutton field on wizard pages. But plugin developer should not describe conditions, he should just write that his plugin is a Storage Backend, Hypervisor or new Network Manager. And the plugins e.g. Zabbix
Re: [openstack-dev] [Fuel][Nailgun]Problems with auto-reloading
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 rprikhodche...@mirantis.com : 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
2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com: - 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
Dmitry, 2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko dborodae...@mirantis.com: 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 vkramsk...@mirantis.com 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 e...@mirantis.com: 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 e...@mirantis.com: 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
Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format
Evgeniy, Responses inline: 2014-11-28 18:31 GMT+03:00 Evgeniy L e...@mirantis.com: 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 vkramsk...@mirantis.com 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
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
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 e...@mirantis.com: 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 vkramsk...@mirantis.com 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
Re: [openstack-dev] [Fuel] Separate code freeze for repos
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 ikalnit...@mirantis.com: 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 vkramsk...@mirantis.com 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 e...@mirantis.com: 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 vkramsk...@mirantis.com 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
[openstack-dev] [Fuel] Separate code freeze for repos
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
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 afedor...@mirantis.com: 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_embeddedv=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
/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
+1 2014-10-13 20:53 GMT+07:00 Evgeniy L e...@mirantis.com: 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=stackforgerelease=junomodule=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
+1 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin vkuk...@mirantis.com: 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=stackforgemodule=fuel-library [2] http://stackalytics.com/report/contribution/fuel-library/180 http://stackalytics.com/?project_type=stackforgemodule=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
, 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 nmar...@mirantis.com 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 vkramsk...@mirantis.com написал: Hi, responses inline. 2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com: 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 vkramsk...@mirantis.com 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, 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 nmar
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
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 e...@mirantis.com: 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 vkramsk...@mirantis.com 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 dborodae...@mirantis.com: 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 unmanageable. - If you ignore uninstallation, soon you will be stuck with plugins that cannot be made removable even when Fuel itself begins to support it. - To break away from unremovable plugins, you're likely going to have to break backwards compatibility (unless you already have a forward-compatible design that allows for removable plugins in the future, but then you wouldn't have to exclude removing plugins from MVP). - And if a Fuel upgrade ever requires uninstalling a plugin due to irreconcilable incompatibility, and they're enabled in all of your environments, you're stuck unable to upgrade. So, lets not enable any plugins by default. And if we can come up with a way to make them removable (when they're not enabled in any deployed
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
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 nmar...@mirantis.com: 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 dshul...@mirantis.com 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 nmar...@mirantis.com 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 vkramsk...@mirantis.com 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 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 e...@mirantis.com: 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 user installs the plugin creates a cluster 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
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
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 nmar...@mirantis.com: 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 nmar...@mirantis.com: 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 dshul...@mirantis.com 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 nmar...@mirantis.com 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 vkramsk...@mirantis.com 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 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 e...@mirantis.com: Hi, We had a meeting today about plugins on UI, as result of the meeting we have two approaches
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
Hi, responses inline. 2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com: 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 vkramsk...@mirantis.com 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 nmar...@mirantis.com: 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 dshul...@mirantis.com 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
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
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 e...@mirantis.com: 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
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 deas...@mirantis.com: 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 mscherba...@mirantis.com 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 vkramsk...@mirantis.com 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 dshul...@mirantis.com: 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 dshul...@mirantis.com: 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 xar...@gmail.com 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 sgolovat...@mirantis.com wrote: +1 for #2. ~Sergii On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin ada...@mirantis.com 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 mscherba...@mirantis.com 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 vkramsk...@mirantis.com 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
Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed
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 dshul...@mirantis.com: 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 xar...@gmail.com 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 sgolovat...@mirantis.com wrote: +1 for #2. ~Sergii On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin ada...@mirantis.com 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 mscherba...@mirantis.com 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 vkramsk...@mirantis.com 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
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
Hi Jaromir, 2014/1/13 Jaromir Coufal jcou...@redhat.com 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
