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

+1 On Sun, Sep 11, 2016 at 10:20 PM, Alexey Shtokolov wrote: > +1 > > Stanislaw made a great contribution! > I would like to mention SSL-support, YAQL expressions for data-driven > orchestration > and his awesome live YAQL evaluator for Fuel Master node [0] > > [0]

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

+1 Denis is excellent at reviews and spotting CI failure root causes. I definitely support him. On Wed, Aug 24, 2016 at 11:36 PM, Alex Schultz wrote: > Ahoy Fuel Cores, > > I would like to propose Denis Egorenko for fuel-library core. Denis is > always providing great

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

+1. Maksim is an excellent reviewer. On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz wrote: > +1 > > On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya > wrote: >> >> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote: >> > I am very sorry for sending

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

previously errored. Best Regards, Matthew Mosesohn On Tue, May 17, 2016 at 6:27 PM, Simon Pasquier <spasqu...@mirantis.com> wrote: > I'm resurrecting this thread because I didn't manage to find a satisfying > solution to deal with this issue. > > First let me provide

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

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] [Ci] Re-trigger by keyword in comment

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] Unrelated changes in patches

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] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

Andrew, The stubs + deprecation warning is exactly the approach I believewe should take for renaming/moving tasks. If it was possible for a plugin to override a task, but preserve the fields from the original task, we could avoid such scenarios. What I mean is that if the following task: - id:

[openstack-dev] [fuel] UCA deployment landed and working

for rebuilding client libraries so quickly. I'm still running through testing cycles, and I'll report when we have a passed BVT using UCA. [1] https://bugs.launchpad.net/fuel/+bug/1556011 [2] https://review.openstack.org/293044 https://review.openstack.org/#/c/292340/ Best Regards, MAtthew Mosesohn

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

gt;>>> <ikalnit...@mirantis.com> wrote: >>>>>> >>>>>> > and really lowering barriers for people who just begin create >>>>>> > plugins. >>>>>> >>>>>> Nonsense. First, people usually creat

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

then install 1 package and enable 1 service, version limiting is the only thing to keep your users from losing their hair trying to figure out why it doesn't work. Best Regards, Matthew Mosesohn On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > Hi folks, &

Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

I'm not core, but I would like to say his contributions for Mitaka were invaluable and I've greatly benefited from his efforts :) On Fri, Mar 4, 2016 at 6:49 PM, Cody Herriges wrote: > Emilien Macchi wrote: >> Hi, >> >> To scale-up our review process, we created

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

.net/fuel/+bug/1543962 >> [1] https://bugs.launchpad.net/fuel/+bug/1551320 >> [3] >> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html >> [4] https://review.openstack.org/#/c/286310/ >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn <

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

/bugs/1548340 Best Regards, Matthew Mosesohn __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman

[openstack-dev] [Fuel][FFE] Enable UCA repositories for deployment

y is quite small because it only touches 1 task in OpenStack deployment, and by default it is not enabled. Open reviews: https://review.openstack.org/#/c/281762/ https://review.openstack.org/#/c/279556/ https://review.openstack.org/#/c/279542/ https://review.openstack.org/#/c/284584/ Best Regard

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

Hi all, Thank you for the nominations and +1s. I would like to propose Michael Polenchuk to add as a maintainer to fuel-library to take my spot when I leave the maintainers list. Best Regards, Matthew Mosesohn On Fri, Feb 26, 2016 at 3:54 PM, Kyrylo Galanov <kgala...@mirantis.com>

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hi Michal, Just add --os-identity-api-version=3 to your command it will work. The provider uses v3 openstackclient via env var OS_IDENTITY_API_VERSION=3. The default is still 2. Best Regards, Matthew Mosesohn On Fri, Feb 19, 2016 at 5:25 PM, Matt Fischer <m...@mattfischer.com> wrote:

[openstack-dev] Fuel 9.0 (Mitaka) deployment with Ubuntu UCA packages

Hi Fuelers and Stackers, I am pleased to announce the first possibility to deploy Mitaka using Fuel as a deployment tool. I am taking advantage of Alex Schultz's plugin, fuel-plugin-upstream[0], along with a series of patches currently on review[1]. I have not had a chance to do destructive tests

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

I would personally like to see Keystone get transitioned first, but it really doesn't matter where we start if we reach the right goal in the end. Since Emelien's work on refactoring all the providers for puppet-keystone, it has become a test bed for project-wide features. I'm really excited to

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

gards, >>> Alex >>> >>> On Wed, Jan 20, 2016 at 6:38 PM, Sergii Golovatiuk < >>> sgolovat...@mirantis.com> wrote: >>> >>>> +1 for 3.3, 3.4, 3.8 and 4 >>>> >>>> >>>> -- >>>> Best regards, >&

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

deploy Fuel 9.0 (or 8.0) on earlier Puppet versions, so what value is there to the checks? I propose we remove these tests, and hopefully we will see some immediate relief. Best Regards, Matthew Mosesohn __ OpenStack Development

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

Hi Nikolas, I'm not exactly sure about your case, but you should try something like this: https://github.com/openstack/fuel-plugin-detach-keystone/blob/master/node_roles.yaml#L14-L15 restrictions: - condition: "settings:opendaylight_plugin:use_external_odl == false" - message: "OpenDaylight role

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

I agree. As far as I remember, rabbit needs fqdns to work and map correctly. I think it means we should disable the ability to move the internal messaging network role in order to fix this bug until we can add extra dns entries per network role (or at least addr) On Dec 23, 2015 8:42 PM, "Andrew

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

Hi all, I have one concern related to 8.0 bugfixing until GA. If we disable docker deployment in master, we will need to target docker-specific patches for 8.0 first to master and then backport to stable/8.0, which is still in line with our standard bugfixing strategy. It will mean we should

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

Bogdan brings up a good point. fuel-createmirror in its current state pulls down an Ubuntu container and uses apt utilities inside. I know it's being replaced, but it's one instance of an item that might be overlooked by this process. On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya

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

Vladimir, The old site.pp is long out of date and should just be recreated from the content of all the other $service-only.pp files. My main question is how do we propose to do a rollback from an update (in theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent data

Re: [openstack-dev] [Fuel] API services available on public VIP

I haven't seen any more discussion on this topic. It looks like since we default to enabling SSL/TLS on deployments, there's no reason to block access to public API endpoints. On Fri, Nov 13, 2015 at 5:15 PM, Vladimir Kuklin wrote: > Adam > > I think, the answer is

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

Dmitry, We really shouldn't put "user" creation into a single package and then depend on it for daemons. If we want nailgun service to run as nailgun 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

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

Vladimir, Bugfixes and minor refactoring often belong in separate commits. Combining "extending foo to enable bar in XYZ" with "ensuring logs from service abc are sent via syslog" often makes little sense to code reviewers. In this case it is a feature enhancement + a bugfix. Looking at it from

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

Oleg, All the volatile information, including a DB dump, are contained in the small Fuel Master backup. There should be no information lost unless there was manual customization done inside the containers (such as puppet manifest changes). There shouldn't be a need to back up the entire

Re: [openstack-dev] [puppet] Creating puppet-keystone-core and proposing Richard Megginson core-reviewer

While I am not core, I would like to say that Rich's leadership in improving our Keystone Puppet module has been immensely valuable. +1 from me. -Matthew On Oct 31, 2015 5:58 PM, "Emilien Macchi" wrote: > At the Summit we discussed about scaling-up our team. > We

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

Bogdan, I don't want to maintain catalog resources 10 (or 20) times. It's an incredible amount of work to upkeep. There has to be a better way to ensure we don't lose some things. The approach I had in mind would have covered these cases: 1 - track all hiera lookups and make sure we catch

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

ript: http://paste.openstack.org/show/476821/ Note that this doesn't reflect "enabled" status of a plugin. It will make controller min count 0 for all environments. That won't break them, but it just removes the restriction. Best Regards, Matthew Mosesohn On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mesch

[openstack-dev] [Fuel] Testing before switching to upstream librarian

for moving to upstream modules to ensure no bugs are regressed that relate to the particular Puppet module being migrated. Secondly, what should our policy be? Revert the switch to upstream module? Or just work on cherry-picking the appropriate fixes? Best Regards, Matthew Mosesohn

[openstack-dev] [Fuel] backporting before merging to master

stable/X.X patches before a patch is _merged_ into master to avoid this scenario. Additionally, if a core sees that this is happening, he or she should mark it -2 and discourage submission of new patchsets. I welcome your thoughts and feedback. Best Regards, Matthe

Re: [openstack-dev] [openstack-ansible] To NTP, or not to NTP, that is the question

to sync time against that one host. This has major issues when you're doing virtual deployments with snapshot/revert and experiencing major time skew, so you may need extra VM management scripts to manually sync time again after revert. Best Regards, Matthew Mosesohn On Fri, Sep 18, 2015 at 4:03

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

, 2015 at 3:47 PM, Gilles Dubreuil gil...@redhat.com wrote: On 14/08/15 20:45, Gilles Dubreuil wrote: On 13/08/15 23:29, Rich Megginson wrote: On 08/13/2015 12:41 AM, Gilles Dubreuil wrote: Hi Matthew, On 11/08/15 01:14, Rich Megginson wrote: On 08/10/2015 07:46 AM, Matthew Mosesohn

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

it probably went undetected for so long. If anyone can speak up on these items, it could help influence the outcome of this patch. Thank you for your time. Best Regards, Matthew Mosesohn On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson rmegg...@redhat.com wrote: On 07/31/2015 07:18 AM, Matthew

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

Jesse, thanks for raising this. Like you, I should just track upstream and wait for full V3 support. I've taken the quickest approach and written fixes to puppet-openstacklib and puppet-keystone: https://review.openstack.org/#/c/207873/ https://review.openstack.org/#/c/207890/ and again to

[openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. [0] https://review.openstack.org/#/c/196943/ [1] https://review.openstack.org/#/c/178456/24 Best Regards, Matthew Mosesohn

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

08:53 AM, Matthew Mosesohn wrote: Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint

Re: [openstack-dev] [Fuel] version.yaml in the context of packages

2) production - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this.

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

We had that before and had very poor validation. Removing fuelmenu would make the experience quite manual and prone to errors. This topic comes up once a year only from Fuel Python developers because they rarely use it and no dev cycles have been invested in improving it. The actual Fuel

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

, vim + config files are enough, since Fuel is not a product for housewives. It's a product for those who do not hesitate to use Vim for soft configuration. Thanks, Igor On Thu, Jul 23, 2015 at 2:27 PM, Matthew Mosesohn mmoses...@mirantis.com wrote: We had that before and had very poor

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

of the parameters supported by Fuel menu as kernel boot parameters. Isn't it sufficient replacement for fuelmenu for dev's purposes? -Oleg On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com wrote: How much effort are we spending? I'm not so sure it's a major

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

One item that will impact this separation is that fuel_upgrade implicitly depends on the openstack.yaml release file from fuel-nailgun. Without it, the upgrade process won't work. We should refactor fuel-nailgun to implement this functionality on its own, but then have fuel_upgrade call this

[openstack-dev] [Fuel][Plugins] Separating services from controller role update

. Best Regards, Matthew Mosesohn [0] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin [1] https://review.openstack.org/#/c/189262/ [2] https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/openstack-cinder/openstack-cinder.pp#L14

Re: [openstack-dev] [puppet] [fuel] more collaboration request

out. I believe I can get the Fuel Library team to agree to do a walk through all the open bugs in Puppet OpenStack and see if we have any related fixes or bug reports. Best Regards, Matthew Mosesohn On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay san...@gmail.com wrote: +1 for the thread, I would

Re: [openstack-dev] [Fuel][docker] A FFE request for docker improvements for the 6.0.1 release

This should be for 6.1, not 6.0.1. On Mar 13, 2015 2:10 PM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello. I'd like to request a FFE for Docker host networking improvements [0] for the Fuel 6.0.1 feature freeze. This is really important to have it implemented for the 6.0.1 release as

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

. If increasing compression time by 3-5x is too much for you guys, why not just go to bzip? You'll still improve compression but be able to cut back on time. Best Regards, Matthew Mosesohn On Mon, Nov 24, 2014 at 3:14 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: IMO, we should get a bunch

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

I'm okay with Sensu or Monit, just as long as the results of monitoring can be represented in a web UI and has a configurable option for email alerting. Tight integration with Fuel Web is a nice-to-have (via AMQP perhaps), but anything that can solve our out-of-disk scenario is ideal. I did my

Re: [openstack-dev] [Fuel] Power management in Cobbler

, neither Cobbler nor Ironic is capable of handling this task. Best Regards, Matthew Mosesohn On Wed, Nov 19, 2014 at 7:38 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 19 Nov 2014, at 16:10, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: I am absolutely -1 for using Cobbler

Re: [openstack-dev] [Fuel] CentOS falls into interactive mode: Unsupported hardware

for CentOS (except from the community), so this error message has no true value in a non-commercial OS. Best Regards, Matthew Mosesohn On Mon, Nov 17, 2014 at 4:30 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi all, I was skimming through a nicely written blogpost about Fuel experience [1

Re: [openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0

which pieces cause the failure and this is some area I didn't plan for in container upgrades. Best Regards, Matthew Mosesohn On Fri, Nov 14, 2014 at 3:43 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi folks, Yesterday I performed the following upgrade chain: 5.1 - 5.1.1 - 6.0

Re: [openstack-dev] [Fuel] NTP settings.

Andrew, That just shifts the error into Nailgun which is forced to examine NTP settings of the host. With docker containerization, it makes detecting this much more difficult. Erroring during fuelmenu is the only chance where a user can effectively set the NTP parameters correctly. We could write

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

+1. I'm not core, but he has done the most thorough reviews lately and shows great initiative in maintaining quality in Fuel. On Mon, Oct 13, 2014 at 5:53 PM, Evgeniy L e...@mirantis.com wrote: Hi everyone! I would like to propose Igor Kalnitsky as a core reviewer on the Fuel-web team. Igor

Re: [openstack-dev] [Fuel] Let's remove fuelweb from repo paths

+1. It was a legacy item and it should go away. I'll review the patches. On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi fuelers, I'm going to propose you remove fuelweb word from repos' paths. What am I talking about? Let me show you. Currently we have the

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

Dmitry, we already use lrzuntar in deploying Docker containers. Use a lower compression ratio and it will decompress faster on virtual envs and it takes under two mins on my virtual env. Compress: https://github.com/stackforge/fuel-main/blob/master/docker/module.mk#L27 Decompress:

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

repositories instead of an upgrade file - and the option can be used for development and production? Jessee, could please clarify this? Do you mean to use remote repository with packages, instead of tarballing everything into single bundle? On Fri, Aug 22, 2014 at 12:39 PM, Matthew Mosesohn mmoses

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

Moving to host networking would reduce our ability to do zero downtime upgrades in the future. It means you must kill the old container in order to start the new one, rather than allowing for the possibility to remap the network configuration in iptables. It's something we don't have now, but we

Re: [openstack-dev] [Fuel] Blueprints process

+1 Keeping features separate as blueprints (even tiny ones with no spec) really will let us focus on the volume of real bugs. On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: Guys, We have a beautiful contribution guide:

Re: [openstack-dev] [Fuel] Symlinks to new stuff for OpenStack Patching

Hi Igor, The repo directory its is too large to fit in a docker container and work reliably. It is just a symlink inside the repo storage container from host:/var/www/nailgun to repo-container:/repo. This /repo folder is shared out to containers, such as nginx, and then symlinks are created for

Re: [openstack-dev] [Fuel] Problem with kombu version.

Dmitry, I don't think you should drop kombu.five so soon. We haven't heard directly from Fuel python team, such as Dmitry Pyzhov, what reason we have to lock kombu at version 2.5.14. I wrote to him earlier today out of band, so hopefully he will get back to this message soon. On Wed, Apr 9, 2014

Re: [openstack-dev] [TripleO] dhcp-all-interfaces changes reverted

Robert, I have noticed that trying to DHCP on all interfaces at once in Ubuntu 12.04 results in wrong interfaces getting particular reservations. It is better to do one at a time (with all interfaces down first) with a pause in between. On Feb 14, 2014 6:03 AM, Robert Collins