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 ma
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:
https://github.
ion can be made to allow the Fuel master to use
>> package 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 everythin
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" wrote:
> Dan - yo
thout this step, 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
wrote:
>
>> On 19 Nov 2014, at 16:10, Vladimir Kozhukalov
>> wrote:
>>
>> I am absolutely -1 for using Cobbler for
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 best
far better than gzip. 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 wrote:
> IMO, we should get a bu
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 ea
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 a
+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 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 following paths
+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 wrote:
> Hi everyone!
>
> I would like to propose Igor Kalnitsky as a core reviewer on the
> Fuel-web team. Igor has been workin
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 a
terested to see 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 wrote:
> Hi folks,
>
> Yesterday I performed the following upgrade chain:
>
> 5.1 ->
x27;s no support 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
wrote:
> Hi all,
> I was skimming through a nicely written blogpost about Fuel experienc
+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 wrote:
> Guys,
>
> We have a beautiful contribution guide:
> https://wiki.openstack.org/wiki/Fuel/How_to_contribute
>
> How
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 new/lost
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 decided to investigate the creat
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
containers
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 o
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
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 realtively simple - if user do
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 directories
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
wrote:
> On
previously errored.
Best Regards,
Matthew Mosesohn
On Tue, May 17, 2016 at 6:27 PM, Simon Pasquier 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 more context on the use case. Th
+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 without subject. I am adding subject to
>> > voting
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 p
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 wi
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 rol
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 leave
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 Ma
x27;t
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 Develo
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 c
>>> 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,
>>>> Sergii Golovatiuk,
>>&
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
see
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
What about bashate? It is already in use in several OpenStack projects?
https://github.com/openstack-dev/bashate
On Jul 9, 2015 11:15 AM, "Bartlomiej Piotrowski"
wrote:
> Hi all,
>
> as hopefully everyone knows, it's very challenging to prove that Bash
> encourages
> writing readable, maintainab
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 piece.
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 deployer
l actions (though it's another topic).
>
> I'm agree with Vladimir, 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
>
>
&g
ers 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
> wrote:
>>
>> How much effort are we spending? I'm not so sure
> 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 t
ble to provide all these parameters to the keystone
provider, 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
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 wrote:
>> There is a patch upstream[1] that enables V3 service endpoint
>> creation, but v2.0 users/clients will not see these endpoints
e auth_endpoint logic seems to just
duplicate that of openstacklib's credentials class, so I think it
would make sense to consolidate that. I will prepare a patch to
puppet-keystone and puppet-openstacklib to address this.
On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson wrote:
> On 07/30
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 Fuel-L
nality, which is why 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 wrote:
> On 07/31/2015 07:18 AM,
; On 11/08/15 01:14, Rich Megginson wrote:
> >>>> On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
> >>>>> Sorry to everyone for bringing up this old thread, but it seems we
> may
> >>>>> need more openstackclient/keystone experts to settle this.
> &
all other hosts 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,
ose we avoid raising any 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 feedba
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
to the script: 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
ommits you'd like to discuss, let's work
them 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 Upa
update on this project. I look forward to your
feedback and comments.
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/os
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 wrote:
> What version of openst
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 wrote:
> Finally! +2 !
>
&g
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
nchpad.net/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-b
g/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
>&g
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 pupept-keystone-core and it
>> wor
For real plugins that do more 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
wrote:
> Hi f
tes? It's will be even better integration tests.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
>>>>> wrote:
>>>>>>
>>>>>> > and really lowering barriers 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,
MAtthe
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: w
This should be for 6.1, not 6.0.1.
On Mar 13, 2015 2:10 PM, "Bogdan Dobrelya" 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
> it would incr
+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 reviews[0] and continues to
+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] https://github.com/sorrowless/f
66 matches
Mail list logo
