On Sun, Sep 11, 2016 at 10:20 PM, Alexey Shtokolov
> Stanislaw made a great contribution!
> I would like to mention SSL-support, YAQL expressions for data-driven
> and his awesome live YAQL evaluator for Fuel Master node 
+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
+1. Maksim is an excellent reviewer.
On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz wrote:
> On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya
>> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:
>> > I am very sorry for sending
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
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
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
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
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:
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.
 https://review.openstack.org/293044 https://review.openstack.org/#/c/292340/
gt;>>> <ikalnit...@mirantis.com> wrote:
>>>>>> > and really lowering barriers for people who just begin create
>>>>>> > plugins.
>>>>>> Nonsense. First, people usually creat
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.
On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov
> Hi folks,
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:
>> To scale-up our review process, we created
>>  https://bugs.launchpad.net/fuel/+bug/1551320
>>  https://review.openstack.org/#/c/286310/
>> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn <
OpenStack Development Mailing List (not for usage questions)
y is quite small because it only touches 1
task in OpenStack deployment, and by default it is not enabled.
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.
On Fri, Feb 26, 2016 at 3:54 PM, Kyrylo Galanov <kgala...@mirantis.com>
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.
On Fri, Feb 19, 2016 at 5:25 PM, Matt Fischer <m...@mattfischer.com> wrote:
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, along with a series of patches
currently on review. I have not had a chance to do destructive
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
>>> 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,
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.
I'm not exactly sure about your case, but you should try something like
- condition: "settings:opendaylight_plugin:use_external_odl == false"
- message: "OpenDaylight role
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
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
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
On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya
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
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
> I think, the answer is
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
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
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
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
On Oct 31, 2015 5:58 PM, "Emilien Macchi" wrote:
> At the Summit we discussed about scaling-up our team.
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
1 - track all hiera lookups and make sure we catch
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.
On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mesch
for moving to upstream modules to
ensure no bugs are regressed that relate to the particular Puppet module
Secondly, what should our policy be? Revert the switch to upstream module?
Or just work on cherry-picking the appropriate fixes?
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.
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.
On Fri, Sep 18, 2015 at 4:03
, 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:
On 11/08/15 01:14, Rich Megginson wrote:
On 08/10/2015 07:46 AM, Matthew Mosesohn
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.
On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson rmegg...@redhat.com wrote:
On 07/31/2015 07:18 AM, Matthew
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:
and again to
, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
Sorry, I meant to link  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 that enables V3 service endpoint
creation, but v2.0 users/clients will not see
08:53 AM, Matthew Mosesohn wrote:
Sorry, I meant to link  to
More responses inline.
On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com
There is a patch upstream that enables V3 service endpoint
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.
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
The actual Fuel
, 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.
On Thu, Jul 23, 2015 at 2:27 PM, Matthew Mosesohn
We had that before and had very poor
of the parameters supported
by Fuel menu as kernel boot parameters. Isn't it sufficient replacement for
fuelmenu for dev's purposes?
On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com
How much effort are we spending? I'm not so sure it's a major
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
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.
On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay san...@gmail.com wrote:
+1 for the thread, I would
This should be for 6.1, not 6.0.1.
On Mar 13, 2015 2:10 PM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
I'd like to request a FFE for Docker host networking improvements 
for the Fuel 6.0.1 feature freeze.
This is really important to have it implemented for the 6.0.1 release as
. 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.
On Mon, Nov 24, 2014 at 3:14 PM, Vladimir Kuklin vkuk...@mirantis.com wrote:
IMO, we should get a bunch
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
, neither Cobbler nor Ironic is
capable of handling this task.
On Wed, Nov 19, 2014 at 7:38 PM, Tomasz Napierala
On 19 Nov 2014, at 16:10, Vladimir Kozhukalov vkozhuka...@mirantis.com
I am absolutely -1 for using Cobbler
for CentOS (except from
the community), so this error message has no true value in a
On Mon, Nov 17, 2014 at 4:30 PM, Mike Scherbakov
I was skimming through a nicely written blogpost about Fuel experience [1
pieces cause the failure and this is some area I didn't plan for in
On Fri, Nov 14, 2014 at 3:43 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote:
Yesterday I performed the following upgrade chain:
5.1 - 5.1.1 - 6.0
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
+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:
I would like to propose Igor Kalnitsky as a core reviewer on the
Fuel-web team. Igor
+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:
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
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.
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
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
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:
We have a beautiful contribution guide:
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
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
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
On Feb 14, 2014 6:03 AM, Robert Collins
Mail list logo