Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core

[Kyrylo Galanov]

+1

On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn 
wrote:

> +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 and my +1
> >>
> >> +1 from my side!
> >>
> >> >
> >> > --
> >> > Best regards,
> >> > Sergii Golovatiuk,
> >> > Skype #golserge
> >> > IRC #holser
> >> >
> >> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk
> >> > > wrote:
> >> >
> >> > Hi,
> >> >
> >> > I would like to nominate Maksim Malchuk to Fuel-Library Core team.
> >> > He’s been doing a great job so far [0]. He’s #2 reviewer and #2
> >> > contributor with 28 commits for last 90 days [1][2].
> >> >
> >> > Fuelers, please vote with +1/-1 for approval/objection. Voting
> will
> >> > be open until July of 4th. This will go forward after voting is
> >> > closed if there are no objections.
> >> >
> >> > Overall contribution:
> >> > [0] http://stackalytics.com/?user_id=mmalchuk
> >> > Fuel library contribution for last 90 days:
> >> > [1]
> >> > 
> http://stackalytics.com/report/contribution/fuel-library/90
> >> > http://stackalytics.com/report/users/mmalchuk
> >> > List of reviews:
> >> > [2]
> >> >
> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z
> >> > --
> >> > Best regards,
> >> > Sergii Golovatiuk,
> >> > Skype #golserge
> >> > IRC #holser
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> >> --
> >> Best regards,
> >> Bogdan Dobrelya,
> >> Irc #bogdando
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel]

[Kyrylo Galanov]

Hi team,

An issue with rsync was recently reported [0].
We have a symlink 'liberty-9.0/modules/osnailyfacter/modular/master' to
examples directory in a fuel master node. However, rsync does not copy the
symlink to slave nodes. Being easy to fix (by adding -l flag) this issue
raises a question: do we need the symlink in prod? Can we just remove it
from package?


[0] https://bugs.launchpad.net/fuel/+bug/1538624

Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] network_metadata hash keys on astute.yaml

[Kyrylo Galanov]

Hi,

I would like to remind that we are close to code freeze and bug is still
there. Moreover, new bug reports continue to be submitted [3].
Please, do not ignore the discussion.

[3] https://bugs.launchpad.net/fuel/+bug/1557417

On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:

> 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 I wanted to change. So node keys in that hash should remain
> immutable.
>
> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
> was working before (and does not require new patches like [0]) and we're
> too late in the release cycle to change keys to '{uid}'.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/284046/
>
> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov <kgala...@mirantis.com>
> wrote:
>
>> Hi,
>>
>> Currently nailgun and puppet process network_metadata hash slightly
>> different.
>> Nailgun uses short hostname as a hash key for each node, while library
>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>> deployment failure.
>>
>> During code review[0] it turned out that there are two points of view,
>> which approach is correct [1].
>> Both are one-line fixes, however it have been lasting too long with no
>> result.
>>
>> I would like to start a discussion with a hope to close the issue shortly.
>>
>> Best regards.
>> Kyrylo
>>
>> [0] https://review.openstack.org/#/c/284046/
>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] network_metadata hash keys on astute.yaml

[Kyrylo Galanov]

Hi,

Currently nailgun and puppet process network_metadata hash slightly
different.
Nailgun uses short hostname as a hash key for each node, while library code
assumes that key is always 'node-{uid}'. Sometimes it can result in a
deployment failure.

During code review[0] it turned out that there are two points of view,
which approach is correct [1].
Both are one-line fixes, however it have been lasting too long with no
result.

I would like to start a discussion with a hope to close the issue shortly.

Best regards.
Kyrylo

[0] https://review.openstack.org/#/c/284046/
[1] https://bugs.launchpad.net/fuel/+bug/1538220
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

[Kyrylo Galanov]

+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]
>> to
>> separate fuel-virtualbox [3] git repo, I propose to update
>> fuel-virtualbox-core
>> team [4] by adding Maksim Malchuk. Maksim is the main contributor to these
>> scripts during Mitaka release cycle [5]
>>
>> Fuel Cores, please vote.
>>
>> [1].
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html
>> [2]. https://github.com/openstack/fuel-main
>> [3]. https://github.com/openstack/fuel-virtualbox
>> [4]. https://review.openstack.org/#/admin/groups/1299,members
>> [5]. https://github.com/openstack/fuel-virtualbox/commits/master
>>
>> --
>> Sergey
>> DevOps Engineer
>> IRC: SergK
>> Skype: Sergey_kul
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Kyrylo Galanov]

Finally! +2 !

On Fri, Feb 26, 2016 at 9:08 PM, Roman Vyalov  wrote:

> +1
>
> On Fri, Feb 26, 2016 at 12:31 PM, Aleksey Kasatkin  > wrote:
>
>> +1
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Feb 25, 2016 at 11:59 PM, Sergey Vasilenko <
>> svasile...@mirantis.com> wrote:
>>
>>> +1
>>>
>>>
>>> /sv
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Wildcards instead of

[Kyrylo Galanov]

Adding this to future features.

On Mon, Feb 22, 2016 at 8:33 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:

> On 22.02.2016 10:28, Kyrylo Galanov wrote:
> > Would namespaces be compatible with existing plugins?
>
> It should be, if the default namespace will be "core"
>
> >
> > On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya <bdobre...@mirantis.com
> > <mailto:bdobre...@mirantis.com>> wrote:
> >
> > On 20.02.2016 10:29, Evgeniy L wrote:
> > > Hi,
> > >
> > > +1 to Igor, plugin developer should be able to granularly define
> what
> > > she/he wants to be executed on the node, without assumptions from
> our side.
> > >
> > > `exclude` - field doesn't look like a good solution to me, it will
> be
> > > hard to support and migrate plugins to newer version OpenStack
> release.
> > >
> > > I would suggest to solve it differently, lets define namespaces,
> which
> > > we will be able to use to identify tasks from core, with prefix
> > > "std:role-name" or "core:role-name", also in the same way plugin
> or a
> > > group of plugins will be able to define their namespaces
> "lma:role-name"
> > > or "detached:keystone", so for library tasks you will have
> something
> > > like that:
> > >
> > > groups: ['/std:.*/']
> > >
> > > or
> > >
> > > groups: ['/core:.*/']
> > >
> > > It's natural to have such thing, because it's similar to what is in
> > > Python/Ruby (modules) or in C++ (namespaces).
> > >
> >
> > Big +1 to namespaces
> >
> > > Thanks,
> > >
> > > On Fri, Feb 19, 2016 at 6:02 PM, Aleksandr Didenko
> > > <adide...@mirantis.com <mailto:adide...@mirantis.com>
> > <mailto:adide...@mirantis.com <mailto:adide...@mirantis.com>>>
> wrote:
> > >
> > > > 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 were executed
> > > everywhere anyway.
> > >
> > > Regards,
> > > Alex
> > >
> > > On Fri, Feb 19, 2016 at 3:22 PM, Bulat Gaifullin
> > > <bgaiful...@mirantis.com <mailto:bgaiful...@mirantis.com>
> > <mailto:bgaiful...@mirantis.com <mailto:bgaiful...@mirantis.com>>>
> > wrote:
> > >
> > >
> > > > On 19 Feb 2016, at 17:09, Igor Kalnitsky
> > > <ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>
> > <mailto:ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>>>
> > wrote:
> > > >
> > > > Kyrylo G. wrote:
> > > >> So who is voting for the path to be abandoned?
> > > >
> > > > 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.
> > > >
> > > >
> > > > Kyrylo G. wrote:
> > > >> By the way, there is already a task running by the
> > wildcard:
> > > >>
> > >
> >
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4
> > > >
> > > > Yes, exactly, but the thing is that our original task
> > for setuping
> > > > repos was executed on all nodes before, including ones
> > provided by
> > > > plugins. Making it executing on core nodes only may break
> > > plugins that
> > > > rely on it. So generally, it's about backward
> compatibility.
> > > >
> > > >
> > > > Bulat G. 

Re: [openstack-dev] [Fuel] Wildcards instead of

[Kyrylo Galanov]

Would namespaces be compatible with existing plugins?

On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:

> On 20.02.2016 10:29, Evgeniy L wrote:
> > Hi,
> >
> > +1 to Igor, plugin developer should be able to granularly define what
> > she/he wants to be executed on the node, without assumptions from our
> side.
> >
> > `exclude` - field doesn't look like a good solution to me, it will be
> > hard to support and migrate plugins to newer version OpenStack release.
> >
> > I would suggest to solve it differently, lets define namespaces, which
> > we will be able to use to identify tasks from core, with prefix
> > "std:role-name" or "core:role-name", also in the same way plugin or a
> > group of plugins will be able to define their namespaces "lma:role-name"
> > or "detached:keystone", so for library tasks you will have something
> > like that:
> >
> > groups: ['/std:.*/']
> >
> > or
> >
> > groups: ['/core:.*/']
> >
> > It's natural to have such thing, because it's similar to what is in
> > Python/Ruby (modules) or in C++ (namespaces).
> >
>
> Big +1 to namespaces
>
> > Thanks,
> >
> > On Fri, Feb 19, 2016 at 6:02 PM, Aleksandr Didenko
> > <adide...@mirantis.com <mailto:adide...@mirantis.com>> wrote:
> >
> > > 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 were executed
> > everywhere anyway.
> >
> > Regards,
> > Alex
> >
> > On Fri, Feb 19, 2016 at 3:22 PM, Bulat Gaifullin
> > <bgaiful...@mirantis.com <mailto:bgaiful...@mirantis.com>> wrote:
> >
> >
> > > On 19 Feb 2016, at 17:09, Igor Kalnitsky
> > <ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>>
> wrote:
> > >
> > > Kyrylo G. wrote:
> > >> So who is voting for the path to be abandoned?
> > >
> > > 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.
> > >
> > >
> > > Kyrylo G. wrote:
> > >> By the way, there is already a task running by the wildcard:
> > >>
> >
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4
> > >
> > > Yes, exactly, but the thing is that our original task for
> setuping
> > > repos was executed on all nodes before, including ones
> provided by
> > > plugins. Making it executing on core nodes only may break
> > plugins that
> > > rely on it. So generally, it's about backward compatibility.
> > >
> > >
> > > Bulat G. wrote:
> > >> This tasks should run on all nodes and it does not matter,
> > the node
> > >> has role from plugin or core-role.
> > >
> > > Nope, they shouldn't. Why do I need to install the following
> > packages
> > >
> > >  'screen',
> > >  'tmux',
> > >  'htop',
> > >  'tcpdump',
> > >  'strace',
> > >  'fuel-misc',
> > >  'man-db',
> > >  'fuel-misc',
> > >  'fuel-ha’
> > >
> > It is big problem?
> >
> > > if I have no plans to use them? As a deployer engineer, I'd
> prefer to
> > > keep my role as clear as possible, and decide what to install
> in my
> > > own way.
> >
> > IMO: The plugin developer wants to install additional
> > applications to extend functionality, It do not want configure
> > low-level things, like specify some banch of task for configure
> > network, configure repositories etc.
> > How can we manage new node if network is not configured or
> > fuel-agent is not installed?
> >
> >   

Re: [openstack-dev] [Fuel] Wildcards instead of

[Kyrylo Galanov]

Hi,

So who is voting for the path to be abandoned?

By the way, there is already a task running by the wildcard:
https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4
However, it this case it might work with plugins.

Best regards,
Kyrylo

On Fri, Feb 19, 2016 at 1:09 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Hey Kyrylo,
>
> As it was mentioned in the review: you're about to break roles defined
> by plugins. That's not good move, I believe.
>
> Regarding 'exclude' directive, I have no idea what you're talking
> about. We don't support it now, and, anyway, there should be no
> difference between roles defined by plugins and core roles.
>
> - Igor
>
> On Thu, Feb 18, 2016 at 12:53 PM, Kyrylo Galanov <kgala...@mirantis.com>
> wrote:
> > Hello,
> >
> > We are about to switch to wildcards instead of listing all groups in
> tasks
> > explicitly [0].
> > This change must make deployment process more obvious for developers.
> > However, it might lead to confusion when new groups are added either by
> > plugin or fuel team in future.
> >
> > As mention by Bogdan, it is possible to use 'exclude' directive to
> mitigate
> > the risk.
> > Any thoughts on the topic are appreciated.
> >
> >
> > [0] https://review.openstack.org/#/c/273596/
> >
> > Best regards,
> > Kyrylo
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Wildcards instead of

[Kyrylo Galanov]

Hello,

We are about to switch to wildcards instead of listing all groups in tasks
explicitly [0].
This change must make deployment process more obvious for developers.
However, it might lead to confusion when new groups are added either by
plugin or fuel team in future.

As mention by Bogdan, it is possible to use 'exclude' directive to mitigate
the risk.
Any thoughts on the topic are appreciated.


[0] https://review.openstack.org/#/c/273596/

Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][library] Switching to external fixtures for integration Noop tests

[Kyrylo Galanov]

Hello Bogdan,

I hope I am not the one of the context. Why do we separate fixtures for Noop
 tests from the repo?
I can understand if while noop test block was carried out to a separate repo
.

On Tue, Jan 26, 2016 at 1:54 PM, Bogdan Dobrelya 
wrote:

> We are going to switch [0] to external astute.yaml fixtures for Noop
> tests and remove them from the fuel-library repo as well.
> Please make sure all new changes to astute.yaml fixtures will be
> submitted now to the new location. Related mail thread [1].
>
> [0]
>
> https://review.openstack.org/#/c/272480/1/doc/noop-guide/source/noop_fixtures.rst
> [1]
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082888.html
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Stop deployment can break production cluster. How we should avoid it?

[Kyrylo Galanov]

Hello,

Why don't we introduce additional state for nodes like 're-deploying'. If
deployment was stopped we don't erase nodes with this state, but change the
status to 'error' or 'ready' , for example.
Or we can add warning message that 'stop' button would destroy every and
each node.

On Fri, Jan 22, 2016 at 8:15 PM, Vladimir Sharshov 
wrote:

> Hi!
>
> I also vote for solution "mark a cluster 'operational' after successful
> deployment". It is simple and guarantee that we do not erase main
> components.
> Also it will free resources to support stop/rerun(resume) feature on task
> based deployment which will works much better (without node destroy as side
> affect)
>
> On Fri, Jan 22, 2016 at 8:09 PM, Igor Kalnitsky 
> wrote:
>
>> Dmitry,
>>
>> > We can mark a cluster 'operational' after successful deployment. And we
>> > can disable 'stop' button on this kind of clusters.
>>
>> I think this is a best solution so far. Moreover, I don't know how to
>> fix it properly since there could be a lot of questions how this
>> button should behave at all.
>>
>> Taking into account all this, I propose to solve this issue as a
>> blueprint (so we can think and cover all edge cases in the spec) or
>> drop stop button functionality at all.
>>
>> The latest, perhaps, may be a good solution. I don't know how often
>> someone use Stop deployment.
>>
>>
>> Bogdan,
>>
>> > This is the critical issue. The *worst* of possible situations for
>> > cluster operations. I believe this should be covered by a dedicated
>> > bulletin issued, the stop action shall be disabled for all releases as
>> > emergency fix, and fixed by next maintenance updates.
>>
>> It wasn't always the case. Some time ago we didn't execute any tasks
>> on controllers when adding new nodes. It's become a case, I assume,
>> since Fuel 8.0, when we start executing netconfig and other puppet
>> task on each deployment run.
>>
>> So we need to investigate in which release we have introduced
>> re-execution some tasks on controllers, and only then thinking about
>> bulletins.
>>
>>
>> Thanks,
>> Igor
>>
>> On Fri, Jan 22, 2016 at 1:06 PM, Bogdan Dobrelya 
>> wrote:
>> > On 22.01.2016 11:45, Dmitry Pyzhov wrote:
>> >> Guys,
>> >>
>> >> There is a tricky bug with our 'stop deployment'
>> >> feature: https://bugs.launchpad.net/fuel/+bug/1529691
>> >>
>> >> It cannot be fixed easily because it is a design flaw. By design we
>> >> cannot leave a node in unpredictable state. So we move all nodes that
>> >> are not in ready state back to bootstrap.
>> >>
>> >> But when user adding a node and deploying cluster system reruns puppet
>> >> on controllers. If user press 'stop' button controllers will be erased.
>> >> Cluster will be destroyed. Definitely this is not expected behaviour.
>> >
>> > This is the critical issue. The *worst* of possible situations for
>> > cluster operations. I believe this should be covered by a dedicated
>> > bulletin issued, the stop action shall be disabled for all releases as
>> > emergency fix, and fixed by next maintenance updates.
>> >
>> >>
>> >> Taking into account that we are going to rewrite this feature in 9.0
>> and
>> >> we are close to HCF there is no value in major changes for this feature
>> >> in 8.0. Let's do a simple workaround.
>> >>
>> >> We can mark a cluster 'operational' after successful deployment. And we
>> >> can disable 'stop' button on this kind of clusters.
>> >>
>> >> Any concerns or other proposals?
>> >>
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> > Bogdan Dobrelya,
>> > Irc #bogdando
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Kyrylo Galanov]

Hi,

I am not QA engineer at all, but it is always a pleasure to work with
Artem. I would vote +1.

--
Kyrylo

On Wed, Dec 23, 2015 at 7:20 PM, Igor Marnat  wrote:

> Folks,
> I'm not a fuel-qa core, but if I was, I'd vote with +1:)
>
> I'm really impressed with quality of analysis which Artem provides in bug
> reports and his overall help with bugs resolving. Keep going!
>
> Regards,
> Igor Marnat
>
> On Wed, Dec 23, 2015 at 8:05 PM, Igor Kalnitsky 
> wrote:
>
>> Artem is doing a great job! Definitely +1.
>>
>> On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
>>  wrote:
>> > +1
>> >
>> > Regards,
>> > Bulat Gaifullin
>> > Mirantis Inc.
>> >
>> >
>> >
>> > On 23 Dec 2015, at 17:29, Aleksey Kasatkin 
>> wrote:
>> >
>> > +1
>> >
>> > Aleksey Kasatkin
>> >
>> >
>> > On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko <
>> adide...@mirantis.com>
>> > wrote:
>> >>
>> >> +1
>> >>
>> >> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich
>> >>  wrote:
>> >>>
>> >>> Absolutely agree
>> >>>
>> >>> +1
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy
>> >>>  wrote:
>> 
>>  Hi guys,
>>  I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>> 
>>  Artem has great technical expertise in fuel-qa and he developed a
>> lot of
>>  vital parts of framework. His first place in a number of commits is
>> a good
>>  proof of that.
>>  His reviews are always thorough and consistent.
>>  Please, vote for Artem!
>> 
>>  [0]
>> 
>> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>> 
>>  --
>>  Thanks,
>>  Andrey Sledzinskiy
>>  QA Engineer,
>>  Mirantis, Kharkiv
>> 
>> 
>> 
>> __
>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe:
>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> >>>
>> >>>
>> >>>
>> >>>
>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] RabbitMQ in dedicated network

[Kyrylo Galanov]

Hello,

I would like to start discussion regarding the issue we have discovered
recently [1].

In a nutshell, if RabbitMQ is configured to run in separate mgmt/messaging
network it fails on building cluster.
While RabbitMQ is managed by Pacemaker and OCF script, the cluster is built
using FQDN. Apparently, FQDN resolves to admin network which is different
in this particular case.
As a result, RabbitMQ on secondary controller node fails to join to primary
controller node.

I can suggest two ways to tackle the issue: one is pretty simple, while
other is not.

The first way is to accept by design using admin network for RabbitMQ
internal communication between controller nodes.

The second way is to dig into pacemaker and RabbitMQ reconfiguration. Since
it requires to refuse from using common fqdn/node names, this approach can
be argued.


--
[1] https://bugs.launchpad.net/fuel/+bug/1528707

Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon]

[Kyrylo Galanov]

Hello,

When a file is uploaded to Glance, Swift through Horizon it is stored
locally in a temporary directory in Horizon server. This is inefficient
approach especially for big files.

I would suggest to implement 'proxy' upload to Glance, Swift using chunk
buffer instead of storing a file locally. It would eliminate such drawbacks
as potential free space exhaustion.

It would be awesome to add upload progress bar as well.

I look forward to your constructive replies.

Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon]

[Kyrylo Galanov]

Looks great. What is the estimated date / release for this feature to be
delivered?

On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev <tsuf...@mirantis.com> wrote:

> Please take a look at
> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
>
> On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov <kgala...@mirantis.com>
> wrote:
>
>> Hello,
>>
>> When a file is uploaded to Glance, Swift through Horizon it is stored
>> locally in a temporary directory in Horizon server. This is inefficient
>> approach especially for big files.
>>
>> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
>> buffer instead of storing a file locally. It would eliminate such drawbacks
>> as potential free space exhaustion.
>>
>> It would be awesome to add upload progress bar as well.
>>
>> I look forward to your constructive replies.
>>
>> Best regards,
>> Kyrylo
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Kyrylo Galanov]

Hi Team,

I have been testing fail-over after free disk space is less than 512 mb. (
https://review.openstack.org/#/c/240951/)
Affected node is stopped correctly and services migrate to a healthy node.

However, after free disk space is more than 512 mb again the node does not
recover it's state to operating. Moreover, starting the resources manually
would rather fail. In a nutshell, the pacemaker service / node should be
restarted. Detailed information is available here:
https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html

How do we address this issue?


Best regards,
Kyrylo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev