+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]
+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:
> +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
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
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
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
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
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:
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
gt;>>> <ikalnit...@mirantis.com> wrote:
>>>>>>
>>>>>> > and really lowering barriers for people who just begin create
>>>>>> > plugins.
>>>>>>
>>>>>> Nonsense. First, people usually creat
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,
&
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
.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 <
/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
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
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>
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:
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
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
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,
>&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
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
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
, 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
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
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
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
improving it.
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.
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
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
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
.
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
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
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
. 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
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.
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
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
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
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
+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
+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
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:
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
+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:
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
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
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
65 matches
Mail list logo