Hi,
> 3. Consider integration of Fuel provisioning, network configuration and
disk partitioning with Ironic and TripleO
As a part of this, I'd like to propose "l23network" puppet module [0]
separation from fuel-library. This would allow anyone to reuse it for
software-defined network
+1
On Thu, Sep 8, 2016 at 11:06 AM, Sergey Vasilenko
wrote:
> +1
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
Hi,
-1 for the proposal
Regards,
Alex
On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov
wrote:
> Guys, I have one serious question: WHO will be global core?
> Example:
> I'm core reviewer in 2 repos, but I'm absolutely could not be core
> reviewer in puppet!
>
> On
+1
On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko
wrote:
> +1
>
>
> /sv
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
Hi,
well, we have only one DHCP server that serves multiple clusters. Actions
with those multiple clusters may affect DHCP server configuration. So
queueing tasks that change DHCP server configuration seems like a
reasonable way to fix the problem. So options 2 and 3 are much better than
1 or 4.
Hi,
+1 from me.
Regards,
Alex
On Mon, Jun 27, 2016 at 4:54 PM, Sergii Golovatiuk wrote:
> I am very sorry for sending without subject. I am adding subject to voting
> and my +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon,
at 11:46 AM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi,
>
> you don't need to change anything in your plugin, we still have the same
> netconfig.pp task on all nodes even after bugfix.
>
> Regards,
> Alex
>
> On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovi
hange plugins deployment tasks
> <https://github.com/openstack/fuel-plugin-nsxv/blob/bab9541d9f13cf80a4796117483e56e94f3a4c09/deployment_tasks.yaml#L1-L10>
> according to the netconfig.pp refactoring?
>
>
> On 6 June 2016 at 11:12, Aleksandr Didenko <adide...@mirantis.com&g
://review.openstack.org/324307
[1] http://paste.openstack.org/show/508319/
On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi,
>
> YAQL expressions support for task dependencies has been added to Nailgun
> [0]. So now it's possible to fix network configu
lthough AFAIR it doesn't
>> solve thing I'd like to do.
>> I'll come later to you in case of any questions.
>>
>>
>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hey Adam,
>>>
>>
Hi,
+1 to Igor. It should be easily doable via some sort of "watcher" script
(run it as a daemon or under cron), that script should:
- watch for new nodes in 'discover' state. CLI example:
fuel nodes
- assign new nodes to env with compute role. CLI example:
fuel --env $ENV_ID node set --node
lan and associated bridge only for
> controllers?
> I think about DMZ use case and possibility to expose public IPs/VIP and
> API endpoints on controllers on a completely separate L2 network (segment
> vlan/bridge) not present on any other nodes than controllers.
> Thanks.
>
> On W
will be executed only
aftetr 'virtual_ips' task.
Regards,
Alex
[0] https://review.openstack.org/#/c/320530/
On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi all,
>
> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>
> -
Hi,
thank you Stas, long awaited tool :) Using it right now on the latest
Fuel-10.0, very helpful and saves a lot of time (switching between nodes to
test yaql for different roles is super cool).
Regards,
Alex
On Tue, May 24, 2016 at 12:50 PM, Stanislaw Bogatkin
Hi all,
please be aware that now we have two netconfig tasks (in Fuel 9.0+):
- netconfig-controller - executed on controllers only
- netconfig - executed on all other nodes
puppet manifest is the same, but tasks are different. We had to do this [0]
in order to fix network idempotency issues
Alex, we can do this (and I hope we'll do) after we fix
https://bugs.launchpad.net/fuel/+bug/1567367
Regards,
Alex
On Thu, Apr 7, 2016 at 5:04 PM, Alex Schultz <aschu...@mirantis.com> wrote:
>
> On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko <adide...@mirantis.com>
/302313
On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi folks,
>
> we've merged all the changes related to fixtures update [0] and bugfix to
> unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in tests
> not related to yo
://review.openstack.org/301107
[2] https://ci.fuel-infra.org/job/fuellib_noop_tests/
On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:
> Hi Alex
>
> +1 to your proposal - this is long-awaited change.
>
> On Fri, Apr 1, 2016 at 6:01 PM, Ale
and dependencies in noop tests. All we need is to map rspec task
tests to astute.yaml fixtures. And it could be done via roles.
Regards,
Alex
[0]
https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko <ad
Hi.
As you may know, we're still using some very old astute.yaml fixtures
(v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
problems with fixture-to-rspec mapping [1]. So we've started to work on
those problems [2].
So please be aware of upcoming changes in noop rspec
w: https://review.openstack.org/286704
> >
> > Complete list of patches on review:
> >
> https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov
> >
> >
> >
> > Aleksey Kasatkin
> >
> >
> > On Tue, Mar 1, 2016 at
Hi,
some additional info on the problem: if I create some Hiera override for
the nodes list and use node key which is hostname bond, then after node
rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
override will create a "ghost" node in the list and will not change
settings
> Good idea. That should be done despite on any decision we will take.
Currently you have to specify which releases your plugin supports [0]. So I
can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually
did it and it worked just fine). But I won't be able to enable this plugin
omcheg
> >>>
> >>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin <akasat...@mirantis.com>
> >>> написав(ла):
> >>>
> >>> AFAIC, it is better to remove by name then. Otherwise, you do not know
> >>> what VIPs you are removing.
&
+1
On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov
wrote:
> +1
>
> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov wrote:
>
>> +1
>>
>> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov
>> wrote:
>>
>>> Hey Fuelers,
>>>
>>> Since
+1 for Michael Polenchuk
On Wed, Mar 2, 2016 at 5:33 PM, Fedor Zhadaev wrote:
> +1 for Michael :)
>
> ср, 2 мар 2016, 17:50 Matthew Mosesohn :
>
>> Hi all,
>>
>> Thank you for the nominations and +1s. I would like to propose Michael
>> Polenchuk to
Hi,
> Merging this code is relatively non-intrusive to core Fuel Library code
> as it is merely re-organizing the file structure of the osnailyfacter
> module to be compatible with Puppet Master.
It looks like super-intrusive to me. Modular manifests are, actually, the
core of Fuel Library. And
Hi,
I'd like to to request a feature freeze exception for "Support for DPDK for
improved networking performance" feature [0].
Part of this feature is already merged [1]. We have the following patches
in work / on review:
https://review.openstack.org/281827
https://review.openstack.org/283044
Hi,
I'd like to to request a feature freeze exception for "Support for SR-IOV
for improved networking performance" feature [0].
Part of this feature is already merged [1]. We have the following patches
in work / on review:
https://review.openstack.org/280782
https://review.openstack.org/284603
+1
On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin
wrote:
> Fellow Fuelers
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn as
> a Fuel Library Core
> reviewer.
>
> Matthew has been working with Fuel since its inception, worked on
> countless
> I vote to abandon it. Let's do not break existing plugins, and do not
> add *undo* tasks for plugin developers. If they want to configure
> network, they'll ask it explicitly.
+1 to this gentleman. It's safe to add wildcards only to tasks that were
moved from pre/post deployment stages, which
> Given the requirements to be able to use new features in fuel, with an
older version of OpenStack, what alternative would you propose?
For example, it's possible to use existing "release" functionality in Fuel
(release contains granular tasks configuration, puppet modules and
manifests,
9 PM, Andrew Woodward <xar...@gmail.com> wrote:
>
>
> On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <adide...@mirantis.com>
> wrote:
>
>> Hi,
>>
>>
>> > So what is open? The composition layer.
>>
>> We can have different c
Hi,
> So what is open? The composition layer.
We can have different composition layers for every release and it's already
implemented in releases - separate puppet modules/manifests dir for every
release.
> Currently, we just abandon support for previous versions in the
composition layer and
Hi,
one of cons: there might be delay in time when we need to apply a patch to
upstream project and thus fork some project (needs some time to prepare
patch to projects, get reviews and approves, etc). Having said that I vote
for "lazy downstreaming".
Regards,
Alex
On Fri, Jan 29, 2016 at 10:12
ray. But we'll have the problem with multiple plugins
in such case.
I've changed my mind :) I vote for leaving as in [0] since it's less
destructive comparing to what we have now.
Regards,
Alex
[0] https://review.openstack.org/#/c/273169/1
On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko <
Well, with merging instead of overriding, I believe, this problem with
multiple plugins still exists, right? How are we handling this now for
multiple plugins?
Since VIPs is array I also vote for overriding, since merging it could be a
pain (how do you remove existing element during array merge?).
such
configuration.
Regards,
Alex
[0] https://bugs.launchpad.net/fuel/+bug/1524320/comments/12
On Tue, Jan 19, 2016 at 9:42 AM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi,
>
> I would also prefer second solution. The only real downside of it is the
> possibility to
Whoops, forgot to add a link, sorry.. Here it is
[0] http://paste.openstack.org/show/484552/
On Thu, Jan 21, 2016 at 1:24 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:
> Hi,
>
> I'm working on a plugin for 8.0 atm and this is how it worked for me [0].
> It's a restri
Hi,
I'm working on a plugin for 8.0 atm and this is how it worked for me [0].
It's a restriction not for node role, it's for other plugin setting, but I
suppose it should work in your case as well.
So in general it should look like:
condition: "settings:plugin_name.attribute_name.value == false"
Hi,
> I also think 3.3 is the version that ships with 14.04.
3.4.3 is shipped with Ubuntu-14.04. I think 3.4, 3.8 and 4 should be enough.
Regards,
Alex
On Wed, Jan 20, 2016 at 6:38 PM, Sergii Golovatiuk wrote:
> +1 for 3.3, 3.4, 3.8 and 4
>
>
> --
> Best regards,
>
ployment of roles that share VIP (created
from plugin, for instance) even when no load-balancing is involved at all -
just to be safe.
Regards,
Alex
On Fri, Jan 15, 2016 at 10:50 AM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:
> On 15.01.2016 10:19, Aleksandr Didenko wrote:
>
Hi,
We need to come up with some solution for a problem with VIP generation
(auto allocation), see the original bug [0].
The main problem here is: how do we know what exactly IPs to auto allocate
for VIPs when needed roles are in different nodegroups (i.e. in different
IP networks)?
For example
Hi,
> b) Make the snapshot location share the diskspace of /var/log?
+1 for that. And +1 for using hard links to save space during snapshot
creation.
Regards,
Alex
On Tue, Jan 12, 2016 at 12:12 PM, Artem Panchenko
wrote:
> Hi,
>
> doesn't matter how /var partition is
> accurately wipe only partition table and do not touch any other data
As Andrew said already, in such case LVM meta data will remain on the hard
drive. So if you remove partition table, reboot the node (env reset), then
configure exactly the same partition table (like when you use the same
Hi,
> I want to propose not to wipe disks and simply unset bootable flag from
node disks.
AFAIK, removing bootable flag does not guarantee that system won't be
booted from the local drive. This is why erase_node is needed.
Regards,
Alex
On Fri, Dec 25, 2015 at 8:59 AM, Artur Svechnikov
+1
On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:
> +1
>
> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
> tleontov...@mirantis.com> wrote:
>
>> Hi guys,
>> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>>
>> Artem cares about fuel-ostf
+1
On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich <
tleontov...@mirantis.com> wrote:
> Absolutely agree
>
> +1
>
>
>
>
> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy <
> asledzins...@mirantis.com> wrote:
>
>> Hi guys,
>> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>>
Hi,
just finished deployment of multirack env with ceph and external LB (not a
standard multi-rack deployment scheme, actually, but still):
http://paste.openstack.org/show/482610/
As you can see it works just fine in multirack.
Also, we're running 'deploy_ceph_ha_nodegroups' system test as a
015 17:03, Bogdan Dobrelya wrote:
> > On 01.12.2015 11:28, Aleksandr Didenko wrote:
> >> Hi,
> >>
> >>> pregenerated catalogs for the Noop tests to become the very first
> >>> committed state in the data regression process has to be put in the
> >&g
Hi,
having or not having docker on Fuel master affects mostly Fuel node
deployment related scripts/manifests. If we need to fix a bug in Nailgun or
OSTF - we can fix it in their codebase and it does not really matter
whether we run Nailgin or OSTF inside docker or not. The same goes for all
the
Hi,
looks good to me.
Regards,
Alex
On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych
wrote:
> Hi fuelers,
>
> We want to throw KVM/QEMU options from Wizard and instead of them leave
> only one: Libvirt [0]. Libvirt option enables QEMU by default and there are
> still
Hi,
> Downgrading for no reason could bring us to big trouble and bad user
experience
+1 to this. Let's keep PostgreSQL 9.3.
Regards,
Alex
On Mon, Dec 14, 2015 at 2:04 PM, Artem Silenkov
wrote:
> Hello!
>
> Vote for update.
>
> 1. We have already shipped 9.3 in
Hi,
I suppose disabling purge_configs is the only solution here. Running all
the configuration in a single task does not fit well into deployment
granularization philosophy.
Regards,
Alex
On Fri, Dec 11, 2015 at 12:13 PM, Dmitry Bilunov
wrote:
> Hello.
>
> I am trying
Hi,
I agree, let's do this.
Regards,
Alex
On Fri, Dec 11, 2015 at 1:08 PM, Bartłomiej Piotrowski <
bpiotrow...@mirantis.com> wrote:
> Hi folks,
>
> my sense of aesthetics was slightly disturbed when I saw that the mounts
> fact[1] is implemented by joining mount points using a comma.
>
> It
Hi,
that's great to know about this new button behaviour, because I was going
to file a bug few days ago when I was not able to find "Stop" button on UI.
But then I updated to a more recent ISO and the button "appeared" again.
Now I know what that was, thank you. And I can't tell that my own
+1
On Wed, Dec 2, 2015 at 9:13 AM, Julia Aranovich
wrote:
> +1
>
> On Tue, Dec 1, 2015 at 10:29 PM Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> +1
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Tue, Dec 1, 2015
Hi,
> pregenerated catalogs for the Noop tests to become the very first
> committed state in the data regression process has to be put in the
> *separate repo*
+1 to that, we can put this new repo into .fixtures.yml
> note, we could as well move the tests/noop/astute.yaml/ there
+1 here too,
Hi,
in your plan you need to have an item about updating ISO on fuel-library CI
gates.
Regards,
Alex
On Tue, Dec 1, 2015 at 4:11 PM, Sergii Golovatiuk
wrote:
> Hi,
>
> On Tue, Dec 1, 2015 at 3:58 PM, Dmitry Teselkin
> wrote:
>
>> Hello,
>>
>>
Hi,
I think something like this would be more flexible:
$swift_proxy_roles = hiera('swift_proxy_roles', ['primary-controller',
'controller'])
$swift_storage_roles = hiera('swift_storage_roles', ['primary-controller',
'controller'])
# ...
$swift_nodes =
+1 from me
On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin
wrote:
> 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
Hi,
Mike, that's exactly how you can use this VIPs allocation functionality.
Nailgun will save that VIP so it's not going to be auto-assigned to any
node and serialize it into astute.yaml (vip_name: IP). After that you can
get your VIP via Hiera and use it in your deployment scripts.
Guys, could
Hi,
let me try to rephrase this a bit and Bogdan will correct me if I'm wrong
or missing something.
We have a set of top-scope manifests (called Fuel puppet tasks) that we use
for OpenStack deployment. We execute those tasks with "puppet apply". Each
task supposed to bring target system into
Hi,
please note that such tasks are executed inside 'mcollective' docker
container, not on the Fuel master host system.
Regards,
Alex
On Tue, Nov 3, 2015 at 10:41 PM, Igor Kalnitsky
wrote:
> Hi Javeria,
>
> Try to use 'master' in 'role' field. Example:
>
> - role:
Hi,
+1 from me.
Regards,
Alex
On Wed, Sep 2, 2015 at 5:00 PM, Vladimir Kuklin
wrote:
> +1 and also he is in US timezone, which should help us cover the globe
> with Continuous Review process.
>
> On Wed, Sep 2, 2015 at 3:45 PM, Dmitry Borodaenko <
>
Hi,
I'm all in for any formalization and automation of review process. The only
concern that I see here is about core reviewers involvement metrics. If we
succeed in reducing the load on core reviewers, it will mean that core
reviewers will do less code reviews. This could lead to core reviewer
, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich
tleontov...@mirantis.com wrote:
Hi,
Alex vote +1 to use astute tag as well to get possibility identify issues
related to astute in the most easy way.
Regards,
Tanya
On Fri, Jul 17, 2015 at 3:59 PM, Aleksandr Didenko
adide
Hi,
I think that checking commit message compliance to commit message
guidelines (for example ending the first line with dot) is part of CI jobs,
and they will vote -1 if message is wrongly structured.
Maciej, we don't have such checks at the moment. You can craft any commit
message you want
Hi,
I agree with Sergii, the patch had some problems only with tests which are
already resolved. So I vote for FFE.
P.S. We've just merged it.
Regards,
Alex
On Mon, Jul 27, 2015 at 3:30 PM, Sergii Golovatiuk sgolovat...@mirantis.com
wrote:
Hi,
I have checked the code. After fixing tests,
Hi,
we were not able to get a working deployment with fernet token support
patches, mostly due to issues with keys generation and deployment
mechanism. I've also spend some time debugging problems with this and I
think it's too risky to land it in 7.0. So I vote for postponing it till
8.0.
Hi,
guys, we're about to switch keystone to apache wsgi by merging [0]. Just
wanted to make sure everyone is aware of this change.
If you have any questions or concerns let's discuss them in this thread.
Regards,
Alex
[0] https://review.openstack.org/#/c/204111/
Hi,
Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?
Nope. I'm with you :)
Many people prefer vim UX instead of wandering through the semi-graphical
interface.
Are those ppl developers or
Hi,
I think we should just fix the bug to make nodes.yaml match with the data
in astute.yaml. Because 'nodes' Hiera key is also used for /etc/hosts
update. I've raised bug priority to high.
Regards,
Alex
On Wed, Jul 22, 2015 at 2:42 PM, Irina Povolotskaya
ipovolotsk...@mirantis.com wrote:
Hi
,
On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
wrote:
Hi,
I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script
Hi,
as we decided on the recent Fuel weekly IRC meeting, we need to align LP
fuel-* groups with our teams and bug confirmation queues/duties. We decided
to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have
2 members each. So from now on please assign bugs about provisioning
Hi,
I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build process and CI jobs.
Regards,
Alex
On Thu, Jul 16, 2015 at 11:17 PM,
Hi,
guys, what if we simplify things a bit? All we need is:
1. Remove all the community modules from fuel-library.
2. Create 'Puppetfile' with list of community modules and their versions
that we currently use.
3. Make sure all our customizations are proposed to the upstream modules
Hi,
just wanted to mention another tool to work with 'Puppetfile' - r10k:
https://github.com/puppetlabs/r10k/blob/master/doc/puppetfile.mkd
Regards,
Alex
On Wed, Jun 24, 2015 at 11:04 PM, Paul Belanger pabelan...@redhat.com
wrote:
On 06/23/2015 01:51 PM, Alex Schultz wrote:
Hello everyone,
/fuellib_tasks_graph_check/
Regards,
Aleksandr
On Wed, Feb 18, 2015 at 4:02 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
Hi, Seb
Very fair point, thank you. We need to add this to our jobs for unittests
run and syntax check. I am adding Aleksandr Didenko into the loop as he is
currently working
/fuel-library/tree/master/deployment/puppet/osnailyfacter/modular
[6] https://fuel-jenkins.mirantis.com/job/fuellib_tasks_graph_check
--
Regards,
Aleksandr Didenko
__
OpenStack Development Mailing List (not for usage questions
, Aleksandr Didenko adide...@mirantis.com
wrote:
Mike,
Any objections / additional suggestions?
no objections from me, and it's already covered by LP 1415116 bug [1]
[1] https://bugs.launchpad.net/fuel/+bug/1415116
On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov
mscherba
Mike,
Any objections / additional suggestions?
no objections from me, and it's already covered by LP 1415116 bug [1]
[1] https://bugs.launchpad.net/fuel/+bug/1415116
On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Folks,
one of the things we should not
developer how to handle some particular task for
different roles: developer can write 2 different tasks (one for
'primary-controller' and the other one for 'controller'), or he can write
the same task for both groups and handle differences inside the task.
--
Regards,
Aleksandr Didenko
On Wed, Jan 28
3rd option is about using rsyncd that we run under xinetd on primary
controller. And yes, the main concern here is security.
On Wed, Jan 28, 2015 at 6:04 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
Hi.
I'm vote for second option, cause if we will want to implement some
unified
suppose, it's time to finally drop
support for Simple mode in Fuel :)
[1] https://blueprints.launchpad.net/fuel/+spec/single-controller-ha
[2] https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
--
Regards,
Aleksandr Didenko
On Tue, Aug 26, 2014 at 9:25 AM, Mike Scherbakov
://docs.mirantis.com/fuel-dev/develop/module_structure.html#contributing-to-existing-fuel-library-modules
[2] https://review.openstack.org/141022
Regards,
Aleksandr
On Fri, Nov 21, 2014 at 8:07 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On 21 Nov 2014, at 17:15, Aleksandr Didenko adide
Hi,
Dmitriy, first of all, monit can provide HTTP interface for communication -
so it's possible to poll that this interface to get info or even control
monit (stop/start/restart service, stop/start monitoring of a service,
etc). Secondly, you can configure different triggers in monit and set
Hi,
according to [1] you should be able to use:
puppet_modules: puppet/:/etc/puppet/modules/
This is valid string yaml parameter that should be parsed just fine.
[1]
https://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62
Regards
--
Alex
On Mon, Nov 24,
/glance)_config resources have needed values in the
puppet catalog. Since we're not going to sync 'openstack' module with the
upstream, such tests will remain intact until we change them, and they
won't be affected by other modules sync/merge (keystone, cinder, nova, etc).
--
Regards,
Aleksandr
/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33
[3] https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements
Regards,
Aleksandr Didenko
___
OpenStack-dev mailing list
OpenStack-dev
://review.openstack.org/#/c/126559/
[4] http://pastebin.com/HH0bUtYc
Regards,
Aleksandr Didenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-library/blob/master/deployment/puppet/galera/manifests/init.pp#L206-L212
Regards,
Aleksandr Didenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1 for both.
On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1.
On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
Hi, Fuelers
As you may have noticed our project is growing continuously. And this
imposes a requirement of
Hi,
as for execution of arbitrary code across the OpenStack cluster - I was
thinking of mcollective + fact filters:
1) we need to start using mcollective facts [0] [2] - we don't
use/configure this currently
2) use mcollective execute_shell_command agent (or any other agent) with
fact filter [1]
Hi,
we're running only 3 containers in privileged mode: cobbler, rsyslog and
mcollective. Running all the containers in privileged mode is not a good
idea for security reasons. Docker manages DNAT forwarding itself, so it
does not create any overhead for us.
Is there any real benefits of using
mean which version should we use in 5.0.1, for example? As far as I
understand @DmitryB, it have to be 2014.1-5.0.1. Am I right?
Thanks,
Igor
On Tue, Jul 1, 2014 at 8:47 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
Hi,
my 2 cents:
1) Fuel version (+1 to Dmitry)
2) Could you
Hi,
my 2 cents:
1) Fuel version (+1 to Dmitry)
2) Could you please clarify what exactly you mean by our patches / our
first patch?
On Tue, Jul 1, 2014 at 8:04 PM, Dmitry Borodaenko dborodae...@mirantis.com
wrote:
1) Puppet manifests are part of Fuel so the version of Fuel should be
used.
Hi,
If user runs some experiments with creating/deleting clusters, then taking
care of old logs is under user's responsibility, I suppose. Fuel configures
log rotation with compression for remote logs, so old logs will be gzipped
and will not take much space.
In case of additional boolean
or
such situation is ok?
- Igor
On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
Hi,
If user runs some experiments with creating/deleting clusters, then
taking care of old logs is under user's responsibility, I suppose. Fuel
configures log rotation
for all nodes at once too.
- Igor
On Tue, Jun 24, 2014 at 6:38 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
Yeah, I thought about diagnostic snapshot too. Maybe it would be better
to implement per-environment diagnostic snapshots? I.e. add diagnostic
snapshot generate/download buttons
1 - 100 of 101 matches
Mail list logo