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
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]
27; 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 Didenko
On Wed, Nov 19, 2014 at 5:45 PM, Vladimir Kuklin
wrote:
> Fuelers
>
> I
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,
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
appr
oop tests, then it will get '-1' from CI and attract our
attention :)
[1]
http://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 Napier
> 4) do lrzipping as weak as possible during the development phase and
lrzip it strongly only when we do release
We create lrzip archive with compression level "2" (from 1-9 range, default
is 7). So we don't have much potential for improvement here. Here are some
tests:
== Bare metal 12 cpus, 32
+1 for both.
On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky
wrote:
> +1.
>
> On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin
> wrote:
> > Hi, Fuelers
> >
> > As you may have noticed our project is growing continuously. And this
> > imposes a requirement of increasing amount of core reviewers
parseyaml-with-hiera
[2] https://etherpad.openstack.org/p/fuel_hiera
[3] https://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
ithub.com/stackforge/fuel-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
b.com/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
OpenStac
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 paramet
> such situation is ok?
>
> - Igor
>
>
>
>
> On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko
> wrote:
>
>> Hi,
>>
>> If user runs some experiments with creating/deleting clusters, then
>> taking care of old logs is under user's responsib
for all nodes at once too.
>
> - Igor
>
>
> On Tue, Jun 24, 2014 at 6:38 PM, Aleksandr Didenko
> wrote:
>
>> Yeah, I thought about diagnostic snapshot too. Maybe it would be better
>> to implement per-environment diagnostic snapshots? I.e. add diagnostic
>> sna
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
wrote:
> 1) Puppet manifests are part of Fuel so the version of Fuel should be
> used. It is possible to h
you please clarify what exactly you mean by "our patches" /
>> > "our first patch"?
>>
>> I 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?
>>
>&g
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 some
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: 'master'
> stage: p
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
+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 captured while
>> doing reviews recently - we a
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 = get_nodes_hash_by_roles($network_m
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, as
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,
>>
>> We're almost got green BVT on custom CentOS7 ISO a
+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 at 6:15 PM, Aleksey Kasatk
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
exper
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 [1].
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 wrote:
> Hi all,
>
> as you ma
y order it: netconfig on non-controllers 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
wrote:
> Hi all,
>
> please be aware that now we have two netconfi
ssociated 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 Wed,
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
x27;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,
>>>
>>> in Fue
rds,
Alex
[0] https://review.openstack.org/324307
[1] http://paste.openstack.org/show/508319/
On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko
wrote:
> Hi,
>
> YAQL expressions support for task dependencies has been added to Nailgun
> [0]. So now it's possible to fix network configuration id
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 wrote:
>
>> Hi,
>>
>> a bi
ins/+bug/1591117
On Tue, Jun 7, 2016 at 11:46 AM, Aleksandr Didenko
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
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, Jun 27, 2016 at 4:42 PM, Serg
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.
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
ks
ordering 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 Didenk
https://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
wrote:
> Hi Alex
>
> +1 to your proposal - this is long-awaited change.
>
> On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko
> wrote:
&g
nstack.org/302313
On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko
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 your patch, then plea
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 wrote:
>
> On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko
> wrote:
>
>> Hi,
>>
>> thanks to Di
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 to pick a way of making p
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 tur
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 fuel-7.0. Downgrading such comp
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 Op
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 be possibility to change
dan 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
> >>> *se
+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.
>>
>>
+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
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 pa
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
wrote:
> 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
defaul
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 big, diagnostic snapshot
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 '
s out-of-box.
True. But we're going block deployment 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
wrote:
> On 15.01.2016 10:19, Aleksandr Di
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,
> Sergii Golovatiuk,
> Skype
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"
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
wrote:
> 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 nod
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
wrote:
> Hi,
>
> I would also prefer second solution. The only real downside of it is the
> possibility to configure invalid cluster (
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?).
ty array. 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, A
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
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 lea
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,
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, Al
Alex,
>
> On Jul 17, 2015 4:32 AM, "Aleksandr Didenko"
> 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
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 a
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,
> 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 e
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,
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.
Regard
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 wrote:
> Hi,
>
> I have checked the code. After fixing tests, this patch maybe includ
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 a
gned to fuel-library.
>
> Thanks,
> Igor
>
> On Fri, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich
> wrote:
> > Hi,
> >
> > Alex vote +1 to use astute tag as well to get possibility identify issues
> > related to astute in the most easy way.
> >
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
de
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 <
> dborodae...@mirantis.com> wrote:
>
>> Huge
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
wrote:
> On 06/23/2015 01:51 PM, Alex Schultz wrote:
>
>> Hello everyone,
>>
>> I took some
2, 2016 at 10:19 PM, Andrew Woodward wrote:
>
>
> On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko
> wrote:
>
>> Hi,
>>
>>
>> > So what is open? The composition layer.
>>
>> We can have different composition layers for every release and it&#x
> 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, configur
> 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 we
+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 amount of features, such a
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
h
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
htt
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 t
+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 add as a maintainer to fuel-library to take my
+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 we've successfully moved [1] virtual-box scripts from fuel-main
>>> [2
аписав(ла):
> >>>
> >>> AFAIC, it is better to remove by name then. Otherwise, you do not know
> >>> what VIPs you are removing.
> >>> Another option - remove "built-in" VIPs using some specific expression.
> >>> Anyway, you
> 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
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
704
> >
> > 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 6:27 PM, Aleksandr Didenko &g
before. I 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,
it will
be up to the task 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.
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
wrote:
> Hi.
> I'm vote for second option, cause if we will want to implement some
> unified hierarchy (like Fuel as CA
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
wrote:
> Folks,
> one of the things we should not forget about - is out Fuel
.com
>> --
>> Igor Belikov
>> Fuel DevOps
>> ibeli...@mirantis.com
>>
>>
>>
>>
>>
>> On 29 Jan 2015, at 13:42, Aleksandr Didenko
>> wrote:
>>
>> Mike,
>>
>> > Any objections / additional suggestions?
>>
ithub.com/stackforge/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
m/job/fuellib_tasks_graph_check/
Regards,
Aleksandr
On Wed, Feb 18, 2015 at 4:02 PM, Vladimir Kuklin
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
+1
On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko
wrote:
> +1
>
>
> /sv
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: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 Tue, Sep 6, 2016 at 11:31 A
+1
On Thu, Sep 8, 2016 at 11:06 AM, Sergey Vasilenko
wrote:
> +1
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http:/
1 - 100 of 101 matches
Mail list logo
