Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

+1 On Wed, Feb 24, 2016 at 4:57 PM, Denis Egorenko wrote: > I'm not a fuel core member, but i also would like to vote +1 for Matthew. > He's doing great job! > > 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko : > >> +1 >> >> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin >> wrote: >> >>> Fellow

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

+1 On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko wrote: > I'm not a fuel core member, but i also would like to vote +1 for Matthew. > He's doing great job! > > 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko : > >> +1 >> >> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin >> wrote: >> >>> Fellow

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

I'm not a fuel core member, but i also would like to vote +1 for Matthew. He's doing great job! 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko : > +1 > > On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin > wrote: > >> Fellow Fuelers >> >> I would like to kindly ask you to consider voting for Matthe

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

+1 On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin wrote: > Fellow Fuelers > > I would like to kindly ask you to consider voting for Matthew Mosesohn as > a Fuel Library Core > reviewer. > > Matthew has been working with Fuel since its inception, worked on > countless amount of features, such a

Re: [openstack-dev] [Fuel] Wildcards instead of

Adding this to future features. On Mon, Feb 22, 2016 at 8:33 PM, Bogdan Dobrelya wrote: > On 22.02.2016 10:28, Kyrylo Galanov wrote: > > Would namespaces be compatible with existing plugins? > > It should be, if the default namespace will be "core" > > > > > On Mon, Feb 22, 2016 at 7:33 PM, Bogd

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

New git repository fuel-virtualbox has been created https://github.com/openstack/fuel-virtualbox.git and since now all review requests that are related to virtualbox scripts for releases 9.0 and later should be sent to the new git repository. Checklist status: - Launchpad bug: https://bugs.lau

Re: [openstack-dev] [Fuel] Wildcards instead of

On 22.02.2016 10:28, Kyrylo Galanov wrote: > Would namespaces be compatible with existing plugins? It should be, if the default namespace will be "core" > > On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya > wrote: > > On 20.02.2016 10:29, Evgeniy L wrote: >

Re: [openstack-dev] [Fuel] Wildcards instead of

Would namespaces be compatible with existing plugins? On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya wrote: > On 20.02.2016 10:29, Evgeniy L wrote: > > Hi, > > > > +1 to Igor, plugin developer should be able to granularly define what > > she/he wants to be executed on the node, without assumpt

Re: [openstack-dev] [Fuel] Wildcards instead of

On 20.02.2016 10:29, Evgeniy L wrote: > Hi, > > +1 to Igor, plugin developer should be able to granularly define what > she/he wants to be executed on the node, without assumptions from our side. > > `exclude` - field doesn't look like a good solution to me, it will be > hard to support and migra

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, +1 to Igor, plugin developer should be able to granularly define what she/he wants to be executed on the node, without assumptions from our side. `exclude` - field doesn't look like a good solution to me, it will be hard to support and migrate plugins to newer version OpenStack release. I wo

Re: [openstack-dev] [Fuel][puppet] Fuel CI for puppet-openstack modules

Thanks Igor! With this CI up and running we're one more step closer to completing the integration between Fuel and Puppet OpenStack projects that has started with the introduction of the puppet-librarian-simple in fuel-library. Consider the whole picture: - Fuel CI is now using mitaka-2 packages

Re: [openstack-dev] [Fuel] Wildcards instead of

> I vote to abandon it. Let's do not break existing plugins, and do not > add *undo* tasks for plugin developers. If they want to configure > network, they'll ask it explicitly. +1 to this gentleman. It's safe to add wildcards only to tasks that were moved from pre/post deployment stages, which we

Re: [openstack-dev] [Fuel] Wildcards instead of

> On 19 Feb 2016, at 17:09, Igor Kalnitsky wrote: > > Kyrylo G. wrote: >> So who is voting for the path to be abandoned? > > I vote to abandon it. Let's do not break existing plugins, and do not > add *undo* tasks for plugin developers. If they want to configure > network, they'll ask it explic

Re: [openstack-dev] [Fuel] Wildcards instead of

Kyrylo G. wrote: > So who is voting for the path to be abandoned? I vote to abandon it. Let's do not break existing plugins, and do not add *undo* tasks for plugin developers. If they want to configure network, they'll ask it explicitly. Kyrylo G. wrote: > By the way, there is already a task run

Re: [openstack-dev] [Fuel] Wildcards instead of

+1 to use wildcards for common tasks like netconfig and setup repositories. This tasks should run on all nodes and it does not matter, the node has role from plugin or core-role. In my opinion we should one approach for basic configuration of node. Regards, Bulat Gaifullin Mirantis Inc. > On

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, So who is voting for the path to be abandoned? By the way, there is already a task running by the wildcard: https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4 However, it this case it might work with plugins. Best regards, Ky

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Thu, Feb 18, 2016 at 4:00 AM, Aleksandr Didenko wrote: > > Given the requirements to be able to use new features in fuel, with an > older version of OpenStack, what alternative would you propose? > > For example, it's possible to use existing "release" functionality in Fuel > (release contains

Re: [openstack-dev] [Fuel] Wildcards instead of

Hey Kyrylo, As it was mentioned in the review: you're about to break roles defined by plugins. That's not good move, I believe. Regarding 'exclude' directive, I have no idea what you're talking about. We don't support it now, and, anyway, there should be no difference between roles defined by plu

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

> Given the requirements to be able to use new features in fuel, with an older version of OpenStack, what alternative would you propose? For example, it's possible to use existing "release" functionality in Fuel (release contains granular tasks configuration, puppet modules and manifests, configur

Re: [openstack-dev] [fuel][nailgun][volume-manager][fuel-agent] lvm metadata size value. why was it set to 64M?

Hi Alexander, I was trying to trace the change and found 3 year old commit, yes it's hard to recover the reason [0]. So what we should ask is what is a right way to calculate lvm metadata size and change this behaviour. I would suggest at least explicitly set metadata size on Nailgun side to the

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On 17.02.2016 18:23, Bogdan Dobrelya wrote: >> So we'll have tons of conditionals in composition layer, right? Even if >> some puppet-openstack class have just one new parameter in new release, >> then we'll have to write a conditional and duplicate class declaration. Or >> write complex parameters

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

I've finally compiled a spec for this topic https://review.openstack.org/#/c/281557/ On Wed, Feb 17, 2016 at 2:13 PM Alex Schultz wrote: > On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya > wrote: > >> > So we'll have tons of conditionals in composition layer, right? Even if >> > some puppet-

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class declaration. > Or > > wri

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

The merge freeze is now lifted, the transition to Mitaka has completed successfully. Fuel CI jobs for master are now based on Mitaka packages: https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.smoke_neutron/2188/ https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.neutron_vla

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Folks First of all, there is a critical bug which is not fixed. It may be floating because it is related to implicit resources ordering in puppet. But it does not mean that it is not a merge blocker. Secondly, I do not share your optimism about easiness of bugfixing of possible regressions becau

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Hi Fabrizio, The project-config patch is on the review now, waiting for a core-reviewers to merge the changes. On Wed, Feb 17, 2016 at 5:47 PM, Fabrizio Soppelsa wrote: > Vladimir, > a dedicated repo - good to hear. > Do you have a rough estimate for how long this directory will be in freeze >

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Vladimir, Obviously, there will be regressions in other scenarios. However, it's better to catch them now. We have not much time before FF, and it'd be better to merge such features as early as possible, and do not wait for merge hell a day before FF. The thing we need to know is that BVT is gree

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

BVT for master has been unblocked earlier today, and a custom ISO with Mitaka packages is passing BVT, so switching to Mitaka will not regress Fuel CI deployment tests. Lets not make this process more complicated than it has to be, non-BVT swarm regressions will have to be fixed either way, and it

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class declaration. > Or > > write

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 8:38 AM Aleksandr Didenko wrote: > > This requires the loss of all of the features in the newer version of > fuel since it relies on the older version of the serialized data from > nailgun. > > Yes. But isn't it how "stable" branches are supposed to work? Introducing > new

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Fuelers I have strong opinion against this merge freeze right now. We have critical bugs blocking bvt and we do not have enough info on mitaka readiness for other scenarios than bvt. 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko" < dborodae...@mirantis.com> написал: > Fuel core reviewers

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

> This requires the loss of all of the features in the newer version of fuel since it relies on the older version of the serialized data from nailgun. Yes. But isn't it how "stable" branches are supposed to work? Introducing new features into "stable" branches will make them not so "stable", right

Re: [openstack-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies

On 17.02.2016 16:23, Vladimir Kuklin wrote: > Fuelers > > It seems that this change [0] into Fuel came unnoticed, but it may help > you in testing your puppet catalogues. > > I was refactoring our code pieces that actually wait for Load Balancer > to be ready to serve requests. I ended putting t

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Vladimir, a dedicated repo - good to hear. Do you have a rough estimate for how long this directory will be in freeze state? Thanks, Fabrizio > On Feb 15, 2016, at 5:16 PM, Vladimir Kozhukalov > wrote: > > Dear colleagues, > > I'd like to announce that we are next to moving fuel-main/virtua

Re: [openstack-dev] [Fuel][library] Switching to external fixtures for integration Noop tests

Hello, an update inline! On 27.01.2016 17:37, Bogdan Dobrelya wrote: > On 26.01.2016 22:18, Kyrylo Galanov wrote: >> Hello Bogdan, >> >> I hope I am not the one of the context. Why do we separate fixtures for >> Noop tests from the repo? >> I can understand if while noop test block was carried out

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Hi, I have some comments on CI for plugins, currently there is a good instruction on how to install your own CI and using fuel-qa write your own tests [0], since just running BVT is not enough to make sure that plugin works, we should provide a way for a plugin developer to easily extend checks/as

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

That is awesome, happy to finally see it enabled! On Mon, Feb 15, 2016 at 9:32 PM, Anastasia Urlapova wrote: > Aleksey, great news! > > On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov > wrote: > >> Fuelers, >> >> Task based deployment engine has been enabled in master (Fuel 9.0) by >> default

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Aleksey, great news! On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov wrote: > Fuelers, > > Task based deployment engine has been enabled in master (Fuel 9.0) by > default [0] > > [0] - https://review.openstack.org/#/c/273693/ > > WBR, Alexey Shtokolov > > 2016-02-09 21:57 GMT+03:00 Vladimir Ku

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Fuelers, Task based deployment engine has been enabled in master (Fuel 9.0) by default [0] [0] - https://review.openstack.org/#/c/273693/ WBR, Alexey Shtokolov 2016-02-09 21:57 GMT+03:00 Vladimir Kuklin : > Folks > > It seems that docker removal spoilt our celebration a bit. Here is a bug > li

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Dmitry, So this changes the workflow for the devopses, the fuel plugin repo creators under Openstack namespace. As I understand, development of every new fuel plugin must be now started in a private github repo first, and when a developer(s) decide they want to go level higher they request for

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Well done, Fedor! Congrats! -Dmitry. On Mon, Feb 15, 2016 at 1:12 PM, Maksim Malchuk wrote: > Congrats! > > > On Mon, Feb 15, 2016 at 1:08 PM, Fedor Zhadaev > wrote: > >> Thank you! >> -- >> Kind Regards, >> Fedor Zhadaev >> >> skype: zhadaevfm >> IRC: fzhadaev >> >> __

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Congrats! On Mon, Feb 15, 2016 at 1:08 PM, Fedor Zhadaev wrote: > Thank you! > -- > Kind Regards, > Fedor Zhadaev > > skype: zhadaevfm > IRC: fzhadaev > > __ > OpenStack Development Mailing List (not for usage questions) >

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Thank you! -- 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.

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

Well, voting period is over and there's no objections from cores. So I'm going to add Fedor to fuel-menu-core group. Congrats Fedor! :) On Mon, Feb 8, 2016 at 2:34 PM, Aleksey Kasatkin wrote: > +1 > > > Aleksey Kasatkin > > > On Mon, Feb 8, 2016 at 12:04 PM, Tatyana Leontovich > wrote: >> >> +1

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko wrote: > Hi, > > > > So what is open? The composition layer. > > We can have different composition layers for every release and it's > already implemented in releases - separate puppet modules/manifests dir for > every release. > This requires th

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

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

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

>> We have package format <=4.0 where all files have fixed names and locations. This is the defaults. The thing is for 5.0 there should be no default, those fields from now on should be specified explicitly. >> Igor want to provide multi-package I'm not familiar with this idea, could you please

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

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

On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L wrote: > Ilya, > > What do you mean by "default"? From the data format I see that we don't > "override defaults" we specify the data for specific release, the way it > was always done for deployment scripts and repositories. > > We have package format <=

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

Ilya, What do you mean by "default"? From the data format I see that we don't "override defaults" we specify the data for specific release, the way it was always done for deployment scripts and repositories. I don't see any reasons to complicate format even more and to have some things which are

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

On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L wrote: > Ilya, > > >> My opinion that i've seen no example of multiple software of plugins > versions shipped in one package or other form of bundle. Its not a common > practice. > > With plugins we extend Fuel capabilities, which supports multiple > op

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

Vitaly, > Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon and > every plugin link Why? And how do you handle it with link now? On Fri, Feb 12, 2016 at 11:15 AM, Vitaly Kramskikh wrote: > Igor, > > Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon a

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

Stanislaw B., You're somehow contradicting in your statements. However, taking into account your's - > Both of these approaches can be used, so I'm against forcing plugin > developers to use just one approach. I can conclude that you support idea of having multi-release plugins? Because no one c

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

>>With plugins we extend Fuel capabilities, which supports multiple operating system releases, so it's absolutely natural to extend multiple releases at the same time. It is okay for me when we talk about different operating system release, but initial question was about different Fuel and OpenStac

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 dismissin

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

Ilya, >> My opinion that i've seen no example of multiple software of plugins versions shipped in one package or other form of bundle. Its not a common practice. With plugins we extend Fuel capabilities, which supports multiple operating system releases, so it's absolutely natural to extend multi

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

r/YACL/YAQL/ On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov wrote: > My opinion that i've seen no example of multiple software of plugins > versions shipped in one package or other form of bundle. Its not a common > practice. > > Anyway we need to provide ability to override paths in manifest > (

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

My opinion that i've seen no example of multiple software of plugins versions shipped in one package or other form of bundle. Its not a common practice. Anyway we need to provide ability to override paths in manifest (metadata.yaml). So the plugin developers could use this approaches to provide m

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

Hi, On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky wrote: > Hey folks, > > The original idea is to provide a way to build plugin that are > compatible with few releases. It makes sense to me, cause it looks > awful if you need to maintain different branches for different Fuel > releases and th

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

Vitaly, What about adding some button with "Go" or "Visit" text? Somewhere on the right size of line? It'd be easy to understand what to click to visit the dashboard. - Igor On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh wrote: > Roman, > > For with enabled SSL it still can be quite long as

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Thanks to all for answers! We will leave Fuel master node on a VM for our testing until some specific cases will require it on a baremetal. Ironic looks like a good tool for PXE provisioning and manage other baremetal slaves via IPMI, we will investigate how it could be used in our testing tools l

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

Sorry for the typo "s/I can shade more light/I can shed more light/" On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L wrote: > Hi, > > As an author of this part of pluggable architecture I can shade more light > on why it was implemented this way and why it's valuable to continue > supporting multi-re

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

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

Hi, As an author of this part of pluggable architecture I can shade more light on why it was implemented this way and why it's valuable to continue supporting multi-release feature. At the time it was implemented Fuel officially was supporting both Ubuntu and CentOS, in order to simplify plugins

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

Hey folks, The original idea is to provide a way to build plugin that are compatible with few releases. It makes sense to me, cause it looks awful if you need to maintain different branches for different Fuel releases and there's no difference in the sources. In that case, each bugfix to deploymen

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

Hi, The Octane team has some issues with lacking definition of what the 'release' is in Fuel (in terms of managed environments). I started an etherpad [1] to summarize the entities/artifacts that consistute a 'release' at the moment. Based on this definition, we can localize and define entry point

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

Hi, > So what is open? The composition layer. We can have different composition layers for every release and it's already implemented in releases - separate puppet modules/manifests dir for every release. > Currently, we just abandon support for previous versions in the composition layer and lea

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

I agree with Stas, one rpm - one version. But plugin builder allows to specify several releases as compatible. The deployment tasks and repositories can be specified per release, at the same time the deployment graph is one for all releases. Currently it looks like half-implemented feature. Can

Re: [openstack-dev] [fuel] Fuel Community ISO 8.0

Was a bug ever filed for this? It's still not on the landing page On Thu, Feb 4, 2016 at 4:19 AM Ivan Kolodyazhny wrote: > Thanks, Igor. > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Thu, Feb 4, 2016 at 1:21 PM, Igor Belikov > wrote: > >> Hi Ivan, >> >> I think this counts as

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

On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko wrote: > +1 to Stas, supplanting VCS branches with code duplication is a path to > madness and despair. The dubious benefits of a cross-release backwards > compatible plugin binary are not worth the code and infra technical debt > that such approa

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

+1 to Stas, supplanting VCS branches with code duplication is a path to madness and despair. The dubious benefits of a cross-release backwards compatible plugin binary are not worth the code and infra technical debt that such approach would accrue over time. On Wed, Feb 10, 2016 at 07:36:30PM +030

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

Colleagues, Centos bootstrap image (that we used to build together with the ISO) code has been removed from fuel-main. Now the only available option is the Ubuntu based bootstrap image that is built on the master node in run time. >From this moment we are ready to get rid of building Fuel packages

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

It changes mostly nothing for case of furious plugin development when big parts of code changed from one release to another. You will have 6 different deployment_tasks directories and 30 a little bit different files in root directory of plugin. Also you forgot about repositories directory (+6 at l

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Folks I think the easiest and the best option here is to boot iPXE or pxelinux with NFS and put master node image onto an NFS mount. This one should work seamlessly. On Wed, Feb 10, 2016 at 1:36 AM, Andrew Woodward wrote: > Unless we hope to gain some insight and specific testing by installing

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Unless we hope to gain some insight and specific testing by installing the ISO on a bare-metal node (like UEFI), I'd propose that we stop testing things that are well tested elsewhere (a given ISO produces a working fuel master) and just focus on what we want to test in this environment. Along thi

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Folks It seems that docker removal spoilt our celebration a bit. Here is a bug link https://bugs.launchpad.net/fuel/+bug/1543720 . Fix is trivial, but will postpone swarm run for another day. Nevertheless, it seems to be the only issue affecting our ability to use TBD. Stay tuned! On Tue, Feb 9,

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Hi, Ironic also supports running it as standalone service, w/o Keystone/Glance/Neutron/Nova etc integration, deploying images from HTTP links. Could that be an option too? BTW, there is already an official project under OpenStack Baremetal program called Bifrost [0] that, quoting, "automates the

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

+1 to Vitaly. There can be many links, so just underline those we already have is the best option. On Tue, Feb 9, 2016 at 4:31 PM, Roman Prykhodchenko wrote: > Cannot we use display the same link we use in the title? > > 9 лют. 2016 р. о 14:14 Vitaly Kramskikh > написав(ла): > > Hi, Roman, > >

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

Cannot we use display the same link we use in the title? > 9 лют. 2016 р. о 14:14 Vitaly Kramskikh написав(ла): > > Hi, Roman, > > I think the only solution here is to underline the title so it would look > like a link. I don't think it's a good idea to show full URL because: > If SSL is enabl

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

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 wou

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

Whoops! I forgot to attach the link. Sorry! 1. http://i.imgur.com/8GaUtDq.png > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko написав(ла): > > Hi fuelers! > > I’m not sure, if it’s my personal problem or the UX can be improved a little, > but I’ve literary spend more than 5 minutes trying to fig

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

> I've run BVT more than 100 times, it works, You run it some time ago. There were a lot of opportunities to introduce regression in both Nailgun and tasks of Fuel Library. ;) > We are going to run a swarm test today against the ISO with enabled > task-based deployment So there will be a custom

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Igor, We are going to run a swarm test today against the ISO with enabled task-based deployment, than check results and merge changes tomorrow. I've run BVT more than 100 times, it works, but I would like to check more deployment cases. And I guess it should be easy to troubleshoot if docker-relat

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Well, I'm going to build a new ISO and run BVT. As soon as they are green, I'm going to approve the change. On Tue, Feb 9, 2016 at 12:32 PM, Bogdan Dobrelya wrote: > On 08.02.2016 17:05, Igor Kalnitsky wrote: >> Hey Fuelers, >> >> When we are going to enable it? I think since HCF is passed for >>

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

On 08.02.2016 17:05, Igor Kalnitsky wrote: > Hey Fuelers, > > When we are going to enable it? I think since HCF is passed for > stable/8.0, it's time to enable task-based deployment for master > branch. > > Opinion? This must be done for the 9.0, IMHO. > > - Igor > > On Wed, Feb 3, 2016 at 12

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Tue, Feb 9, 2016 at 11:58 AM, Alexander Kislitsky < akislit...@mirantis.com> wrote: > +1 > > On Tue, Feb 9, 2016 at 12:28 PM, Anastasia Urlapova < > aurlap...@mirantis.com> wrote: > >> +1 >> >> On Tue, Feb 9, 2016 at 11:51 AM, Evgeniy L wrote: >> >>> +1 >>> >>> On Mon, Feb 8, 2016 at 7:58

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Tue, Feb 9, 2016 at 12:28 PM, Anastasia Urlapova wrote: > +1 > > On Tue, Feb 9, 2016 at 11:51 AM, Evgeniy L wrote: > >> +1 >> >> On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < >> vkozhuka...@mirantis.com> wrote: >> >>> +1 to enable it ASAP. >>> >>> It will also affect our deploymen

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Tue, Feb 9, 2016 at 11:51 AM, Evgeniy L wrote: > +1 > > On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> +1 to enable it ASAP. >> >> It will also affect our deployment tests (~1 hour vs. ~2.5 hours). >> >> Vladimir Kozhukalov >> >> On Mon, Feb 8

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > +1 to enable it ASAP. > > It will also affect our deployment tests (~1 hour vs. ~2.5 hours). > > Vladimir Kozhukalov > > On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin > wrote: > >> +1. >> >> Regards, >>

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 to enable it ASAP. It will also affect our deployment tests (~1 hour vs. ~2.5 hours). Vladimir Kozhukalov On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin wrote: > +1. > > Regards, > Bulat Gaifullin > Mirantis Inc. > > > > > On 08 Feb 2016, at 19:05, Igor Kalnitsky > wrote: > > > > Hey Fuel

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1. Regards, Bulat Gaifullin Mirantis Inc. > On 08 Feb 2016, at 19:05, Igor Kalnitsky wrote: > > Hey Fuelers, > > When we are going to enable it? I think since HCF is passed for > stable/8.0, it's time to enable task-based deployment for master > branch. > > Opinion? > > - Igor > > On Wed

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

Hey Fuelers, When we are going to enable it? I think since HCF is passed for stable/8.0, it's time to enable task-based deployment for master branch. Opinion? - Igor On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya wrote: > On 02.02.2016 17:35, Alexey Shtokolov wrote: >> Hi Fuelers! >> >> As y

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

+1 Aleksey Kasatkin On Mon, Feb 8, 2016 at 12:04 PM, Tatyana Leontovich < tleontov...@mirantis.com> wrote: > +1 > > > > On Mon, Feb 8, 2016 at 11:54 AM, Igor Kalnitsky > wrote: > >> Hey Fuelers, >> >> I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. >> Fedor's doing good review

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

+1 On Mon, Feb 8, 2016 at 11:54 AM, Igor Kalnitsky wrote: > Hey Fuelers, > > I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. > Fedor's doing good review with detailed feedback [1], and has > contributes over 20 patches during Mitaka release cycle [2]. > > Fuel Cores, please rep

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

+1 Regards, Bulat Gaifullin Mirantis Inc. > On 08 Feb 2016, at 12:57, Evgeniy L wrote: > > +1 > > On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky > wrote: > Hey Fuelers, > > I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. > Fedor's doing good

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

+1 On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky wrote: > Hey Fuelers, > > I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. > Fedor's doing good review with detailed feedback [1], and has > contributes over 20 patches during Mitaka release cycle [2]. > > Fuel Cores, please reply

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Hi Simon. For running selected tasks on already deployed nodes you can use the following command of CLI (fuel command-line utility): fuel node --node node_id1[,node_idN] --tasks task1[,taskN] where node_id - is the unique identifier of node, where specified tasks shall be run. Any plan t

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

On Fri, Feb 5, 2016 at 1:54 PM, Igor Kalnitsky wrote: > Simon, > > > Nope, it doesn't work for me since it should run for *all* the nodes, > > irrespective of their roles. AFAIK update_required doesn't support '*'. > > If your plugin provides a new node role as well as additional tasks > for othe

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Simon, > Nope, it doesn't work for me since it should run for *all* the nodes, > irrespective of their roles. AFAIK update_required doesn't support '*'. If your plugin provides a new node role as well as additional tasks for other node roles, you may try to workaround that by using reexecute_o

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Simon, >> Any plan to have a nicer experience in future Fuel releases? I haven't heard about any plans on improvements for that, but management team should know better whether it's on roadmap or not. Thanks, On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier wrote: > Thanks Evgeniy. > > On Fri, F

<    2   3   4   5   6   7   8   9   10   11   >