Re: [openstack-dev] [fuel][plugin] Is there a way to change plugin html dynamically?

Hi Peter, there are two ways I see today to have done what you want to: First, you can change [0] and add some fields to store second netapp device. In this case you'll need to change puppet manifests logic to use new fields - according to current state, it's a bunch of code double or you'll

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

Hi Vladimir, I see one big problem here - people who have expert skills in one area (for example, in fuel-library puppet manifests and their logic) will have ability to set +2 and workflow +1 to reviews in other areas (for example, in fuel-astute) where they don't have good expertise. It can lead

Re: [openstack-dev] [fuel] Propose Denis Egorenko for fuel-library core

+1 On Thu, Aug 25, 2016 at 12:08 PM, Aleksandr Didenko wrote: > +1 > > On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko > wrote: > >> +1 >> >> >> /sv >> >> >> >> __ >>

Re: [openstack-dev] [Fuel] Failed to install fuel master

. > (I tried this process for ubuntu-server.iso and it worked correctly). > > Regards, > > On 7 July 2016 at 09:54, Stanislaw Bogatkin <sbogat...@mirantis.com> > wrote: > >> Hi guys, >> >> could you tell which way you used to write ISO to the

Re: [openstack-dev] [Fuel] Failed to install fuel master

Hi guys, could you tell which way you used to write ISO to the USB stick? On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan wrote: > I'm pretty sure this is a USB stick install as I've seen the same failure > on Fuel-8.0. Basically, the installer is not able to find the

[openstack-dev] [Fuel] YAQL console for master node

Hi all, as you maybe know, new conditions for Fuel tasks were recently (in master and mitaka branches) introduced. Right after this I got several questions like 'hey, how can I check my new condition?' Answer could be 'use standard yaql console', but it hasn't have Fuel internal yaql functions

[openstack-dev] [Fuel] Broken plugins.

Hi guys, if you develop or testing Fuel plugins with current Fuel master ISOs - be aware that with last changes into Fuel tasks serialize system plugins are currently broken. There is a patch [0] which partially fixes this from nailgun side and I am working on library part of it. I believe that

[openstack-dev] [Fuel] Broken plugins.

Hi guys, if you develop or testing Fuel plugins with current Fuel master ISOs - be aware that with last changes into Fuel tasks serialize system plugins are currently broken. There is a patch [0] which partially fixes this from nailgun side and I am working on library part of it. I believe that

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

+1 to maintain example plugins. It is easy enough and really lowering barriers for people who just begin create plugins. On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn wrote: > Igor, > > It seems you are proposing an IKEA approach to plugins. Take Fuel's > example

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

Can we drop this >>>> feature? >>>> > or should we finish implementation of this feature. >>>> > >>>> > >>>> > Regards, >>>> > Bulat Gaifullin >>>> > Mirantis Inc. >>>> > >>&g

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] 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][Bugs] Time sync problem when testing.

Yes, I have created custom iso with debug output. It didn't help, so another one with strace was created. On Jan 27, 2016 00:56, "Alex Schultz" <aschu...@mirantis.com> wrote: > On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin > <sbogat...@mirantis.com> wrote: >

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

Malchuk <mmalc...@mirantis.com> wrote: > I think we shouldn't depend on the other services like Syslog and logger > trying to catch the problem and it is better to create the logs ourselves. > > > On Wed, Jan 27, 2016 at 1:49 PM, Stanislaw Bogatkin < > sbogat...@mirantis.c

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

output redirection to the log-file directly. > > > On Wed, Jan 27, 2016 at 11:21 AM, Stanislaw Bogatkin < > sbogat...@mirantis.com> wrote: > >> Yes, I have created custom iso with debug output. It didn't help, so >> another one with strace was created. >> On

[openstack-dev] [Fuel][Bugs] Time sync problem when testing.

Hi guys, for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of time, but breaks our BVT and swarm tests. There is no exact point where problem root located. To better understand this, some verbosity to ntpdate output was added but in logs we can see only that packet exchange

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

a real clock onboard. On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com> wrote: > On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin > <sbogat...@mirantis.com> wrote: > > Hi guys, > > > > for some time we have a bug [0] with ntpdate. It d

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

+1 to Andrew. Plugins created for run some code and plugin verification is the source of trust there. On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward wrote: > I'd have to say that this is expected behavior. I'm not sure what you > would hope to prohibit when these kinds of

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

k.org/#/c/243340 >> >> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov <dnikis...@mirantis.com> >> wrote: >> >>> Stanislaw, >>> >>> proposing patches could be a viable option long-term, however, by the >>> time these patches will mak

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

> What if you're not sure how the improved code should look like, but > you definitely sure that it shouldn't look like proposed one? :) I believe you should ask other people if you are right, as set '-1' to code that you cannot improve is not the best option, so > If you are not sure how the

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

before each retrigger of > deployment test. > > Hope this answers your question. > > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com > > On 20 Nov 2015, at 13:57, Stanislaw Bogatkin <sbogat...@mirantis.com> > wrote: > > Hi Igor, > &g

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

Hi Igor, would you be so kind tell, why fuel-library deployment tests doesn't support this? Maybe there is a link with previous talks about it? On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov wrote: > Hi, > > I’d like to inform you that all jobs running on Fuel CI (with

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

/github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326 > > On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin < > sbogat...@mirantis.com> wrote: > >> Dmitry, I mean whole feature. >> Btw, why do you want to grant capabilities via puppet? It should be do

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Another option would be to have a fine-grained control only on Fuel > services and leave all the other at their defaults. > > On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin < > sbogat...@mirantis.com> wrote: > >> Dmitry, I just propose the way I think is right,

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

gt; user, it should be created in the fuel-nailgun package. >>>>>>> I think it makes the most sense to create multiple users, one for >>>>>>> each service. >>>>>>> >>>>>>> Lastly, it makes a lot of sense to tie a "

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

+1 to remove containers On Fri, Nov 20, 2015 at 12:29 AM, Thomas Goirand wrote: > On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote: > > Anyway, the idea is to get > > rid of Docker containers on the master node and switch to plane package > > based approach that we used

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

nislaw, >>>>> >>>>> I agree that this approch would work well. However, does Puppet allow >>>>> managing capabilities and/or file ACLs? Or can they be easily set up when >>>>> installing RPM package? (is there a way to specify capabilities/ACLs in

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

reement on the implementation so that there's >> going to be a some kinf of compatibility during upgrades. >> >> Stanislaw, >> Do I understand correctly that you propose using something like sucap to >> launch from root, switch to a different user and then drop

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

I think that it is excellent thought. +1 On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin wrote: > Folks > > I wanted to raise awareness about one of the things I captured while doing > reviews recently - we are sacrificing quality to bugfixing and feature > development

Re: [openstack-dev] [fuel] Using upstream packages & modules

Hi Simon, using 'include' in HAProxy is damn conveniently, I don't think it should die. There is just one way I know to use haproxy with several different conf's - to construct looong command line with all of them - and it's really inconvenient. On Tue, Nov 10, 2015 at 12:20 PM, Simon

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

Bartolomiej, it's customer-related patches, they, I think, have to be done for 6.1 prior to 8+ release. Dmitry, it's nice to hear about it. Did you consider to use linux capabilities on fuel-related processes instead of just using non-extended POSIX privileged/non-privileged permission checks?

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

I spoken with Sergii about this and prepared a patch for get rid of SecurityWarning [0] - it was easy. But we can't get rid from InsecurePlatformWarning so easy way. I see next options: 1. Update python version as [1] said - should be hard task 2. Downgrade urllib version to one without such

Re: [openstack-dev] [Fuel] SSL keys saving

, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key: a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate

[openstack-dev] [Fuel] SSL keys saving

Hi folks. Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key: a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate private key, csr and crt in a pre-deployment hook on master

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

and release notes (cause if someone will decide to force HTTPS, he must to upgrade fuel-nailgun-client on all old nodes too). On Tue, Aug 4, 2015 at 5:05 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Seems that second solution is okay. Sebastian, I'll try to fix it before SCF. On Tue, Aug 4

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

Hi guys, in overall movement of Fuel to use secure sockets we think about wrapping master node UI and API calls to SSL. But there are next caveat: a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a little. But if it will be rewritten in 7.0 and HTTPS on master node will be

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

SSL. But probably for UI we will have to perform redirect on JS level. Thanks, On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi guys, in overall movement of Fuel to use secure sockets we think about wrapping master node UI and API calls to SSL

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

+1 On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com wrote: +1 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: At the moment we have several core reviewers for the fuel-main project. Roman Vyalov is responsible for merging of

Re: [openstack-dev] [Fuel] SSL feature status

Hi, we have a spec that says we disable SSL by default and it was successfully merged with that, no one was against such decision. So, if we want to enable it by default now - we can. It should be done as a part of our usual process, I think - I'll create a bug for it and fix it. Current status

Re: [openstack-dev] [Fuel Zabbix in deployment tasks

Actually, I didn't participate in that process a lot - just reviewed plugin couple of times and as I know, we had had a commits that deleted zabbix from current Fuel. There is bug about that: https://bugs.launchpad.net/fuel/+bug/1455664 There is a review: https://review.openstack.org/#/c/182615/

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

2 weeks seems too small for me. We easy can be in situation when fix for medium bug is done, but SCF starts. And gap between SCF and release easily can be more than a month. So, 2 months seems okay for me if speaking about forcibly applying auto-abandon by major vote. And I'm personally against

Re: [openstack-dev] [Fuel] wrong network for keystone endpoint in 6.1 ?

Hi Daniel, answer is no - actually there is no strong dependency between public and internal/admin endpoints. In your case keystone client ask keystone on address 10.52.71.39 (which, I think, was provided by system variable OS_AUTH_URL), auth on it and then keystone give endpoints list to client.

Re: [openstack-dev] [Fuel] LBaaS in version 5.1

easily ignore the controller HA (LBaaS doesn't support HA :) ) and just go the standard LBaaS? On Wed, May 6, 2015 at 2:55 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi Daniel, Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system was introduced and LBaaS

Re: [openstack-dev] [Fuel] LBaaS in version 5.1

Hi Daniel, Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system was introduced and LBaaS plugin was created. So, I think than docs about it never existed for 5.1. But as I know, you can easily install LBaaS in 5.1 (it should be shipped in our repos) and configure it with

Re: [openstack-dev] [Fuel] glusterfs plugin

Hi Przemyslaw, I would be glad to be core reviewer to fuel-plugin-glusterfs as long as seems than I was only one person who push some commits to it. On Thu, Apr 2, 2015 at 10:47 AM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: Since there is no reply here I have taken steps to become core

Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

+1 On Wed, Mar 25, 2015 at 10:10 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent

[openstack-dev] [Fuel] Stop distributing IMG artifact and start using hybrid ISO.

Hi everyone, we have merged code that will create hybrid ISO. Current 6.1 #147 ISO already can be booted from USB by standard method (just using dd of=/path/to/iso of=/path/to/usb/stick). Creating IMG artifact will be disabled soon, so, please, be aware of it.

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Hi. I'm vote for second option, cause if we will want to implement some unified hierarchy (like Fuel as CA for keys on controllers for different env's) then it will fit better than other options. If we implement 3rd option then we will reinvent the wheel with SSL in future. Bare rsync as storage

Re: [openstack-dev] [Fuel] removing single mode

+1 On Tue, Jan 27, 2015 at 4:05 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, After starting implementing granular deployment we've faced a bunch of issues that would make further development of this feature much more complicated if we have to support both Simple and HA deployment

[openstack-dev] [FUEL] Bootstrap NTP sync.

Hi guys, We have a little concern related to Fuel bootstrap node NTP sync. Currently we trying to sync time on bootstrap node with master node, but problem is that NTP protocol has long convergence time, so if we just install master node and right after that try to start some bootstrap node -

Re: [openstack-dev] [FUEL] Bootstrap NTP sync.

, cause some of followed tasks depends on synced time. On Fri, Dec 19, 2014 at 2:12 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 19 Dec 2014, at 10:00, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi guys, We have a little concern related to Fuel bootstrap node NTP sync

Re: [openstack-dev] [Fuel] fuel master monitoring

Hi all, As I understand, we just need to monitoring one node - Fuel master. For slave nodes we already have a solution - zabbix. So, in that case why we need some complicated stuff like monasca? Let's use something small, like monit or sensu. On Mon, Nov 24, 2014 at 10:36 PM, Fox, Kevin M

Re: [openstack-dev] [Fuel] fuel master monitoring

As for me - zabbix is overkill for one node. Zabbix Server + Agent + Frontend + DB + HTTP server, and all of it for one node? Why not use something that was developed for monitoring one node, doesn't have many deps and work out of the box? Not necessarily Monit, but something similar. On Wed, Nov

[openstack-dev] [Fuel] NTP settings.

Hi all, Today we have a next workflow about NTP in Fuel: 1. When someone deploy a master node, we need to somehow operate with NTP and set upstream NTP servers to Fuel NTP daemon on master node. 2. NTP will enabled by default and set to default upstream values (from ntp.org pool). 3. If user will

[openstack-dev] [FUEL] Re: SSL in Fuel.

I think that if we have 3 blueprints that realises some SSL stuff around themselves then we can discuss it here. My vision about SSL in Fuel split into 3 parts: A) We need to implement [1] blueprint, cause it is only one way to generate certificates. How i see that: 1.0 We sync puppet-openssl