Hi Peter,
there are two ways I see today to have done what you want to:
First, you can change [0] and add some fields to store second netapp
device. In this case you'll need to change puppet manifests logic to use
new fields - according to current state, it's a bunch of code double or
you'll
Hi Vladimir,
I see one big problem here - people who have expert skills in one area (for
example, in fuel-library puppet manifests and their logic) will have
ability to set +2 and workflow +1 to reviews in other areas (for example,
in fuel-astute) where they don't have good expertise. It can lead
+1
On Thu, Aug 25, 2016 at 12:08 PM, Aleksandr Didenko
wrote:
> +1
>
> On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko > wrote:
>
>> +1
>>
>>
>> /sv
>>
>>
>>
>> __
>>
.
> (I tried this process for ubuntu-server.iso and it worked correctly).
>
> Regards,
>
> On 7 July 2016 at 09:54, Stanislaw Bogatkin <sbogat...@mirantis.com>
> wrote:
>
>> Hi guys,
>>
>> could you tell which way you used to write ISO to the
Hi guys,
could you tell which way you used to write ISO to the USB stick?
On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan wrote:
> I'm pretty sure this is a USB stick install as I've seen the same failure
> on Fuel-8.0. Basically, the installer is not able to find the
Hi all,
as you maybe know, new conditions for Fuel tasks were recently (in master
and mitaka branches) introduced. Right after this I got several questions
like 'hey, how can I check my new condition?' Answer could be 'use standard
yaql console', but it hasn't have Fuel internal yaql functions
Hi guys,
if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that
Hi guys,
if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that
+1 to maintain example plugins. It is easy enough and really lowering
barriers for people who just begin create plugins.
On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
wrote:
> Igor,
>
> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> example
Can we drop this
>>>> feature?
>>>> > or should we finish implementation of this feature.
>>>> >
>>>> >
>>>> > Regards,
>>>> > Bulat Gaifullin
>>>> > Mirantis Inc.
>>>> >
>>&g
It changes mostly nothing for case of furious plugin development when big
parts of code changed from one release to another.
You will have 6 different deployment_tasks directories and 30 a little bit
different files in root directory of plugin. Also you forgot about
repositories directory (+6 at
+1 to Vitaly. There can be many links, so just underline those we already
have is the best option.
On Tue, Feb 9, 2016 at 4:31 PM, Roman Prykhodchenko wrote:
> Cannot we use display the same link we use in the title?
>
> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh
Yes, I have created custom iso with debug output. It didn't help, so
another one with strace was created.
On Jan 27, 2016 00:56, "Alex Schultz" <aschu...@mirantis.com> wrote:
> On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
> <sbogat...@mirantis.com> wrote:
>
Malchuk <mmalc...@mirantis.com>
wrote:
> I think we shouldn't depend on the other services like Syslog and logger
> trying to catch the problem and it is better to create the logs ourselves.
>
>
> On Wed, Jan 27, 2016 at 1:49 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.c
output redirection to the log-file directly.
>
>
> On Wed, Jan 27, 2016 at 11:21 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Yes, I have created custom iso with debug output. It didn't help, so
>> another one with strace was created.
>> On
Hi guys,
for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
time, but breaks our BVT and swarm tests. There is no exact point where
problem root located. To better understand this, some verbosity to ntpdate
output was added but in logs we can see only that packet exchange
a
real clock onboard.
On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
wrote:
> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
> <sbogat...@mirantis.com> wrote:
> > Hi guys,
> >
> > for some time we have a bug [0] with ntpdate. It d
+1 to Andrew. Plugins created for run some code and plugin verification is
the source of trust there.
On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward wrote:
> I'd have to say that this is expected behavior. I'm not sure what you
> would hope to prohibit when these kinds of
k.org/#/c/243340
>>
>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov <dnikis...@mirantis.com>
>> wrote:
>>
>>> Stanislaw,
>>>
>>> proposing patches could be a viable option long-term, however, by the
>>> time these patches will mak
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
I believe you should ask other people if you are right, as set '-1' to code
that you
cannot improve is not the best option, so
> If you are not sure how the
before each retrigger of
> deployment test.
>
> Hope this answers your question.
>
> --
> Igor Belikov
> Fuel CI Engineer
> ibeli...@mirantis.com
>
> On 20 Nov 2015, at 13:57, Stanislaw Bogatkin <sbogat...@mirantis.com>
> wrote:
>
> Hi Igor,
>
&g
Hi Igor,
would you be so kind tell, why fuel-library deployment tests doesn't
support this? Maybe there is a link with previous talks about it?
On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov wrote:
> Hi,
>
> I’d like to inform you that all jobs running on Fuel CI (with
/github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>
> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I mean whole feature.
>> Btw, why do you want to grant capabilities via puppet? It should be do
Another option would be to have a fine-grained control only on Fuel
> services and leave all the other at their defaults.
>
> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I just propose the way I think is right,
gt; 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 makes a lot of sense to tie a "
+1 to remove containers
On Fri, Nov 20, 2015 at 12:29 AM, Thomas Goirand wrote:
> On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote:
> > Anyway, the idea is to get
> > rid of Docker containers on the master node and switch to plane package
> > based approach that we used
nislaw,
>>>>>
>>>>> I agree that this approch would work well. However, does Puppet allow
>>>>> managing capabilities and/or file ACLs? Or can they be easily set up when
>>>>> installing RPM package? (is there a way to specify capabilities/ACLs in
reement on the implementation so that there's
>> going to be a some kinf of compatibility during upgrades.
>>
>> Stanislaw,
>> Do I understand correctly that you propose using something like sucap to
>> launch from root, switch to a different user and then drop
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 captured while doing
> reviews recently - we are sacrificing quality to bugfixing and feature
> development
Hi Simon,
using 'include' in HAProxy is damn conveniently, I don't think it should
die. There is just one way I know to use haproxy with several different
conf's - to construct looong command line with all of them - and
it's really inconvenient.
On Tue, Nov 10, 2015 at 12:20 PM, Simon
Bartolomiej, it's customer-related patches, they, I think, have to be done
for 6.1 prior to 8+ release.
Dmitry, it's nice to hear about it. Did you consider to use linux
capabilities on fuel-related processes instead of just using non-extended
POSIX privileged/non-privileged permission checks?
I spoken with Sergii about this and prepared a patch for get rid of
SecurityWarning [0] - it was easy. But we can't get rid from
InsecurePlatformWarning
so easy way. I see next options:
1. Update python version as [1] said - should be hard task
2. Downgrade urllib version to one without such
, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
Hi folks.
Today I want to discuss the way we save SSL keys for Fuel
environments. As you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in
this case). In this case we will generate
Hi folks.
Today I want to discuss the way we save SSL keys for Fuel environments. As
you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in this
case). In this case we will generate private key, csr and crt in a
pre-deployment hook on master
and release notes (cause if someone will
decide to force HTTPS, he must to upgrade fuel-nailgun-client on all old
nodes too).
On Tue, Aug 4, 2015 at 5:05 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
Seems that second solution is okay.
Sebastian, I'll try to fix it before SCF.
On Tue, Aug 4
Hi guys,
in overall movement of Fuel to use secure sockets we think about wrapping
master node UI and API calls to SSL. But there are next caveat:
a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
little. But if it will be rewritten in 7.0 and HTTPS on master node will be
SSL.
But probably for UI we will have to perform redirect on JS level.
Thanks,
On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
Hi guys,
in overall movement of Fuel to use secure sockets we think about
wrapping master node UI and API calls to SSL
Hi,
can we just add all needed functionality from old fuel client that fuel2
needs, then say that old fuel-client is deprecated now and will not support
some new features, then add new features to fuel2 only? It seems like best
way for me, cause with this approach:
1. Clients will can use only
+1
On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com wrote:
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
wrote:
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of
Hi,
we have a spec that says we disable SSL by default and it was successfully
merged with that, no one was against such decision. So, if we want to
enable it by default now - we can. It should be done as a part of our usual
process, I think - I'll create a bug for it and fix it.
Current status
Actually, I didn't participate in that process a lot - just reviewed plugin
couple of times and as I know, we had had a commits that deleted zabbix
from current Fuel.
There is bug about that: https://bugs.launchpad.net/fuel/+bug/1455664
There is a review: https://review.openstack.org/#/c/182615/
2 weeks seems too small for me. We easy can be in situation when fix for
medium bug is done, but SCF starts. And gap between SCF and release easily
can be more than a month. So, 2 months seems okay for me if speaking about
forcibly applying auto-abandon by major vote. And I'm personally against
Hi Daniel,
answer is no - actually there is no strong dependency between public and
internal/admin endpoints. In your case keystone client ask keystone on
address 10.52.71.39 (which, I think, was provided by system
variable OS_AUTH_URL), auth on it and then keystone give endpoints list to
client.
easily ignore the controller HA (LBaaS
doesn't support HA :) ) and just go the standard LBaaS?
On Wed, May 6, 2015 at 2:55 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
Hi Daniel,
Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system
was introduced and LBaaS
Hi Daniel,
Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system
was introduced and LBaaS plugin was created. So, I think than docs about it
never existed for 5.1. But as I know, you can easily install LBaaS in 5.1
(it should be shipped in our repos) and configure it with
Hi Przemyslaw,
I would be glad to be core reviewer to fuel-plugin-glusterfs as long as
seems than I was only one person who push some commits to it.
On Thu, Apr 2, 2015 at 10:47 AM, Przemyslaw Kaminski pkamin...@mirantis.com
wrote:
Since there is no reply here I have taken steps to become core
+1
On Wed, Mar 25, 2015 at 10:10 PM, Dmitry Borodaenko
dborodae...@mirantis.com wrote:
Fuelers,
I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
She has contributed thousands of lines of documentation to Fuel over
the past several months, and has been a diligent
Hi everyone,
we have merged code that will create hybrid ISO. Current 6.1 #147 ISO
already can be booted from USB by standard method (just using dd
of=/path/to/iso of=/path/to/usb/stick).
Creating IMG artifact will be disabled soon, so, please, be aware of it.
Hi.
I'm vote for second option, cause if we will want to implement some unified
hierarchy (like Fuel as CA for keys on controllers for different env's)
then it will fit better than other options. If we implement 3rd option then
we will reinvent the wheel with SSL in future. Bare rsync as storage
+1
On Tue, Jan 27, 2015 at 4:05 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
Hi,
After starting implementing granular deployment we've faced a bunch of
issues that would make further development of this feature much more
complicated if we have to support both Simple and HA deployment
Hi guys,
We have a little concern related to Fuel bootstrap node NTP sync. Currently
we trying to sync time on bootstrap node with master node, but problem is
that NTP protocol has long convergence time, so if we just install master
node and right after that try to start some bootstrap node -
, cause some of
followed tasks depends on synced time.
On Fri, Dec 19, 2014 at 2:12 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On 19 Dec 2014, at 10:00, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
Hi guys,
We have a little concern related to Fuel bootstrap node NTP sync
Hi all,
As I understand, we just need to monitoring one node - Fuel master. For
slave nodes we already have a solution - zabbix.
So, in that case why we need some complicated stuff like monasca? Let's use
something small, like monit or sensu.
On Mon, Nov 24, 2014 at 10:36 PM, Fox, Kevin M
As for me - zabbix is overkill for one node. Zabbix Server + Agent +
Frontend + DB + HTTP server, and all of it for one node? Why not use
something that was developed for monitoring one node, doesn't have many
deps and work out of the box? Not necessarily Monit, but something similar.
On Wed, Nov
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will
I think that if we have 3 blueprints that realises some SSL stuff around
themselves then we can discuss it here.
My vision about SSL in Fuel split into 3 parts:
A) We need to implement [1] blueprint, cause it is only one way to generate
certificates.
How i see that:
1.0 We sync puppet-openssl
56 matches
Mail list logo