Re: [openstack-dev] [fuel][tripleo] Fuel and TripleO Cross-Project Integration

Hi, > 3. Consider integration of Fuel provisioning, network configuration and disk partitioning with Ironic and TripleO As a part of this, I'd like to propose "l23network" puppet module [0] separation from fuel-library. This would allow anyone to reuse it for software-defined network

Re: [openstack-dev] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

+1 On Thu, Sep 8, 2016 at 11:06 AM, Sergey Vasilenko wrote: > +1 > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe:

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

Hi, -1 for the proposal Regards, Alex On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov wrote: > Guys, I have one serious question: WHO will be global core? > Example: > I'm core reviewer in 2 repos, but I'm absolutely could not be core > reviewer in puppet! > > On

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

+1 On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko wrote: > +1 > > > /sv > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe:

Re: [openstack-dev] [Fuel] It is impossible to queue UpdateDnsmasqTask

Hi, well, we have only one DHCP server that serves multiple clusters. Actions with those multiple clusters may affect DHCP server configuration. So queueing tasks that change DHCP server configuration seems like a reasonable way to fix the problem. So options 2 and 3 are much better than 1 or 4.

Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

Hi, +1 from me. Regards, Alex On Mon, Jun 27, 2016 at 4:54 PM, Sergii Golovatiuk wrote: > I am very sorry for sending without subject. I am adding subject to voting > and my +1 > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Mon,

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

at 11:46 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi, > > you don't need to change anything in your plugin, we still have the same > netconfig.pp task on all nodes even after bugfix. > > Regards, > Alex > > On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovi

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

hange plugins deployment tasks > <https://github.com/openstack/fuel-plugin-nsxv/blob/bab9541d9f13cf80a4796117483e56e94f3a4c09/deployment_tasks.yaml#L1-L10> > according to the netconfig.pp refactoring? > > > On 6 June 2016 at 11:12, Aleksandr Didenko <adide...@mirantis.com&g

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

://review.openstack.org/324307 [1] http://paste.openstack.org/show/508319/ On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi, > > YAQL expressions support for task dependencies has been added to Nailgun > [0]. So now it's possible to fix network configu

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

lthough 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 < >> adide...@mirantis.com> wrote: >> >>> Hey Adam, >>> >>

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

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] [Plugins] Netconfig tasks changes

lan 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) not present on any other nodes than controllers. > Thanks. > > On W

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

will be executed only aftetr 'virtual_ips' task. Regards, Alex [0] https://review.openstack.org/#/c/320530/ On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi all, > > please be aware that now we have two netconfig tasks (in Fuel 9.0+): > > -

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

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

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

Hi all, please be aware that now we have two netconfig tasks (in Fuel 9.0+): - netconfig-controller - executed on controllers only - netconfig - executed on all other nodes puppet manifest is the same, but tasks are different. We had to do this [0] in order to fix network idempotency issues

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

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 <aschu...@mirantis.com> wrote: > > On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko <adide...@mirantis.com>

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

/302313 On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > 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 yo

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

://review.openstack.org/301107 [2] https://ci.fuel-infra.org/job/fuellib_noop_tests/ On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Hi Alex > > +1 to your proposal - this is long-awaited change. > > On Fri, Apr 1, 2016 at 6:01 PM, Ale

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

and dependencies in noop tests. All we need is to map rspec task tests to astute.yaml fixtures. And it could be done via roles. Regards, Alex [0] https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko <ad

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

Hi. As you may know, we're still using some very old astute.yaml fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have problems with fixture-to-rspec mapping [1]. So we've started to work on those problems [2]. So please be aware of upcoming changes in noop rspec

Re: [openstack-dev] [Fuel] [FFE] FF exception request for SR-IOV

w: https://review.openstack.org/286704 > > > > Complete list of patches on review: > > > https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov > > > > > > > > Aleksey Kasatkin > > > > > > On Tue, Mar 1, 2016 at

Re: [openstack-dev] [Fuel] network_metadata hash keys on astute.yaml

Hi, some additional info on the problem: if I create some Hiera override for the nodes list and use node key which is hostname bond, then after node rename (rename during LCM or reset/rename/redeploy - doesn't matter) my override will create a "ghost" node in the list and will not change settings

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

> Good idea. That should be done despite on any decision we will take. Currently you have to specify which releases your plugin supports [0]. So I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually did it and it worked just fine). But I won't be able to enable this plugin

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

omcheg > >>> > >>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin <akasat...@mirantis.com> > >>> написав(ла): > >>> > >>> AFAIC, it is better to remove by name then. Otherwise, you do not know > >>> what VIPs you are removing. &

Re: [openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

+1 On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov wrote: > +1 > > On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov wrote: > >> +1 >> >> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov >> wrote: >> >>> Hey Fuelers, >>> >>> Since

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

+1 for Michael Polenchuk On Wed, Mar 2, 2016 at 5:33 PM, Fedor Zhadaev wrote: > +1 for Michael :) > > ср, 2 мар 2016, 17:50 Matthew Mosesohn : > >> Hi all, >> >> Thank you for the nominations and +1s. I would like to propose Michael >> Polenchuk to

Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

Hi, > Merging this code is relatively non-intrusive to core Fuel Library code > as it is merely re-organizing the file structure of the osnailyfacter > module to be compatible with Puppet Master. It looks like super-intrusive to me. Modular manifests are, actually, the core of Fuel Library. And

[openstack-dev] [Fuel] [FFE] FF exception request for DPDK

Hi, I'd like to to request a feature freeze exception for "Support for DPDK for improved networking performance" feature [0]. Part of this feature is already merged [1]. We have the following patches in work / on review: https://review.openstack.org/281827 https://review.openstack.org/283044

[openstack-dev] [Fuel] [FFE] FF exception request for SR-IOV

Hi, I'd like to to request a feature freeze exception for "Support for SR-IOV for improved networking performance" feature [0]. Part of this feature is already merged [1]. We have the following patches in work / on review: https://review.openstack.org/280782 https://review.openstack.org/284603

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

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

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

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

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

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

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

9 PM, Andrew Woodward <xar...@gmail.com> wrote: > > > On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <adide...@mirantis.com> > wrote: > >> Hi, >> >> >> > So what is open? The composition layer. >> >> We can have different c

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

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

Re: [openstack-dev] [Fuel][library] relax downstream policy for puppet modules managed by librarian

Hi, one of cons: there might be delay in time when we need to apply a patch to upstream project and thus fork some project (needs some time to prepare patch to projects, get reviews and approves, etc). Having said that I vote for "lazy downstreaming". Regards, Alex On Fri, Jan 29, 2016 at 10:12

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

ray. But we'll have the problem with multiple plugins in such case. I've changed my mind :) I vote for leaving as in [0] since it's less destructive comparing to what we have now. Regards, Alex [0] https://review.openstack.org/#/c/273169/1 On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko <

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Well, with merging instead of overriding, I believe, this problem with multiple plugins still exists, right? How are we handling this now for multiple plugins? Since VIPs is array I also vote for overriding, since merging it could be a pain (how do you remove existing element during array merge?).

Re: [openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

such configuration. Regards, Alex [0] https://bugs.launchpad.net/fuel/+bug/1524320/comments/12 On Tue, Jan 19, 2016 at 9:42 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi, > > I would also prefer second solution. The only real downside of it is the > possibility to

Re: [openstack-dev] [fuel][plugin] node_role only need when attribute false - where is the fuel plugin parser code?

Whoops, forgot to add a link, sorry.. Here it is [0] http://paste.openstack.org/show/484552/ On Thu, Jan 21, 2016 at 1:24 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi, > > I'm working on a plugin for 8.0 atm and this is how it worked for me [0]. > It's a restri

Re: [openstack-dev] [fuel][plugin] node_role only need when attribute false - where is the fuel plugin parser code?

Hi, I'm working on a plugin for 8.0 atm and this is how it worked for me [0]. It's a restriction not for node role, it's for other plugin setting, but I suppose it should work in your case as well. So in general it should look like: condition: "settings:plugin_name.attribute_name.value == false"

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

Hi, > I also think 3.3 is the version that ships with 14.04. 3.4.3 is shipped with Ubuntu-14.04. I think 3.4, 3.8 and 4 should be enough. Regards, Alex On Wed, Jan 20, 2016 at 6:38 PM, Sergii Golovatiuk wrote: > +1 for 3.3, 3.4, 3.8 and 4 > > > -- > Best regards, >

Re: [openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

ployment of roles that share VIP (created from plugin, for instance) even when no load-balancing is involved at all - just to be safe. Regards, Alex On Fri, Jan 15, 2016 at 10:50 AM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > On 15.01.2016 10:19, Aleksandr Didenko wrote: >

[openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

Hi, We need to come up with some solution for a problem with VIP generation (auto allocation), see the original bug [0]. The main problem here is: how do we know what exactly IPs to auto allocate for VIPs when needed roles are in different nodegroups (i.e. in different IP networks)? For example

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hi, > b) Make the snapshot location share the diskspace of /var/log? +1 for that. And +1 for using hard links to save space during snapshot creation. Regards, Alex On Tue, Jan 12, 2016 at 12:12 PM, Artem Panchenko wrote: > Hi, > > doesn't matter how /var partition is

Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

> accurately wipe only partition table and do not touch any other data As Andrew said already, in such case LVM meta data will remain on the hard drive. So if you remove partition table, reboot the node (env reset), then configure exactly the same partition table (like when you use the same

Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

Hi, > I want to propose not to wipe disks and simply unset bootable flag from node disks. AFAIK, removing bootable flag does not guarantee that system won't be booted from the local drive. This is why erase_node is needed. Regards, Alex On Fri, Dec 25, 2015 at 8:59 AM, Artur Svechnikov

Re: [openstack-dev] [Fuel] Nominate Artem Roma for fuel-ostf core

+1 On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy < asledzins...@mirantis.com> wrote: > +1 > > On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich < > tleontov...@mirantis.com> wrote: > >> Hi guys, >> I'd like to nominate Artem Roma [0] for fuel-ostf core. >> >> Artem cares about fuel-ostf

Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

+1 On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich < tleontov...@mirantis.com> wrote: > Absolutely agree > > +1 > > > > > On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy < > asledzins...@mirantis.com> wrote: > >> Hi guys, >> I'd like to nominate Artem Panchenko [0] for fuel-qa core. >>

Re: [openstack-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?

Hi, just finished deployment of multirack env with ceph and external LB (not a standard multi-rack deployment scheme, actually, but still): http://paste.openstack.org/show/482610/ As you can see it works just fine in multirack. Also, we're running 'deploy_ceph_ha_nodegroups' system test as a

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

015 17:03, Bogdan Dobrelya wrote: > > On 01.12.2015 11:28, Aleksandr Didenko wrote: > >> Hi, > >> > >>> pregenerated catalogs for the Noop tests to become the very first > >>> committed state in the data regression process has to be put in the > >&g

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

Hi, having or not having docker on Fuel master affects mostly Fuel node deployment related scripts/manifests. If we need to fix a bug in Nailgun or OSTF - we can fix it in their codebase and it does not really matter whether we run Nailgin or OSTF inside docker or not. The same goes for all the

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

Hi, looks good to me. Regards, Alex On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych wrote: > Hi fuelers, > > We want to throw KVM/QEMU options from Wizard and instead of them leave > only one: Libvirt [0]. Libvirt option enables QEMU by default and there are > still

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

Hi, > Downgrading for no reason could bring us to big trouble and bad user experience +1 to this. Let's keep PostgreSQL 9.3. Regards, Alex On Mon, Dec 14, 2015 at 2:04 PM, Artem Silenkov wrote: > Hello! > > Vote for update. > > 1. We have already shipped 9.3 in

Re: [openstack-dev] [fuel-library] making task "apache" idempotent

Hi, I suppose disabling purge_configs is the only solution here. Running all the configuration in a single task does not fit well into deployment granularization philosophy. Regards, Alex On Fri, Dec 11, 2015 at 12:13 PM, Dmitry Bilunov wrote: > Hello. > > I am trying

Re: [openstack-dev] [Fuel] Disable stringify_facts in 9.0

Hi, I agree, let's do this. Regards, Alex On Fri, Dec 11, 2015 at 1:08 PM, Bartłomiej Piotrowski < bpiotrow...@mirantis.com> wrote: > Hi folks, > > my sense of aesthetics was slightly disturbed when I saw that the mounts > fact[1] is implemented by joining mount points using a comma. > > It

Re: [openstack-dev] [fuel] UI experience

Hi, that's great to know about this new button behaviour, because I was going to file a bug few days ago when I was not able to find "Stop" button on UI. But then I updated to a more recent ISO and the button "appeared" again. Now I know what that was, thank you. And I can't tell that my own

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

+1 On Wed, Dec 2, 2015 at 9:13 AM, Julia Aranovich wrote: > +1 > > On Tue, Dec 1, 2015 at 10:29 PM Sergii Golovatiuk < > sgolovat...@mirantis.com> wrote: > >> +1 >> >> -- >> Best regards, >> Sergii Golovatiuk, >> Skype #golserge >> IRC #holser >> >> On Tue, Dec 1, 2015

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

Hi, > pregenerated catalogs for the Noop tests to become the very first > committed state in the data regression process has to be put in the > *separate repo* +1 to that, we can put this new repo into .fixtures.yml > note, we could as well move the tests/noop/astute.yaml/ there +1 here too,

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hi, in your plan you need to have an item about updating ISO on fuel-library CI gates. Regards, Alex On Tue, Dec 1, 2015 at 4:11 PM, Sergii Golovatiuk wrote: > Hi, > > On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin > wrote: > >> Hello, >> >>

Re: [openstack-dev] [fuel][puppet] Detached roles and globals.pp

Hi, I think something like this would be more flexible: $swift_proxy_roles = hiera('swift_proxy_roles', ['primary-controller', 'controller']) $swift_storage_roles = hiera('swift_storage_roles', ['primary-controller', 'controller']) # ... $swift_nodes =

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

+1 from me On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin wrote: > 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

Re: [openstack-dev] [Fuel] Change VIP address via API

Hi, Mike, that's exactly how you can use this VIPs allocation functionality. Nailgun will save that VIP so it's not going to be auto-assigned to any node and serialize it into astute.yaml (vip_name: IP). After that you can get your VIP via Hiera and use it in your deployment scripts. Guys, could

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

Hi, let me try to rephrase this a bit and Bogdan will correct me if I'm wrong or missing something. We have a set of top-scope manifests (called Fuel puppet tasks) that we use for OpenStack deployment. We execute those tasks with "puppet apply". Each task supposed to bring target system into

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

Hi, please note that such tasks are executed inside 'mcollective' docker container, not on the Fuel master host system. Regards, Alex On Tue, Nov 3, 2015 at 10:41 PM, Igor Kalnitsky wrote: > Hi Javeria, > > Try to use 'master' in 'role' field. Example: > > - role:

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

Hi, +1 from me. Regards, Alex On Wed, Sep 2, 2015 at 5:00 PM, Vladimir Kuklin wrote: > +1 and also he is in US timezone, which should help us cover the globe > with Continuous Review process. > > On Wed, Sep 2, 2015 at 3:45 PM, Dmitry Borodaenko < >

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

Hi, I'm all in for any formalization and automation of review process. The only concern that I see here is about core reviewers involvement metrics. If we succeed in reducing the load on core reviewers, it will mean that core reviewers will do less code reviews. This could lead to core reviewer

Re: [openstack-dev] [Fuel] Aligning LP groups with real teams

, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich tleontov...@mirantis.com wrote: Hi, Alex vote +1 to use astute tag as well to get possibility identify issues related to astute in the most easy way. Regards, Tanya On Fri, Jul 17, 2015 at 3:59 PM, Aleksandr Didenko adide

Re: [openstack-dev] [Fuel][CI] CI on commit message

Hi, I think that checking commit message compliance to commit message guidelines (for example ending the first line with dot) is part of CI jobs, and they will vote -1 if message is wrongly structured. Maciej, we don't have such checks at the moment. You can craft any commit message you want

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature

Hi, I agree with Sergii, the patch had some problems only with tests which are already resolved. So I vote for FFE. P.S. We've just merged it. Regards, Alex On Mon, Jul 27, 2015 at 3:30 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have checked the code. After fixing tests,

Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support

Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0.

[openstack-dev] [Fuel] Switching keystone to apache wsgi

Hi, guys, we're about to switch keystone to apache wsgi by merging [0]. Just wanted to make sure everyone is aware of this change. If you have any questions or concerns let's discuss them in this thread. Regards, Alex [0] https://review.openstack.org/#/c/204111/

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hi, Am I alone in thinking it's not the best use of our development resources to throw it away and replace it with a text file that is edited by hand? Nope. I'm with you :) Many people prefer vim UX instead of wandering through the semi-graphical interface. Are those ppl developers or

Re: [openstack-dev] [Fuel][Plugins] Hiera nodes issue for 6.1 plugins

Hi, I think we should just fix the bug to make nodes.yaml match with the data in astute.yaml. Because 'nodes' Hiera key is also used for /etc/hosts update. I've raised bug priority to high. Regards, Alex On Wed, Jul 22, 2015 at 2:42 PM, Irina Povolotskaya ipovolotsk...@mirantis.com wrote: Hi

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

, On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script

[openstack-dev] [Fuel] Aligning LP groups with real teams

Hi, as we decided on the recent Fuel weekly IRC meeting, we need to align LP fuel-* groups with our teams and bug confirmation queues/duties. We decided to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have 2 members each. So from now on please assign bugs about provisioning

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

Hi, I think that we should provide a separate script that will fetch the upstream modules into fuel-library/deployment/puppet/ directory. It will allow us to have everything in a single place and use this script in ISO build process and CI jobs. Regards, Alex On Thu, Jul 16, 2015 at 11:17 PM,

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, guys, what if we simplify things a bit? All we need is: 1. Remove all the community modules from fuel-library. 2. Create 'Puppetfile' with list of community modules and their versions that we currently use. 3. Make sure all our customizations are proposed to the upstream modules

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, just wanted to mention another tool to work with 'Puppetfile' - r10k: https://github.com/puppetlabs/r10k/blob/master/doc/puppetfile.mkd Regards, Alex On Wed, Jun 24, 2015 at 11:04 PM, Paul Belanger pabelan...@redhat.com wrote: On 06/23/2015 01:51 PM, Alex Schultz wrote: Hello everyone,

Re: [openstack-dev] [Fuel] Python code in fuel-library

/fuellib_tasks_graph_check/ Regards, Aleksandr On Wed, Feb 18, 2015 at 4:02 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Seb Very fair point, thank you. We need to add this to our jobs for unittests run and syntax check. I am adding Aleksandr Didenko into the loop as he is currently working

[openstack-dev] [Fuel][Fuel-Library] Manifests and tasks for granular deployment

/fuel-library/tree/master/deployment/puppet/osnailyfacter/modular [6] https://fuel-jenkins.mirantis.com/job/fuellib_tasks_graph_check -- Regards, Aleksandr Didenko __ OpenStack Development Mailing List (not for usage questions

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

, Aleksandr Didenko adide...@mirantis.com wrote: Mike, Any objections / additional suggestions? no objections from me, and it's already covered by LP 1415116 bug [1] [1] https://bugs.launchpad.net/fuel/+bug/1415116 On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov mscherba

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

Mike, Any objections / additional suggestions? no objections from me, and it's already covered by LP 1415116 bug [1] [1] https://bugs.launchpad.net/fuel/+bug/1415116 On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Folks, one of the things we should not

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task. -- Regards, Aleksandr Didenko On Wed, Jan 28

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

3rd option is about using rsyncd that we run under xinetd on primary controller. And yes, the main concern here is security. On Wed, Jan 28, 2015 at 6:04 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi. I'm vote for second option, cause if we will want to implement some unified

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

suppose, it's time to finally drop support for Simple mode in Fuel :) [1] https://blueprints.launchpad.net/fuel/+spec/single-controller-ha [2] https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization -- Regards, Aleksandr Didenko On Tue, Aug 26, 2014 at 9:25 AM, Mike Scherbakov

Re: [openstack-dev] [Fuel] We lost some commits during upstream puppet manifests merge

://docs.mirantis.com/fuel-dev/develop/module_structure.html#contributing-to-existing-fuel-library-modules [2] https://review.openstack.org/141022 Regards, Aleksandr On Fri, Nov 21, 2014 at 8:07 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 21 Nov 2014, at 17:15, Aleksandr Didenko adide

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

Hi, Dmitriy, first of all, monit can provide HTTP interface for communication - so it's possible to poll that this interface to get info or even control monit (stop/start/restart service, stop/start monitoring of a service, etc). Secondly, you can configure different triggers in monit and set

Re: [openstack-dev] [Fuel] Plugins improvement

Hi, according to [1] you should be able to use: puppet_modules: puppet/:/etc/puppet/modules/ This is valid string yaml parameter that should be parsed just fine. [1] https://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62 Regards -- Alex On Mon, Nov 24,

Re: [openstack-dev] [Fuel] We lost some commits during upstream puppet manifests merge

/glance)_config resources have needed values in the puppet catalog. Since we're not going to sync 'openstack' module with the upstream, such tests will remain intact until we change them, and they won't be affected by other modules sync/merge (keystone, cinder, nova, etc). -- Regards, Aleksandr

[openstack-dev] [Fuel] Waiting for Haproxy backends

/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33 [3] https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements Regards, Aleksandr Didenko ___ OpenStack-dev mailing list OpenStack-dev

[openstack-dev] [Fuel] Hiera implementation

://review.openstack.org/#/c/126559/ [4] http://pastebin.com/HH0bUtYc Regards, Aleksandr Didenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Change in fuel-library CI syntax check script

-library/blob/master/deployment/puppet/galera/manifests/init.pp#L206-L212 Regards, Aleksandr Didenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

+1 for both. On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers As you may have noticed our project is growing continuously. And this imposes a requirement of

Re: [openstack-dev] [Fuel] Plugable solution for running abstract commands on nodes

Hi, as for execution of arbitrary code across the OpenStack cluster - I was thinking of mcollective + fact filters: 1) we need to start using mcollective facts [0] [2] - we don't use/configure this currently 2) use mcollective execute_shell_command agent (or any other agent) with fact filter [1]

Re: [openstack-dev] [Fuel] Using host networking for docker containers

Hi, we're running only 3 containers in privileged mode: cobbler, rsyslog and mcollective. Running all the containers in privileged mode is not a good idea for security reasons. Docker manages DNAT forwarding itself, so it does not create any overhead for us. Is there any real benefits of using

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

mean which version should we use in 5.0.1, for example? As far as I understand @DmitryB, it have to be 2014.1-5.0.1. Am I right? Thanks, Igor On Tue, Jul 1, 2014 at 8:47 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, my 2 cents: 1) Fuel version (+1 to Dmitry) 2) Could you

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

Hi, my 2 cents: 1) Fuel version (+1 to Dmitry) 2) Could you please clarify what exactly you mean by our patches / our first patch? On Tue, Jul 1, 2014 at 8:04 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: 1) Puppet manifests are part of Fuel so the version of Fuel should be used.

Re: [openstack-dev] [Fuel] Removing old node logs

Hi, If user runs some experiments with creating/deleting clusters, then taking care of old logs is under user's responsibility, I suppose. Fuel configures log rotation with compression for remote logs, so old logs will be gzipped and will not take much space. In case of additional boolean

Re: [openstack-dev] [Fuel] Removing old node logs

or such situation is ok? - Igor On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, If user runs some experiments with creating/deleting clusters, then taking care of old logs is under user's responsibility, I suppose. Fuel configures log rotation

Re: [openstack-dev] [Fuel] Removing old node logs

for all nodes at once too. - Igor On Tue, Jun 24, 2014 at 6:38 PM, Aleksandr Didenko adide...@mirantis.com wrote: Yeah, I thought about diagnostic snapshot too. Maybe it would be better to implement per-environment diagnostic snapshots? I.e. add diagnostic snapshot generate/download buttons

  1   2   >