Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

2016-05-25 Thread jason
Hi Aleksandr, Thanks for the examples! That will really help me a lot. On May 25, 2016 6:26 PM, "Aleksandr Didenko" wrote: > Hi, > > +1 to Igor. It should be easily doable via some sort of "watcher" script > (run it as a daemon or under cron), that script should: > > -

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

2016-05-25 Thread jason
Hi Igor, Thanks, and yes you got my point, my "automatically ", means after a new node has been discovered , the deployement process starts automatically. Cron may help, but what if I need more info to check if that new discovered node deserves to be a compute node or not? Can the cron script

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

2016-05-25 Thread Aleksandr Didenko
Hi, +1 to Igor. It should be easily doable via some sort of "watcher" script (run it as a daemon or under cron), that script should: - watch for new nodes in 'discover' state. CLI example: fuel nodes - assign new nodes to env with compute role. CLI example: fuel --env $ENV_ID node set --node

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

2016-05-25 Thread Igor Kalnitsky
Hey Jason, What do you mean by "automatically"? You need to assign "compute" role on that discovered node, and hit "Deploy Changes" button. If you really want to deploy any new discovered node automatically, I think you can create some automation script and put it under cron. Hope it helps,

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Simon Pasquier
Hi Adam, Maybe you want to look into network templates [1]? Although the documentation is a bit sparse, it allows you to define flexible network mappings. BR, Simon [1] https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates On Wed, May 25, 2016 at 10:26 AM,

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
Thanks Alex, will experiment with it once again although AFAIR it doesn't solve thing I'd like to do. I'll come later to you in case of any questions. On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko wrote: > Hey Adam, > > in Fuel we have the following option

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
Hey Adam, in Fuel we have the following option (checkbox) on Network Setting tab: Assign public network to all nodes When disabled, public network will be assigned to controllers only So if you uncheck it (by default it's unchecked) then public network and 'br-ex' will exist on controllers

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
Hello Alex, I have a question about the proposed changes. Is it possible to introduce new vlan and associated bridge only for controllers? I think about DMZ use case and possibility to expose public IPs/VIP and API endpoints on controllers on a completely separate L2 network (segment vlan/bridge)

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
Hi folks, we had to revert those changes [0] since it's impossible to propery handle two different netconfig tasks for multi-role nodes. So everything stays as it was before - we have single task 'netconfig' to configure network for all roles and you don't need to change anything in your plugins.

Re: [openstack-dev] [fuel] release version numbers: let's use semvers

2016-05-24 Thread Roman Prykhodchenko
The only thing I would like to mention here is that scripts for making automatic releases on PyPi using OpenStack Infra won’t work, if the version is not formatted according to semver. - romcheg > 24 трав. 2016 р. о 14:34 Igor Kalnitsky написав(ла): > > Hey Zigo, >

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

2016-05-24 Thread Aleksandr Didenko
Hi, thank you Stas, long awaited tool :) Using it right now on the latest Fuel-10.0, very helpful and saves a lot of time (switching between nodes to test yaql for different roles is super cool). Regards, Alex On Tue, May 24, 2016 at 12:50 PM, Stanislaw Bogatkin

Re: [openstack-dev] [fuel] release version numbers: let's use semvers

2016-05-24 Thread Igor Kalnitsky
Hey Zigo, In Python community there's a PEP-440 [1] that defines a versioning scheme. The thing you should know is, the PEP __is not__ compatible with semver, and it's totally fine to have two components version. So I don't think we should force version changes from two-components to

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-05-18 Thread Bogdan Dobrelya
On 05/17/2016 08:55 PM, Clint Byrum wrote: > I missed your reply originally, so sorry for the 2 week lag... > > Excerpts from Mike Bayer's message of 2016-04-30 15:14:05 -0500: >> >> On 04/30/2016 10:50 AM, Clint Byrum wrote: >>> Excerpts from Roman Podoliaka's message of 2016-04-29 12:04:49

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

2016-05-18 Thread Simon Pasquier
Hi Matthew, Thanks for the reply. On Tue, May 17, 2016 at 5:33 PM, Matthew Mosesohn wrote: > Hi Simon, > > For 8.0 and earlier, I would deploy ElasticSearch before deploy_end > and LMA collector after post_deploy_start > > Unfortunately this isn't possible because the

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-05-17 Thread Clint Byrum
I missed your reply originally, so sorry for the 2 week lag... Excerpts from Mike Bayer's message of 2016-04-30 15:14:05 -0500: > > On 04/30/2016 10:50 AM, Clint Byrum wrote: > > Excerpts from Roman Podoliaka's message of 2016-04-29 12:04:49 -0700: > >> > > > > I'm curious why you think setting

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-05-17 Thread Bogdan Dobrelya
On 04/22/2016 05:42 PM, Bogdan Dobrelya wrote: > [crossposting to openstack-operat...@lists.openstack.org] > > Hello. > I wrote this paper [0] to demonstrate an approach how we can leverage a > Jepsen framework for QA/CI/CD pipeline for OpenStack projects like Oslo > (DB) or Trove, Tooz DLM and

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

2016-05-17 Thread Matthew Mosesohn
Hi Simon, For 8.0 and earlier, I would deploy ElasticSearch before deploy_end and LMA collector after post_deploy_start For Mitaka and Newton releases, the task graph now skips dependencies that are not found for the role being processed. Now this "requires" dependency will work that previously

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

2016-05-17 Thread Simon Pasquier
I'm resurrecting this thread because I didn't manage to find a satisfying solution to deal with this issue. First let me provide more context on the use case. The Elasticsearch/Kibana and LMA collector plugins need to synchronize their deployment. Without too many details, here is the workflow

Re: [openstack-dev] [fuel][plugins][lma] Leveraging OpenStack logstash grok filters in StackLight?

2016-05-17 Thread Simon Pasquier
The short answer is no. StackLight is based on Heka for log processing and parsing. Heka itself uses Lua Parsing Expression Grammars [1]. For now the patterns are maintained in the LMA collector repository [2] but it's on our to-do list to have it available in a dedicated repo. One advantage of

Re: [openstack-dev] [Fuel] Fuel - Rack Scale Architecture integration

2016-05-13 Thread Vladimir Kozhukalov
Absolutely agree with Jay. Fuel is a community project. Please keep discussion public including technical details. Anyway, integration is welcome, please go ahead and create BP (btw, spec review request is the best place to discuss technical details). Vladimir Kozhukalov On Fri, May 13, 2016

Re: [openstack-dev] [Fuel] Fuel - Rack Scale Architecture integration

2016-05-13 Thread Jay Pipes
On 05/13/2016 07:26 AM, Andrian Noga wrote: Hi Deepti, We have already a vision about Fuel-UI implementation for RSA. I've replied already to you in private email. Let's continue this thread in private conversation. Please, no. Fuel is an OpenStack Big Tent project. The Fuel roadmap,

Re: [openstack-dev] [Fuel] Fuel - Rack Scale Architecture integration

2016-05-13 Thread Andrian Noga
Hi Deepti, We have already a vision about Fuel-UI implementation for RSA. I've replied already to you in private email. Let's continue this thread in private conversation. Regards, Andrian Noga Engineering Manager Partner Integration Team, Mirantis, Inc. +38 (066) 811-84-12 Skype: bigfoot_ua

Re: [openstack-dev] [fuel] switch to upstream haproxy module

2016-05-12 Thread Simon Pasquier
On Thu, May 12, 2016 at 6:13 PM, Alex Schultz wrote: > > > On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier > wrote: > >> First of all, I'm +1 on this. But as Matt says, it needs to take care of >> the plugins. >> A few examples I know of are the

Re: [openstack-dev] [fuel] switch to upstream haproxy module

2016-05-12 Thread Alex Schultz
On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier wrote: > First of all, I'm +1 on this. But as Matt says, it needs to take care of > the plugins. > A few examples I know of are the Zabbix plugin [1] and the LMA collector > plugin [2] that modify the HAProxy configuration

Re: [openstack-dev] [fuel] switch to upstream haproxy module

2016-05-12 Thread Simon Pasquier
First of all, I'm +1 on this. But as Matt says, it needs to take care of the plugins. A few examples I know of are the Zabbix plugin [1] and the LMA collector plugin [2] that modify the HAProxy configuration of the controller nodes. How could they work with your patch? Simon [1]

Re: [openstack-dev] [fuel] switch to upstream haproxy module

2016-05-12 Thread Alex Schultz
On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn wrote: > Hi Alex, > > Collapsing our haproxy tasks makes it a bit trickier for plugin > developers. We would still be able to control it via hiera, but it > means more effort for a plugin developer to run haproxy for a

Re: [openstack-dev] [fuel] switch to upstream haproxy module

2016-05-12 Thread Matthew Mosesohn
Hi Alex, Collapsing our haproxy tasks makes it a bit trickier for plugin developers. We would still be able to control it via hiera, but it means more effort for a plugin developer to run haproxy for a given set of services, but explicitly exclude all those it doesn't intend to run on a custom

Re: [openstack-dev] [fuel] [QA] running Fuel tests using nodepool

2016-05-10 Thread Spencer Krum
As a frequent tinc user I'd be interested to see the code you are using to manage tinc into doing this. Is that code available somewhere? On Tue, May 10, 2016, at 09:02 AM, Monty Taylor wrote: > On 05/10/2016 08:54 AM, Vladimir Eremin wrote: > > Hi, > > > > I've investigated status of nodepool

Re: [openstack-dev] [fuel] [QA] running Fuel tests using nodepool

2016-05-10 Thread Monty Taylor
On 05/10/2016 08:54 AM, Vladimir Eremin wrote: > Hi, > > I've investigated status of nodepool multi node testing and fuel-qa > approaches, and I wanna share my opinion on moving Fuel testing on > OpenStack and nodepool. Awesome! This is a great writeup - and hopefully will be useful as we

Re: [openstack-dev] [fuel] [QA] running Fuel tests using nodepool

2016-05-10 Thread Jeremy Stanley
On 2016-05-10 15:54:34 +0300 (+0300), Vladimir Eremin wrote: [...] > 1. Automate overlay networking setup. I've used > https://www.tinc-vpn.org/ as a L2 > switching overlay, but OpenVPN could be tool of choice. Action > items: > - overlay networking setup should be

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

2016-05-04 Thread Sheena Conant
Hi all – I think this might’ve gotten buried a bit in the pre-summit and summit madness. I just wanted to kick the thread – I think this is a really good idea. Dogpiling all plugins into a single LP project makes it really difficult to pick out which bugs affect which plugins – and the

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

2016-05-02 Thread Evgeniy L
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][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-04-30 Thread Mike Bayer
On 04/30/2016 10:50 AM, Clint Byrum wrote: Excerpts from Roman Podoliaka's message of 2016-04-29 12:04:49 -0700: I'm curious why you think setting wsrep_sync_wait=1 wouldn't help. The exact example appears in the Galera documentation:

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-04-30 Thread Clint Byrum
Excerpts from Roman Podoliaka's message of 2016-04-29 12:04:49 -0700: > Hi Bogdan, > > Thank you for sharing this! I'll need to familiarize myself with this > Jepsen thing, but overall it looks interesting. > > As it turns out, we already run Galera in multi-writer mode in Fuel > unintentionally

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-04-30 Thread Mike Bayer
On 04/30/2016 02:57 AM, bdobre...@mirantis.com wrote: Hi Roman. That's interesting, although’s hard to believe (there is no slave lag in galera multi master). I can only suggest us to create another jepsen test to verify exactly scenario you describe. As well as other OpenStack specific

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-04-30 Thread bdobrelia
Hi Roman. That's interesting, although’s hard to believe (there is no slave lag in galera multi master). I can only suggest us to create another jepsen test to verify exactly scenario you describe. As well as other OpenStack specific patterns. Regards, Bogdan. Od: Roman Podoliaka

Re: [openstack-dev] [Fuel][MySQL][DLM][Oslo][DB][Trove][Galera][operators] Multi-master writes look OK, OCF RA and more things

2016-04-29 Thread Roman Podoliaka
Hi Bogdan, Thank you for sharing this! I'll need to familiarize myself with this Jepsen thing, but overall it looks interesting. As it turns out, we already run Galera in multi-writer mode in Fuel unintentionally in the case, when the active MySQL node goes down, HAProxy starts opening

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

2016-04-27 Thread Roman Prykhodchenko
Jeremy, Thanks for checking! Probably that is missing in the the release checklist. - romcheg > 26 квіт. 2016 р. о 17:35 Jeremy Stanley написав(ла): > > On 2016-04-26 17:29:40 +0200 (+0200), Roman Prykhodchenko wrote: >> I still don’t see python-fuelclient-9.0.0 on PyPi: >>

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

2016-04-26 Thread Jeremy Stanley
On 2016-04-26 17:29:40 +0200 (+0200), Roman Prykhodchenko wrote: > I still don’t see python-fuelclient-9.0.0 on PyPi: > https://pypi.python.org/pypi/python-fuelclient > > > Shouldn’t someone investigate this? It hasn't been tagged yet as far as

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

2016-04-26 Thread Roman Prykhodchenko
I still don’t see python-fuelclient-9.0.0 on PyPi: https://pypi.python.org/pypi/python-fuelclient Shouldn’t someone investigate this? > 25 квіт. 2016 р. о 18:33 Daniele Pizzolli > написав(ла): > > On Mon, Apr

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

2016-04-25 Thread Vladimir Kozhukalov
​Done. Wed 11:00-11:40 Finalizing of HA reference architecture with event-based control and fencing Thu 11:00-11:40 Fuel UI Modularization approaches discussion Vladimir Kozhukalov On Mon, Apr 25, 2016 at 10:14 PM, Vladimir Kuklin wrote: > Fuelers > > I am OK with the

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

2016-04-25 Thread Vladimir Kuklin
Fuelers I am OK with the proposed change 21 апр. 2016 г. 12:34 пользователь "Vitaly Kramskikh" < vkramsk...@mirantis.com> написал: > Folks, > > I'd like to request workroom sessions swap. > > I planned to lead a discussion of Fuel UI modularization on Wed > 11.00-11.40, but at the same time

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

2016-04-25 Thread Daniele Pizzolli
On Mon, Apr 25 2016, you wrote: > Can we support alternative way to download ISO since p2p may be prevented in > some company IT? Hello, It is supported... but not advertised. I am not sure if this is by purpose (maybe because in http there is no additional checksum, see later for offline

Re: [openstack-dev] [Fuel][plugins] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

2016-04-25 Thread Ilya Kutukov
You are welcome! On Sat, Apr 23, 2016 at 11:00 AM, Guillaume Thouvenin wrote: > Yes this patch fixes the issue. > Thanks Ilya. > > On Fri, Apr 22, 2016 at 4:53 PM, Ilya Kutukov > wrote: > >> Hello! >> >> I think your problem is related to the: >>

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

2016-04-25 Thread Guo, Ruijing
Can we support alternative way to download ISO since p2p may be prevented in some company IT? Thanks, -Ruijing From: Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com] Sent: Thursday, April 21, 2016 10:52 PM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Fuel][plugins] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

2016-04-23 Thread Guillaume Thouvenin
Yes this patch fixes the issue. Thanks Ilya. On Fri, Apr 22, 2016 at 4:53 PM, Ilya Kutukov wrote: > Hello! > > I think your problem is related to the: > https://bugs.launchpad.net/fuel/+bug/1570846 > > Fix to stable/mitaka was commited 20/04/2016 >

Re: [openstack-dev] [Fuel] [Ci] Re-trigger by keyword in comment

2016-04-22 Thread Aleksey Kasatkin
Matthew, It's great that we have this test. But why to rerun it for no changes? It was executed only when a new patch was published for CR or CR was rebased. Now it is executed on "fuel:recheck". Agree, adding a plugin would be helpful. Aleksey Kasatkin On Fri, Apr 22, 2016 at 4:19 PM,

Re: [openstack-dev] [Fuel][plugins] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

2016-04-22 Thread Simon Pasquier
Thanks Ilya! We're testing and will be reporting back on monday. Simon On Fri, Apr 22, 2016 at 4:53 PM, Ilya Kutukov wrote: > Hello! > > I think your problem is related to the: > https://bugs.launchpad.net/fuel/+bug/1570846 > > Fix to stable/mitaka was commited 20/04/2016

Re: [openstack-dev] [Fuel][plugins] Changing role regex from '*' to ['/.*/'] breaks MOS compatibility

2016-04-22 Thread Ilya Kutukov
Hello! I think your problem is related to the: https://bugs.launchpad.net/fuel/+bug/1570846 Fix to stable/mitaka was commited 20/04/2016 https://review.openstack.org/#/c/307658/ Could you, please, try to apply this patch and reply does it help or not. On Fri, Apr 22, 2016 at 5:40 PM, Guillaume

Re: [openstack-dev] [Fuel] [Ci] Re-trigger by keyword in comment

2016-04-22 Thread Matthew Mosesohn
Aleksey, actually I want to extend the test group we run there. Many changes coming out of nailgun are actually creating BVT failures that can only be prevented by such tests. One such extension would be adding a plugin to the deployment to ensure that basic plugins are still deployable. I'm ok

Re: [openstack-dev] [Fuel] [Ci] Re-trigger by keyword in comment

2016-04-22 Thread Aleksey Kasatkin
Hi Dmitry, Thank you for update. Is it intended that master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy job for code requests to fuel-web runs at every recheck now? Before the change it was executed for new

Re: [openstack-dev] [Fuel] snapshot tool

2016-04-21 Thread Dmitry Sutyagin
Team, A "bicycle" will have to be present anyway, as a code which interacts with Ansible, because as far as I understand Ansible on it's own cannot provide all the functionality in one go, so a wrapper for it will have to be present anyway. I think me and Alexander we will look into converting

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

2016-04-21 Thread Vitaly Kramskikh
Folks, I'd like to request workroom sessions swap. I planned to lead a discussion of Fuel UI modularization on Wed 11.00-11.40, but at the same time there will be discussion of handling JS dependencies of Horizon which I'd really like to attend. So I request to swap my discussion with

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

2016-04-21 Thread Neil Jerram
On 19/04/16 16:52, Irina Povolotskaya wrote: > Hi to everyone, > > as you possibly know (at least, those dev. teams working on their Fuel > plugins) we have a fuel-plugins Launchpad project [1] which serves as > all-in-one entry point for filing bugs, related > to plugin-specific problems. > >

Re: [openstack-dev] [Fuel] snapshot tool

2016-04-20 Thread Dmitry Nikishov
Dmitry, I mean, currently shotgun fetches services' configuration along with astute.yaml. These files contain passwords, keys, tokens. I beleive, these should be sanitized. Or, better yet, there should be an option to sanitize sensitive data from fetched files. Aleksandr, Currently Fuel has a

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

2016-04-20 Thread Simon Pasquier
Many thanks Alexey! That's exactly the information I needed. Simon On Wed, Apr 20, 2016 at 1:19 PM, Aleksey Kasatkin wrote: > Hi Simon, > > When network template is in use, network roles to endpoints mapping is > specified in section "roles" (in the template). So,

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

2016-04-20 Thread Aleksey Kasatkin
Hi Simon, When network template is in use, network roles to endpoints mapping is specified in section "roles" (in the template). So, "default_mapping" from network role description is overridden in the network template. E.g.: network_assignments: monitoring: ep: br-mon ...

Re: [openstack-dev] [Fuel] snapshot tool

2016-04-20 Thread Aleksandr Dobdin
Dmitry, You can create a non-root user account without root privileges but you need to add it to appropriate groups and configure sudo permissions (even though you add this user to root group, it will fail with iptables command for example) to get config files and launch requested commands.I

Re: [openstack-dev] [Fuel] snapshot tool

2016-04-19 Thread Dmitry Sutyagin
IMHO, removal of sensitive information is done by services when they (do not) log relative data to logs, such as tokens. Current set of commands only collects specific config folders and files and logs, but if an admin decided to store keys in one of these folders - the tool will collect them too.

Re: [openstack-dev] [Fuel] snapshot tool

2016-04-19 Thread Dmitry Nikishov
Hello, I've got a couple of questions: - What about this tool using non-root accounts to connect to OpenStack nodes? Currently, it seems to assume that it always is going to use "root" for SSH. - Shouldn't it sanitize all sensitive information (user names, host names, passwords, tokens, keys

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

2016-04-19 Thread Evgeniy L
Hi, On upcoming summit we will have a track on Fuel & Ironic (Ironic-inspector) integration, so you are welcome to participate. Thursday 9:00 https://etherpad.openstack.org/p/fuel-newton-summit-planning Thanks, On Fri, Mar 18, 2016 at 9:49 PM, Jim Rollenhagen wrote:

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

2016-04-18 Thread Evgeniy L
>> Btw, one of the ideas was to use Fuel task capabilities to gather diagnostic snapshot. I think such kind of tools should use as less as possible existing infrastructure, because in case if something went wrong, you should be able to easily get diagnostic information, even with broken RabbitMQ,

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

2016-04-18 Thread Vladimir Kozhukalov
Colleagues, Whether we are going to continue using Shotgun or substitute it with something else, we still need to decouple it from Fuel because 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,

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

2016-04-15 Thread Oleg Gelbukh
Jeremy, thank you, that's excellent news. The Infra team is doing awesome work to improve the processes in all possible ways. Andreas, I will take a closer look, but it seems to be exactly what I had in mind. Thanks for sharing! -- Best regards, Oleg Gelbukh On Fri, Apr 15, 2016 at 10:29 AM,

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

2016-04-15 Thread Andreas Jaeger
On 04/14/2016 06:30 PM, Jeremy Stanley wrote: On 2016-04-14 12:57:38 +0300 (+0300), Oleg Gelbukh wrote: The thread I'm referring to in the prev message is: http://lists.openstack.org/pipermail/openstack-infra/2014-January/000624.html At this point it's probably no longer a concern. We don't

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

2016-04-14 Thread Jeremy Stanley
On 2016-04-14 12:57:38 +0300 (+0300), Oleg Gelbukh wrote: > The thread I'm referring to in the prev message is: > http://lists.openstack.org/pipermail/openstack-infra/2014-January/000624.html At this point it's probably no longer a concern. We don't (and haven't for some time) really support pip

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

2016-04-14 Thread Alexey Shtokolov
Hi, +1 from my side. --- WBR, Alexey Shtokolov 2016-04-14 16:47 GMT+03:00 Evgeniy L : > 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

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

2016-04-14 Thread Evgeniy L
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] [fuelclient] Pre-release versions of fuelclient for testing purposes

2016-04-14 Thread Oleg Gelbukh
The thread I'm referring to in the prev message is: http://lists.openstack.org/pipermail/openstack-infra/2014-January/000624.html -- Best regards, Oleg Gelbukh Mirantis Inc. On Thu, Apr 14, 2016 at 12:56 PM, Oleg Gelbukh wrote: > Hi, > > I'm sorry for replying to this

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

2016-04-14 Thread Oleg Gelbukh
Hi, I'm sorry for replying to this old thread, but I would really like to see this moving. There's a 'pre-release' pipeline in Zuul which serves exactly that purpose: handle pre-release tags (beta-versions). However, per this thread, it is not recommended due to possible issues with pip unable

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Aleksandr Didenko
Alex, we can do this (and I hope we'll do) after we fix https://bugs.launchpad.net/fuel/+bug/1567367 Regards, Alex On Thu, Apr 7, 2016 at 5:04 PM, Alex Schultz wrote: > > On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko > wrote: > >> Hi, >> >>

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Alex Schultz
On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko wrote: > Hi, > > thanks to Dima, we now have ROLE annotations in noop tests [0]. I've > updated all the noop rspec tests that we currently have and added > appropriate role annotation [1]. So after this patch is merged, we

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-07 Thread Aleksandr Didenko
Hi, thanks to Dima, we now have ROLE annotations in noop tests [0]. I've updated all the noop rspec tests that we currently have and added appropriate role annotation [1]. So after this patch is merged, we no longer need to put any new fixtures into dozens of rspec files in order to enable it.

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

2016-04-07 Thread Vladimir Kozhukalov
Dear colleagues, Looks like we have consensus (lazy, but still consensus) on this topic: we don't need this role CL exposed to Fuel project. I have prepared a change [1] for our team structure policy. My suggestion is to make Fuel is an aggregator of independent components. Component teams could

Re: [openstack-dev] [Fuel] Merge Freeze for Mitaka branching

2016-04-06 Thread Aleksandra Fedorova
Hi, everyone, we were delayed by npm issue [0] in the gate, but currently we have successfully merged all version bumps [1] and got stable master, thanks to Sergey Kulanov who got it all fully tested in advance. Merge Freeze is lifted. Please note: * To merge change to Mitaka release, you need

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

2016-04-05 Thread Igor Belikov
Hi Sergey, According to Matthew Mosesohn the plan is to delay branching of detach-* plugins. The only plugin scheduled for branching tomorrow seems to be a fuel-plugin-murano. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 04 Apr 2016, at 15:11, Sergii Golovatiuk

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-05 Thread Aleksandr Didenko
Hi folks, we've merged all the changes related to fixtures update [0] and bugfix to unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in tests not related to your patch, then please rebase. Regards, Alex [0] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0 [1]

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

2016-04-05 Thread Oleksandr Berezovskyi
Hello, At the beginning of the work, we've taken fuel-agent driver from Ironic team and customized it. Here is main features, which were created during development for Cray (all of them are now part of bareon-ironic): 1. deploy-config could be stored in multiple places (image meta,

Re: [openstack-dev] [fuel] Unrelated changes in patches

2016-04-04 Thread Dmitry Borodaenko
On Mon, Apr 04, 2016 at 04:05:28PM +0300, Matthew Mosesohn wrote: > I've seen several cases where core reviewers bully contributors into > refactoring a particular piece of logic because it contains common > lines relating to some non-ideal code, even if the change doesn't > relate to this logic.

Re: [openstack-dev] [fuel] Unrelated changes in patches

2016-04-04 Thread Igor Kalnitsky
Dmitry Guryanov wrote: > It's often not so easy to decide, if you should include some unrelated > changes to your patch, like fixing spaces, renaming variables or > something else, which don't change logic. I'd say it depends. If, for example, variable name is used inside one function - it's ok

Re: [openstack-dev] [fuel] Unrelated changes in patches

2016-04-04 Thread Jason Rist
On 04/04/2016 07:05 AM, Matthew Mosesohn wrote: > Hi Dmitry, > > I've seen several cases where core reviewers bully contributors into > refactoring a particular piece of logic because it contains common > lines relating to some non-ideal code, even if the change doesn't > relate to this logic. >

Re: [openstack-dev] [fuel] Unrelated changes in patches

2016-04-04 Thread Matthew Mosesohn
Hi Dmitry, I've seen several cases where core reviewers bully contributors into refactoring a particular piece of logic because it contains common lines relating to some non-ideal code, even if the change doesn't relate to this logic. In general, I'm ok with formatting issues, but changing how a

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

2016-04-04 Thread Sergii Golovatiuk
What about plugins? For instance: fuel-plugin-detach-keystone -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Apr 4, 2016 at 1:44 PM, Igor Belikov wrote: > Hi, > > Fuel SCF will be taking place on April 6th, this means that we’re going to >

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

2016-04-04 Thread Sergey Kulanov
Hi, Igor thank you for update. Folks, I also kindly ask to review the list of patch-sets regarding SCF [1] We've already built custom iso (with [1]) which passed BVT tests [1]. https://review.openstack.org/#/q/topic:9.0-scf,n,z 2016-04-04 14:44 GMT+03:00 Igor Belikov :

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-01 Thread Vladimir Kuklin
Hi Alex +1 to your proposal - this is long-awaited change. On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko wrote: > One more thing about spec to fixture mapping [0]. What if instead of: > > # RUN: (hiera1) (facts1) > > we'll use > > # RUN: (roles_array1) (facts1) > > ?

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

2016-04-01 Thread Aleksandr Didenko
One more thing about spec to fixture mapping [0]. What if instead of: # RUN: (hiera1) (facts1) we'll use # RUN: (roles_array1) (facts1) ? We don't need to duplicate complicated task graph calculations to understand which task to execute, because we don't care about tasks ordering and

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

2016-04-01 Thread Oleg Gelbukh
Bogdan, I mostly agree with you on this. The only data that might originate from a node is discovery-related parameters, like CPU/disks/NICs architecture and such. However, at the moment the deployment data is partially generated at every node (i.e. globals.yaml, override/plugins/* and some

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

2016-04-01 Thread Bogdan Dobrelya
On 04/01/2016 10:41 AM, Oleg Gelbukh wrote: > Andrew, > > This is an excellent idea. It is apparently more efficient and > error-proof to make the split not by the resulted data but at the time > it is actually generated. We will play with this idea a little bit, and > will come up with design

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

2016-04-01 Thread Oleg Gelbukh
Andrew, This is an excellent idea. It is apparently more efficient and error-proof to make the split not by the resulted data but at the time it is actually generated. We will play with this idea a little bit, and will come up with design proposal shortly. Meanwhile, please be informed that we

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

2016-03-31 Thread Serg Melikyan
Hi fuelers, only few hours left until period of self-nomination will be closed, but so far we don't have neither consensus regarding how to proceed further nor candidates. I've increased period of self-nomination for another week (until April 7, 23:59 UTC) and expect to have decision about how

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

2016-03-31 Thread Bogdan Dobrelya
It is time for update! The previous idea with the committed state and automatic cross-repo merge hooks in zuul seems too complex to implement. So, the "CI gate for blah blah" magically becomes now a manual helper tool for reviewers/developers, see the docs update [0], [1]. You may start using it

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

2016-03-31 Thread Samer Machara
Hi, Sergii Here is the bug: https://bugs.launchpad.net/fuel/+bug/1564312 with the diagnostic snapshot. - Original Message - Sergii Golovatiuk sgolovatiuk at mirantis.com Thu Mar 31 09:09:39 UTC 2016 * Previous message: [openstack-dev] [FUEL] Timeout of deployment is exceeded &

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

2016-03-31 Thread Sergii Golovatiuk
Hi, According to logs I see manifest /etc/puppet/modules/osnailyfacter/modular/ceilometer/controller.pp was exceeded. However, at the same time I don't see any puppet.logs from primary-controllers :\ Though analysing other tasks like database.pp it was executed for 10 minutes when it usually

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

2016-03-31 Thread Evgeniy L
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

2016-03-31 Thread Evgeniy L
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] New version of fuel-devops (2.9.20)

2016-03-31 Thread Roman Prykhodchenko
I’ve just tried to look up for fuel-devops on PyPi and found nothing. Let’s set up everything to let OpenStack CI release this package to PyPi and start publish releases there. Also it’s better to use openstack-announce to announce new releases. - romcheg > 31 бер. 2016 р. о 11:52 Dennis

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

2016-03-31 Thread Vladimir Kozhukalov
Aleksandra, You are right, we need to split this task into several smaller work items. For the start, I have created BP [1]. Let's discuss this on Fuel IRC meeting [2] today. I have put this topic to the agenda. And this is a great idea to put this task into the list for interns. I'll certainly

Re: [openstack-dev] [FUEL] Timeout of deployment is exceeded & Fuel does not autodetect my hardware.

2016-03-31 Thread Sergii Golovatiuk
Hi Samer, On Thu, Mar 31, 2016 at 10:18 AM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Bonjour, Hello. > > I'm trying to deploy the basic 3 nodes architecture to learn OpenStack: > 1 controller and 2 compute nodes. After several hours of deployment, I got > this error 'Timeout

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

2016-03-30 Thread Aleksandra Fedorova
Hi, Vladimir, this is a great feature, which can make Fuel truly universal. But i think it is hard to fully commit to the whole thing at once, especially for new contributors. Let's start with splitting it into some observable chunks of work, in a form of wiki page, blueprint or spec. This way

Re: [openstack-dev] [Fuel] Extra red tape for filing bugs

2016-03-30 Thread Roman Prykhodchenko
We also often use bugtracker as a TODO tracker. This template does not work for TODOs at all. I understand that it’s not technically mandatory to follow it, but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes will overflow. > 30 бер. 2016 р. о 17:37 Roman

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