Re: [Openstack] help - Fuel Community 11 - PXE

I'm not sure if these options should be set, because they are required only if PXE server is on different host from DHCP server, which is not the case for Fuel. On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle <kho...@developingsolutions.com> wrote: > Evgeniy L: > > > > Thank yo

Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

r: uppercase=bad) > ||/ Name Version > Architecture Description > +++-==-- > -=== > === > ii fuel-ha-utils

Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

Hi, fuel_pkgs/9 means that "fuel_pkgs" task failed on node with id 9, find the node with this id using "fuel node" (run it from Fuel node), ssh to the nodes and look for errors in /var/log/puppet.log. If Nova service was running before, it should be running even after fuel_pkgs task failed on

Re: [Openstack] help - Fuel Community 11 - PXE

Hi Ken, Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot, if the issue is hardware specific, you can try to search if anybody else had such problems with DNSMasq PXE boot and similar hardware. Thanks, On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle

Re: [Openstack] Mirantis - Fuel 9.2 Failed Deployment

/util/execution.rb:186:in `execute' >>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_update]) >>>>> /usr/lib/ruby/vendor_ruby/puppet/util/execution.rb:186:in `waitpid2' >>>>> 2017-10-24 17:13:43ERR(/Stage[main]/Apt::Update/Exec[apt_upda

Re: [Openstack] Mirantis - Fuel 9.2 Failed Deployment

Hi, Yes, execution expired, means that it could not build an image within required period of time. The message you see can be used to build an image (copy paste into console "command"), also there is a file with logs /var/log/fuel-agent-env-1.log, which you can use to try to identify where the

Re: [Openstack] [Fuel] Danube Fuel 10 compute node base system partition size

Hi Jim, It's possible to change the amount of space required for base system, but it will require to change partitioning schema in release model. You can retrieve it from Nailgun using: curl -H "X-Auth-Token: $(fuel token)" http://172.29.194.19:8000/api/v1/releases// | python -m json.tool >

Re: [Openstack] Help needed with migrating Fuel server

Hi, Try following this guide: https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master Thanks, On Sun, Sep 24, 2017 at 11:57 PM, Raja T Nair wrote: > Hello All, > > Can somebody help me with info on how to migrate OR

Re: [Openstack] [Fuel] Fuel 11 does not boot into setup menu, does not install successfully

Hi, I've never tried installing 11 version, but this looks suspicious: fuelmenu=10.0.0 I think it should be version 11, not 10. Thanks, On Thu, Sep 21, 2017 at 9:30 AM, Tomas Brännström < tomas.a.brannst...@tieto.com> wrote: > Hi > I'm trying to install the Fuel 11 release in a Virtualbox VM,

Re: [Openstack] Mirantis Fuel 9.2 - nailgund not available when attempting to save changes to cloud environment

r. > > I checked all of the logs in /var/log/nailgun and none of them indicate > any errors that I can see. There are also plenty of nailgun related > processes running on the Fuel server. > > On 04/05/2017 10:14 AM, Evgeniy L wrote: > >> Hi, >> >> Coul

Re: [Openstack] Fuel Reset Environment Never works

Hi, Could you please elaborate on the issue? What do you see after reset? How does consequent deployment fail? Thanks, On Tue, Apr 4, 2017 at 10:32 PM, Waqas Riaz wrote: > Hi, > > Does anyone know why Fuel's Reset Environment feature never works? > The deployment after

Re: [Openstack] Mirantis Fuel 9.2 - nailgund not available when attempting to save changes to cloud environment

Hi, Could you please clarify, do you receive this error in the UI? What do you mean by "save any changes"? I'm not sure if ranges can cause such behavior, please see logs "/var/log/nailgun/app.log" and "/var/log/nailgun/api.log" for any errors/python tracebacks. Thanks, On Mon, Apr 3, 2017 at

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

ore thing can we add more services to already added nodes? > > Or we have to scale down add services and again scale up? > > On Mar 30, 2017 9:12 PM, "Evgeniy L" <e...@mirantis.com> wrote: > >> The repository contains packages important for OpenStack installation, as &

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

src 192.168.0.5* >> *192.168.1.0/24 <http://192.168.1.0/24> dev br-storage proto kernel >> scope link src 192.168.1.3* >> >> Default route goes to br-mgmt which is tagged vlan and does not go to >> internet. Public interface does not come up for compute node whe

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

gt; `sync_if_needed'* >> >> *2017-03-27 17:18:57 ERR >> /usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:204:in >> `sync'* >> >> *2017-03-27 17:18:57 ERR >> /usr/lib/ruby/vendor_ruby/puppet/property.rb:581:in `sync'* >> >> *2017

Re: [Openstack] [Fuel] - OpenStack installation using Fuel Error!!!Task[netconfig/21] Stopping the deployment process

Hi, *netconfig* task is responsible for network configuration. *21* - specifies a node id, where task failed, use `fuel node | grep 21` to find ip address of the node, go to the node using ssh and see results of puppet execution "/var/log/puppet.log". Thanks, On Mon, Mar 27, 2017 at 7:56 AM,

Re: [Openstack] [Fuel] Unable to provision Compute node

Hi, There is a parameter reboot_timeout in /etc/astute/astuted.conf file on Fuel node. But there were some changes in provisioning process in latest versions, so I'm not 100% sure that it will help. Thanks, On Fri, Mar 17, 2017 at 8:33 AM, Vimal Kumar wrote: > 2017-03-17

Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

ery limited by my remote-access > technology in terms of copy-pasting things. If you really need additional > feedback, I'll do my best to give you the full output) > > > Regards > -- > *De :* Evgeniy L <e...@mirantis.com> > *Envoyé :* 10 f

Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

sion.) > > After that, rebuild the new bootstrap and environment images, then driver > successfully updated. > > Thanks for the advice, really appreciate! > > Eddie. > > 2017-02-11 6:25 GMT+08:00 Evgeniy L <e...@mirantis.com>: > >> You have several opti

Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

gt; > WSGIProcessGroup cobbler_web > > WSGIPassAuthorization On > > > At this point, I am rather clueless and am starting to wonder if I am not > breaking the OS further by stabbing in the dark. I wonder if this is > leading anywhere, or whether I should just restart the Fuel

Re: [Openstack] [Fuel] How to manage Puppet manifests, data

Hi Gregory, What version of Fuel do you use? I'm not that familiar with openstack puppet library, can help only with last question, you can override parameters using fuel Nailgun extension which allows to override settings generated by Nailgun [1], these changes can be applied by redeploying the

Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

e > into a repository that inside a Fuel Master node. And add package name into > the installation list so that DKMS module will install during bootstrap > image or environment image build. > > Is that feasible? > > Thanks, > Eddie. > > 2017-02-08 2:18 GMT+08:00 Evge

Re: [Openstack] [OpenStack] [Fuel] Packing kernel drivers into target image.

Hi, Bootstrap image is used only when node is in discovery state (before provisioning is done), when you send nodes for provisioning, Fuel builds an image using repository from environment configuration, after the image is built, it reuses it for future deployments you can find details in

Re: [Openstack] [Fuel] Cannot access Fuel 10.0 UI because of unavailable Nailgun server

Hi, Try to access UI using "curl" from your machine and from Fuel Master: 1. If it's not available from your machine but available from Fuel Master, make sure that your network is configured correctly use regular troubleshooting techniques for that ping/traceroute/tcpdump. 2. If it's not

Re: [Openstack] [Fuel] Questions Around Error Handling In Fuel

Hi Russel, Sorry for late response, there are different types of errors in 8.0 Fuel (nodes->error_type field in db), if error caused by provisioning, those nodes which have state=error, error_type=provision, will be re-provisioned, with possible data lose, those node which failed to deploy

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

+1 to Lukasz. -1 to the proposal, we had it this way for a quite some time, and it was not good for the project (as Lukasz pointed out), why should a person who merges the code to the library have an access to merge the code to Nailgun/Astute without proper expertise. Those are different areas

Re: [openstack-dev] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

Hi Dmitry, It depends, but usually it takes half of working time to do reviews, I'm not sure if we can assume 25-30%, also finding a good reviewer usually is much harder than a person who can write the code, so it would be much more productive to encourage people to spend as much time as they can

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

Hi Irina, I fully support the idea of creating separate launchpad project for each plugin, because plugins have different release cycles and different teams who support them. Fuel Plugin documentation [2] has to be updated with information for plugin developers (how to setup new project) and for

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

> necessary to merge such custom things into Ironic tree. Happily, Ironic > is > > smart enough to consume drivers using stevedore. About ironic-inspector > > the case is the same. Whether we are going to run it inside 'user > instance' > > or inside ramdisk it does not affect

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

ecause Shotgun is a generic > tool. Please review these [1], [2]. > > [1] https://review.openstack.org/#/c/298603 > [2] https://review.openstack.org/#/c/298615 > > > Btw, one of the ideas was to use Fuel task capabilities > to gather diagnostic snapshot. > > Vladimir Koz

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

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Problems which I see with current Shotgun are: 1. Luck of parallelism, so it's not going to fetch data fast enough from medium/big clouds. 2. There should be an easy way to run it manually (it's possible, but there is no ready-to-use config), it would be really helpful in case if

Re: [openstack-dev] [fuel] Component Leads Elections

Hi, I'm not sure if it's a right place to continue this discussion, but if there are doubts that such role is needed, we should not wait for another half a year to drop it. Also I'm not sure if a single engineer (or two engineers) can handle majority of upcoming patches + specs + meetings around

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

Hi Roman, >> reasonable to just install it from PyPi (first we need to release Nailgun to PyPi) Yes there will be dependencies, but there should be a way to test core extensions (those which go to standard Fuel build) from master (or any other branch), so installing from pypi is not always an

[openstack-dev] [Fuel][Bareon][Ironic] The future of integration module

Hi, I would like to bring up discussion on Bareon [0] and Ironic integration and plans for the future. But first let me provide background information on the topic. Bareon is partitioning/provisioning system [1] which is based on Fuel-agent [2], currently it's in active development and will be

[openstack-dev] [Bareon] Weekly update

Hi, here is a weekly update from Bareon team. 1. Extensions testing procedure in Fuel (required for Bareon integration). 1.1. Spec is still in progress [0]. 1.2. Email was sent [1] to figure out the best way to do it in OpenStack Infra, we would appreciate for any help on that. 2. Bareon dynamic

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

On Thu, Mar 17, 2016 at 3:16 PM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 03/16/2016 01:39 PM, Evgeniy L wrote: > >> Hi Dmitry, >> >> I can try to provide you description on what current Nailgun agent is, >> and what are potential requirements

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

Hi Dmitry, I can try to provide you description on what current Nailgun agent is, and what are potential requirements we may need from HW discovery system. Nailgun agent is a one-file Ruby script [0] which is periodically run under cron. It collects information about HW using ohai [1], plus it

[openstack-dev] [Fuel] Plans on networking modularisation

Hi, We've been working on networking modularisation, during this activity Nailgun is being fixed [0] in order to provide better layer boundary between network related code and the rest of the system. The purpose of this email is: 1. To make sure that this activity is known in Fuel team. 2. To

Re: [openstack-dev] [Fuel] Rewriting nailgun agent on Python proposal

Hi Alexander, thanks for bringing this up. >From your list of problems the only problem which I see is 1st, 2nd and 3rd are solvable even with current implementation. Also I don't think that we should continue developing our own HW discovery mechanism, we should consider switching to

Re: [openstack-dev] [Bareon] Weekly update

On Mon, Mar 14, 2016 at 6:53 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, here is update from Bareon team. > 1. The team was actively helping with reviews/debugging/triage/designs for > Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the > code is merged [7],

[openstack-dev] [Bareon] Weekly update

Hi, here is update from Bareon team. 1. The team was actively helping with reviews/debugging/triage/designs for Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the code is merged [7], also bug is fixed [8].3. Extensions testing procedure spec is still in progress [9].4. Dynamic

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, thanks for clarification. On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov wrote: > Thank you for comments folks. > Clarifications, with the feedback incorporated: > 1) We can install plugin developed against 8 to Fuel Mitaka (9). But it > won't appear in the

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

Hi, +1, it's very hard to use current representation of logs for debugging, everybody goes to the node and tries to find required logs, instead of reimplementing debugging friendly tool it would be better to get something ready to use on the master. Thanks, On Fri, Mar 11, 2016 at 12:05 PM,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

ramework for every change to the framework, so that we can > have > > -1 right away if something goes wrong. > > > > I've started separate thread on general thoughts about backward > > compatibility and multiple releases support, which actually affects > > examples: [1

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, comments are inline. On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov wrote: > Hi folks, > in order to make a decision whether we need to support example plugins, > and if actually need them [1], I'd suggest to discuss more common things > about plugins. > >

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

coverage? > > On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "templates" the plugin which is create by just "fpb >> --create plugin-name"? >> It doesn't cover enough, package inst

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Ilya, What do you mean by "templates" the plugin which is create by just "fpb --create plugin-name"? It doesn't cover enough, package installation and all range of tasks executions. Thanks, On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote: > Igor, i completely agree,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Hi, Plugin examples mustn't be removed, those plugins are part of integration tests for fuel plugin builder, which should be able to build any version of plugin. So there are two ways to solve the problem: 1. Before test run update compatibility matrix for plugins automatically. 2. Continue

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

Hi, Thank you for your work, really happy to see it done. So as far as I can see from now on in fuel-web repository we have only Nailgun project. Is it correct? On Fri, Feb 26, 2016 at 3:53 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > We are ready for moving

Re: [openstack-dev] [Fuel][Solar] Integration in 9.0

Hi Jedrzej, >> Maybe instead blueprint in 1st step should we create full blown fuel-spec? If there is anything to be discussed in implementation, or there are different options to do it, it's better to have blueprint and spec, so everybody will be able to see what the integration looks like.

Re: [openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

dae...@mirantis.com > wrote: > If the spec is not going to require code changes in 9.0/Mitaka, why not > simply target it for 10.0/Newton? > > On Thu, Feb 25, 2016 at 05:21:55PM +0300, Evgeniy L wrote: > > Hi, > > > > We have a spec where we are trying to do research and d

[openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

Hi, We have a spec where we are trying to do research and describe how we are going to test extensions [0], we will not be able to land it before feature freeze, so should we get feature freeze exception for it? Or it will not be a problem to merge it even after FF? The spec itself is more about

[openstack-dev] [Bareon] Weekly update

Hi, Here is weekly update from Bareon team. 1. 3 specs from Cray team were merged [0], roadmap was properly adjusted [1] 2. Changing deployment data using extensions in Nailgun [2], spec is merged, code is on review [3] 3. Extensions testing procedure, spec is in progress [4] 4. Dynamic

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

[openstack-dev] [Bareon] Weekly update

Hi, After the discussion with some folks, we agreed that it might be useful for the community to start sending weekly updates on what Bareon team is working on and what is our progress. So here is a first weekly update from Bareon team. 1. Data pipelines for Nailgun integration (changing

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

ould you please clarify what multi-package is? Thanks, On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "d

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

ve some things which are related to the deployment specified in the root and some in specific release. There is consistent mechanism to specify such kind of things, lets just use it. Thanks, On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb

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][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 <e...@mirantis.com> wrote: > Hi, > > As an author of this part of pluggable architecture I can shade more light > on why it was implemented this way and w

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

[openstack-dev] [Bareon][Fuel] Best practises on syncing patches between repositories

Hi, Some time ago we started Bareon project [1], and now we have some fixes landed to fuel-agent only, the question is what are the best practises on keeping two repos in sync with possibility to resolve conflicts manually? Cherry-picking patches manually doesn't look like the most error prone

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

om> wrote: > Thanks Evgeniy. > > On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L <e...@mirantis.com> wrote: > >> Hi Simon, >> >> As far as I know it's expected behaviour (at least for the current >> release), and it's expected that user reruns deployment on requir

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

Hi Simon, As far as I know it's expected behaviour (at least for the current release), and it's expected that user reruns deployment on required nodes using fuel cli, in order to install plugin on a live environment. It depends on specific role, but "update_required" field may help you, it can be

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi, In addition I've generated several examples in order to show how current prototype allocates the volumes [0]. Thanks, [0] http://bareon-allocator.readthedocs.org/en/latest/examples.html On Wed, Jan 13, 2016 at 2:14 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi Artur, > >

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

allocate a single volume on ssd and hdd > > > Best regards, > Svechnikov Artur > > On Tue, Jan 12, 2016 at 9:37 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Hi, >> >> For the last several weeks I've been working on algorithm (and prototype) >> for dyna

[openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi, For the last several weeks I've been working on algorithm (and prototype) for dynamic allocation of volumes on disks. I have some results [0] and would like to ask you to review it and provide some feedback. Our plan is to implement it as an external driver for Bareon [1]. Thanks, [0]

Re: [openstack-dev] [fuel] github can't sync with git because of big uploading

Hi, You should probably talk to infra team on this issue #openstack-infra channel. I see several ways what can be done here: 1. recreate the repo 2. create a repo with different name Also there is possibility to remove from the commit those files and push using --force, but it's a very bad

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

te: > >> I agree with Evgeny: from work organization it would more optimal to have >> 2 repos. API and system facing programming are completely different >> domains, requiring different skill sets. In my opinion separation would >> lower the entry barriers. >> >>

Re: [openstack-dev] [Fuel] Removal of support for nova-network

Hi, We mustn't touch Nailgun's logic, otherwise after upgrade user won't be able to manage her/his old nova Cluster. So lets just remove it from UI. Also as far as I know we should provide a way to manage old clusters not for a release, but for a couple of years. Thanks, On Tue, Dec 22, 2015 at

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

ro' having ConfigDB separate from Solar is that it will > simplify transition from current Fuel architecture by breaking it into more > definite stages and reducing the number of components Solar have to be > integrated with. > > -- > Best regards, > Oleg Gelbukh > > On Wed, Dec 16, 20

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

> > The point is that for Solar integration, we still need integration points, > and the less of them we have, the more simple the transition is going to > be.. > As described above, there will be a single integration point, data processor. > > -- > Best regards, > Ole

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

Hi Andrew, It doesn't look fair at all to say that we use Postgres specific feature for no reasons or as you said "just because we want". For example we used Arrays which fits pretty well for our roles usage, which improved readability and performance. Or try to fit into relational system

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

h additional efforts on fixing 2 >>> different environments. Let's just think from the point of development >>> velocity here and at delay such changes for at least after NY. Because if >>> we do it immediately after SCF there will be a whole bunch of holidays and >>> Russian hol

[openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

Hi, Some time ago, we’ve started a discussion [0] about Fuel modularisation activity. Due to unexpected circumstances POC has been delayed. Regarding to partitioning/provisioning system, we have POC with a demo [1] (thanks to Sylwester), which shows how the integration of Fuel and Bareon [2] can

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

Hi, Since older Postgres doesn't introduce bugs and it won't harm new features, I would vote for downgrade to 9.2 The reasons are: 1. not to support own package for Centos (as far as I know 9.3 for Ubuntu is already there) 2. should Fuel some day be a part of upstream Centos? If yes, or there is

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

y, and start production ready implementation > > For what reason do we need a separate repo? I thought API will be a > part of bareon repo. Or bareon is just a provisioning agent, which > will be driven by bareon-api? > > On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L <e...@mirantis.com>

[openstack-dev] [All][Bareon][Fuel][Ironic] New project: Bareon (provisioning system)

We are happy to introduce Bareon [0], which is a fork of fuel_agent [1] project which have been developed under Fuel’s umbrella. Bareon provides flexible and data driven interface to perform actions which are related to operating system installation. In contrary to standard kickstart and preseed

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

Hi Dmitry, I also don't think that we should duplicate the data in configdb, because in this case there will be +2 additional interfaces which will require to covert the data into configdb and after that from configdb to Solar, which seems redundant overhead. But we should be able to put the

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

+1 to Vladimir Kozhukalov, Entire point of moving branches creation to SCF was to perform such changes as early as possible in the release, I see no reasons to wait for HCF. Thanks, On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > -1 > > We already

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

+1 On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova wrote: > +1 > > On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov > wrote: > >> +1 >> >> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin > > wrote: >> >>> +1. >>> >>>

Re: [openstack-dev] [Fuel] Experimental Task Based Deployment Landed into Master

+1 It's really good job folks. On Sat, Dec 12, 2015 at 2:25 AM, Vladimir Kuklin wrote: > Fuelers > > I am thrilled to announce that task based deployment engine [0] has been > just merged into Fuel master. We checked it against existing BVT test cases > for regressions as

Re: [openstack-dev] [Fuel] Dropping Python 2.6

Hi Roman, We've discussed it [1], so +1 [1] https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility On Mon, Dec 14, 2015 at 5:05 PM, Roman Prykhodchenko wrote: > Fuelers, > > Since Mitaka OpenStack Infra has no resources to test python 2.6

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

com> wrote: > Hey folks, > > In an effort to do some housekeeping, I clean up the list of core > reviewers in Fuel. > > According to Stackalytics the following cores show a low contribution rate: > > # fuel-web [1] > > * Dmitry Shulyak > * Evgeniy L >

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

Hi, During Fuel master migration to CentOS7 there was found a problem that tests get failed [0] for python2.6 As far as I can see it's a common practise to drop python2.6 compatibility [1], shouldn't we switch tests to work with python2.7 instead of python2.6? It looks like fuelclient will be

Re: [openstack-dev] [Fuel] Patch size limit

Hi Maciej, thank you for bringing this up, +1, but we should discuss the limit, personally for me it's ok to review 400loc patches, if the patch covers only one bug-fix/feature implementation. So if everybody is agree, we should: 1. update contribution guide 2. create a task for *non-voting*

Re: [openstack-dev] [Fuel] Fuel Python Gerrit Dashboard

Thanks Igor, it's very helpful, Also if you forget where to get the link, use the documentation [1]. I think something like that may also be useful for library and QA team. Thanks, [1] https://wiki.openstack.org/wiki/Fuel#Development_related_links On Mon, Nov 30, 2015 at 3:29 PM, Igor

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

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?

Re: [openstack-dev] [Fuel] Master node upgrade

he containers (such as puppet >>>> manifest changes). There shouldn't be a need to back up the entire >>>> containers. >>>> >>>> The information we would lose would include the IP configuration >>>> interfaces besides the one used for the Fuel PXE

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

+1 to Dmitry, thanks for pushing this activity Vladimir. On Friday, 6 November 2015, Dmitry Pyzhov wrote: > Great job! We are much closer to removal of fuel-web repo. > > On Tue, Oct 27, 2015 at 7:35 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com >

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Javeria, In your case, I think it's easier to generate config on the target node, using puppet for example, since the information which you may need is placed in /etc/astute.yaml file. Also it may be a problem to retrieve all required information about the cluster, since API is protected with

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

onclusion. > > > -- > Javeria > > On Fri, Nov 6, 2015 at 1:41 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Javeria, >> >> In your case, I think it's easier to generate config on the target node, >> using puppet for example, since the information wh

Re: [openstack-dev] [Fuel] Master node upgrade

Hi Vladimir, Cannot say anything about 1st option, which is to use official Centos scripts, because I'm not familiar with the procedure, but since our installation is not really Centos, I have doubts that it's going to work correctly. 2nd option looks less risky. Also we should decide when to

Re: [openstack-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'

Hi, I believe we don't have any VirtualBox specific hacks, especially in terms of database configuration. By "development env" Vitaly meant fake UI, when developer installs and configures the database by himself, without any iso images, so probably his db is configured correctly with utf-8. Also

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Hi Javeria, As far as I know there is no way to run the task on Fuel master host itself. Since MCollective is installed in the container and tasks get executed using MCollective, as a workaround you may try to ssh from the container to the host. Also I have several additional questions: 1. what

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

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

  1   2   3   >