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

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,

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

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:

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

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

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

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

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

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

Hey folks, I'm glad to announce that Fuel CI for puppet-openstack modules is live and running in it's initial stage, you can look at the builds here[0]. It's running in silent mode now to allow us to gather some results and ensure that everything is running stable, so you won't see any

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

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 >

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

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,

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

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

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,

[openstack-dev] [Fuel] Wildcards instead of

Hello, We are about to switch to wildcards instead of listing all groups in tasks explicitly [0]. This change must make deployment process more obvious for developers. However, it might lead to confusion when new groups are added either by plugin or fuel team in future. As mention by Bogdan, it

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

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

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

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/

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

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

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

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

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

Hi, Apparently, nailgun assumes that lvm metadata size is always set to 64M [1] It seems that it was defined here since the early beginning of nailgun as a project, therefore it's impossible to figure out for what purposes that was done as early commit messages are not so informative. According

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

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

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

Fuel core reviewers, Fuel CI is being migrated to an ISO image with Mitaka packages, please don't merge any commits to any Fuel repositories without coordination with Aleksandra until further notice. This merge freeze is expected to last a few hours. -- Dmitry Borodaenko

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

> 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 hash definitions/merges and use >

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

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

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

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 things into a special define called `wait_for_backend`.

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

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

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

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

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

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

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

[openstack-dev] [Fuel][QA] New runner for fuel-qa system tests

Hi all! Please be informed that we merged a new runner for fuel-qa system tests [1] : run_system_test.py Features of new runner: - auto discovering all test in both test suites ([2] and [3]) - show the groups from the test suites - explain content of groups - run the several groups at the same

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

Dear colleagues, I'd like to announce that we are next to moving fuel-main/virtualbox directory to a separate git repository. This directory contains a set of bash scripts that could be used to easily deploy Fuel environment and try to deploy OpenStack cluster using Fuel. Virtualbox is used as a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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.

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

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

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

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

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.

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

Right now master (targeting 9.0) is still deploying liberty and there is active work going on to support both Kilo and Mitaka. On the review queue are changes that would make fuel-library in-compatible with the prior (liberty) openstack release. However I think if we extend a little bit of effort

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

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

Fuelers, We are discussing the idea to extend the multi release packages for plugins. Fuel plugin builder (FPB) can create one rpm-package for all supported releases (from metadata.yaml) but we can specify only deployment scripts and repositories per release. Current release definition (in

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

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

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

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

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:

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

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

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

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

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

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

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-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Hi all! To run system tests on CI on a daily basis using baremetal servers instead of VMs, Fuel admin node also should be bootstrapped. There is no a simple way to mount an ISO with Fuel as a CDROM or USB device to a baremetal server, so we choose the provisioning with PXE. It could be done in

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

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

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

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

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

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

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

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

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

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

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 back with +1/-1. - igor [1]

<    4   5   6   7   8   9   10   11   12   13   >