Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core

2016-09-08 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 08 Sep 2016, at 12:05, Georgy Kibardin <gkibar...@mirantis.com> wrote:
> 
> +1
> 
> On Thu, Sep 8, 2016 at 11:54 AM, Igor Kalnitsky <i...@kalnitsky.org 
> <mailto:i...@kalnitsky.org>> wrote:
> Hey Fuelers,
> 
> I'd like to nominate Ilya for joining fuel-plugins-core group. He's a
> top contributor by both reviews [1] and commits [2] over the past
> release cycle. Fuel cores, please share your votes.
> 
> - Igor
> 
> [1] http://stackalytics.com/?module=fuel-plugins=newton=marks 
> <http://stackalytics.com/?module=fuel-plugins=newton=marks>
> [2] 
> http://stackalytics.com/?module=fuel-plugins=newton=commits 
> <http://stackalytics.com/?module=fuel-plugins=newton=commits>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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] Common fuel-core group for all Fuel projects

2016-09-06 Thread Bulat Gaifullin 
+1, I think it is good idea.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 05 Sep 2016, at 20:17, Maksim Malchuk <mmalc...@mirantis.com> wrote:
> 
> I want to clarify my previous reply
> +1
> but the new fuel-core would be a small group of the cores who are fully 
> involved in the whole Fuel project.
> 
> 
> On Mon, Sep 5, 2016 at 7:22 PM, Alexey Stepanov <astepa...@mirantis.com 
> <mailto:astepa...@mirantis.com>> wrote:
> -1
> This is seriously dangerous idea: core-reviewer in fuel-qa does not mean 
> exact skills for +2/W on fuel-octane, for example. Sometimes, because of 
> limited time, reviewer will press +W without understanding patch detail. In 
> repo, which he knows, he can fix issue later by itself, but only of he really 
> knows what he doing.
> 
> 
> пн, 5 сент. 2016 г., 19:14 Maksim Malchuk <mmalc...@mirantis.com 
> <mailto:mmalc...@mirantis.com>>:
> -1
> My vision - we should have something like super-core group with a smaller 
> number of the current core guys.
> This is because a lot of current core guys were switched to the other 
> projects and already out of the scope.
> Such guys still can be cores in their former projects and can help sometimes, 
> but only several guys can drive the Fuel.
> 
> P.S. we always can nominate new cores to the specific project individually if 
> you don't like the super-core group idea.
> 
> On Mon, Sep 5, 2016 at 6:39 PM, Andrew Maksimov <amaksi...@mirantis.com 
> <mailto:amaksi...@mirantis.com>> wrote:
> +1
> This is a good proposal, I also think we should have single fuel-core group 
> for all repos. In real life core reviewers won't set +2 or merge to repos 
> with which they are not familiar with. 
> 
> Regards,
> Andrey Maximov
> 
> On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov <vkozhuka...@mirantis.com 
> <mailto:vkozhuka...@mirantis.com>> wrote:
> Dear colleagues,
> 
> I'd like to suggest to use common fuel-core group for all Fuel projects 
> instead of having separate independent 'by-project' core groups like 
> 'fuel-astute-core' or 'fuel-agent-core'. 
> 
> Pros: 
> 1) It will be easier to access core members (timezone and holiday tolerance)
> 2) It will be easier to manage single core group (promote new members, remove 
> not active members)
> 
> Cons:
> 1) Less of flexibility. Permissions will be the same for all core reviewers 
> in all Fuel projects.
> 
> What do you think?
> 
> Vladimir Kozhukalov
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
>  
> <mailto:vgor...@mirantis.com>__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
>  
> <mailto:vgor...@mirantis.com>__
&

Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

2016-07-15 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 15 Jul 2016, at 16:08, Anastasia Urlapova <aurlap...@mirantis.com> wrote:
> 
> +1
> 
> On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy 
> <asledzins...@mirantis.com <mailto:asledzins...@mirantis.com>> wrote:
> Hi,
> I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops [1] core.
> 
> Alexey is doing great job improving fuel-qa and fuel-devops projects. 
> He's become an expert in code base in very short terms so I think he deserves 
> to be a part of fuel-qa/fuel-devops core team.  
> 
> Please, vote for Alexey!
> 
> [0] 
> http://stackalytics.com/?release=all=fuel-qa_id=astepanov-m=marks
>  
> <http://stackalytics.com/?release=all=fuel-qa_id=astepanov-m=marks>
> [1] 
> http://stackalytics.com/?release=all=fuel-devops_id=astepanov-m=marks
>  
> <http://stackalytics.com/?release=all=fuel-devops_id=astepanov-m=marks>
> 
> -- 
> 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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] Deprecation of fuel-mirror tool

2016-06-23 Thread Bulat Gaifullin 
Totally agree with this decision.

Vladimir, thank you for driving this activity.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 23 Jun 2016, at 13:31, Vladimir Kozhukalov <vkozhuka...@mirantis.com> 
> wrote:
> 
> Dear colleagues.
> 
> I'd like to announce that fuel-mirror tool is not going to be a part of Fuel 
> any more. Its functionality is to build/clone rpm/deb repos and modify Fuel 
> releases repository lists (metadata). 
> 
> Since Fuel 10.0 it is recommended to use other available tools for managing 
> local deb/rpm repositories. 
> 
> Packetary is a good example [0]. Packetary is ideal if one needs to create a 
> partial mirror of a deb/rpm repository, i.e. mirror that contains not all 
> available packages but only a subset of packages. To create full mirror it is 
> better to use debmirror or rsync or any other tools that are available.
> 
> To modify releases repository lists one can use commands which are to 
> available by default on the Fuel admin node since Newton.
> 
> # list of available releases
> fuel2 release list
> # list of repositories for a release
> fuel2 release repos list 
> # save list of repositories for a release in yaml format
> fuel2 release repos list  -f yaml | tee repos.yaml
> # modify list of repositories
> vim repos.yaml
> # update list of repositories for a release from yaml file 
> fuel2 release repos update  -f repos.yaml
> 
> They are provided by python-fuelclient [1] package and were introduced by 
> this [2] patch. 
> 
> 
> [0] https://wiki.openstack.org/wiki/Packetary 
> <https://wiki.openstack.org/wiki/Packetary> 
> [1] https://github.com/openstack/python-fuelclient 
> <https://github.com/openstack/python-fuelclient>
> [2] https://review.openstack.org/#/c/326435/ 
> <https://review.openstack.org/#/c/326435/>
> 
> 
> Vladimir Kozhukalov
> __
> 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] Nominating Dmitry Burmistrov for core reviewers of fuel-mirror

2016-06-22 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 22 Jun 2016, at 13:18, Sergey Kulanov <skula...@mirantis.com> wrote:
> 
> Hi All,
> 
> I'd like to nominate Dmitry Burmistrov for core reviewers of fuel-mirror. 
> Dmitry is one of the top
> contributors to the project [1, 2]. One of his latest activity  was related 
> to perestroika builder (add Xenial build target), build target separation for 
> CentOS, etc.
> 
> Fuel Cores, please support with +1
> 
> [1]. http://stackalytics.com/?module=fuel-mirror=commits=all 
> <http://stackalytics.com/?module=fuel-mirror=commits=all>
> [2]. http://stackalytics.com/?module=fuel-mirror=patches=all 
> <http://stackalytics.com/?module=fuel-mirror=patches=all>
> [3]. http://stackalytics.com/?module=fuel-mirror=marks=all 
> <http://stackalytics.com/?module=fuel-mirror=marks=all>
> [4]. http://stackalytics.com/?module=fuel-mirror=all 
> <http://stackalytics.com/?module=fuel-mirror=all>
> 
> -- 
> 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

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

2016-06-20 Thread Bulat Gaifullin 
Well, the agreement is reached. I added Ilya to fuel-web-core group. 

Ilya, congratulations! Will be happy to see even more thorough reviews from you!

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 08 Jun 2016, at 20:52, Bulat Gaifullin <bgaiful...@mirantis.com> wrote:
> 
> Hey Fuelers,
> 
> I'd like to nominate Ilya Kutukov for the fuel-web-core team.
> Ilya`s doing good reviews with detailed feedback [1],
> and has implemented custom graph execution engine for Fuel.
> Also Ilya`s implemented new database models for storing deployment tasks in 
> Fuel.
> 
> 
> Fuel Cores, please reply back with +1/-1.
> 
> [1] http://stackalytics.com/report/contribution/fuel-web/90 
> <http://stackalytics.com/report/contribution/fuel-web/90>
> 
> 
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
> 

__
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 Artur Svechnikov to the fuel-web-core team

2016-06-09 Thread Bulat Gaifullin 
+1 

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 09 Jun 2016, at 12:25, Aleksey Kasatkin <akasat...@mirantis.com> wrote:
> 
> Hey Fuelers,
> 
> I'd like to nominate Artur Svechnikov to the fuel-web-core team.
> 
> Artur is doing thorough reviews [1], he produces high-quality code.
> Artur is actively participating in features development (implementation for 
> Dynamically build bootstrap feature, design and implementation for HugePages 
> support and of NUMA/CPU pinning support) and in bug-fixing in Fuel project.
> 
> Core reviewers, please reply back with +1/-1.
> 
> [1] http://stackalytics.com/report/contribution/fuel-web/90 
> <http://stackalytics.com/report/contribution/fuel-web/90>
> 
> Best regards,
> 
> 
> Aleksey Kasatkin 
> 
> __
> 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] Nominate Ilya Kutukov for the fuel-web-core team

2016-06-08 Thread Bulat Gaifullin 
Hey Fuelers,

I'd like to nominate Ilya Kutukov for the fuel-web-core team.
Ilya`s doing good reviews with detailed feedback [1],
and has implemented custom graph execution engine for Fuel.
Also Ilya`s implemented new database models for storing deployment tasks in 
Fuel.


Fuel Cores, please reply back with +1/-1.

[1] http://stackalytics.com/report/contribution/fuel-web/90 
<http://stackalytics.com/report/contribution/fuel-web/90>


Regards,
Bulat Gaifullin
Mirantis Inc.

__
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] Storing deployment configuration before or after a successful deployment

2016-06-01 Thread Bulat Gaifullin 

IMO: 
Because we do not have the versioning for all settings, the discard button 
shall reset to last deployed state(in case if last deployed state exists, 
otherwise the discard button should not be available).
Now the availability of discard button calculates according to state of 
cluster, but this is not correct way, because the first deployment may fail, 
the cluster will be in ‘error state’, but it does not have last successfully 
deployed configuration.

Regards,at
Bulat Gaifullin
Mirantis Inc.



> On 25 May 2016, at 15:05, Roman Prykhodchenko <m...@romcheg.me> wrote:
> 
> Folks,
> 
> Recently we were investigating an issue [1] when a user configured a cluster 
> to cause deployment to fail and then expected a discard button will allow to 
> reset changes made after that failure. As Julia mentioned in her comment on 
> the bug, basically what we’ve got is that users actually perceive the meaning 
> of a cluster.deployed attribute as a snapshot to a latest deployment 
> configuration while it was designed to keep the latest configuration of a 
> successful deployment. Should we re-consider the meaning of that attribute 
> and therefore features and the action of the Discard button?
> 
> 
> References:
> 
> 1. https://bugs.launchpad.net/fuel/+bug/1584681
> 
> __
> 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] Wiping node's disks on delete

2016-03-22 Thread Bulat Gaifullin 
What about GPT[1] disks?
As I know we have plans to support UEFI boot and GPT disks. 


[1] https://en.wikipedia.org/wiki/GUID_Partition_Table

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 22 Mar 2016, at 13:46, Dmitry Guryanov <dgurya...@mirantis.com> wrote:
> 
> On Tue, 2016-03-22 at 13:07 +0300, Dmitry Guryanov wrote:
>> Hello,
>> 
>>  ..
>> 
>> [0] https://github.com/openstack/fuel-astute/blob/master/mcagents/era
>> se_node.rb#L162-L174
>> [1] https://github.com/openstack/fuel-
>> agent/blob/master/fuel_agent/manager.py#L194-L221
> 
> 
> Sorry, here is a correct link:
> https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.
> py#L228-L252
> 
> 
>> 
>> 
>> -- 
>> Dmitry Guryanov
> 
> __
> 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] Disable observing modifications of nested fields for MutableDict and MutableList

2016-03-09 Thread Bulat Gaifullin 
Fuelers, please notice that the patch [1]  changes behaviour of MutableDict and 
MutableList.
observing of changes in nested objects has been disabled, because it is not 
trivial to handle this case properly.
It is much easier to notify about changes in nester fields  explicitly when it 
is needed.
Example:

# instance.roles_metadata is instance of MutableDict.
instance.roles_metadata[role['name']] = role['meta']
instance.volumes_metadata['volumes_roles_mapping'][role['name']] = 
role.get('volumes_roles_mapping', [])
# notify about changes
instance.volumes_metadata.changed()

[1]  https://review.openstack.org/#/c/289600/

PS:
  Added missing link

Regards,
Bulat Gaifullin
Mirantis Inc.


__
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] Disable observing modifications of nested fields for MutableDict and MutableList

2016-03-09 Thread Bulat Gaifullin 
Fuelers, please notice that the patch [1]  changes behaviour of MutableDict and 
MutableList.
observing of changes in nested objects has been disabled, because it is not 
trivial to handle this case properly.
It is much easier to notify about changes in nester fields  explicitly when it 
is needed.
Example:

# instance.roles_metadata is instance of MutableDict.
instance.roles_metadata[role['name']] = role['meta']
instance.volumes_metadata['volumes_roles_mapping'][role['name']] = 
role.get('volumes_roles_mapping', [])
# notify about changes
instance.volumes_metadata.changed()


Regards,
Bulat Gaifullin
Mirantis Inc.




__
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

2016-03-08 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 03 Mar 2016, at 17:03, Dmitry Klenov <dkle...@mirantis.com> wrote:
> 
> Maksim, good job! +1 from my side though I am not a core.
> 
> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev 
> <azvyagint...@mirantis.com <mailto:azvyagint...@mirantis.com>> wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko <adide...@mirantis.com 
> <mailto:adide...@mirantis.com>> wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov <kgala...@mirantis.com 
> <mailto:kgala...@mirantis.com>> wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov <rvya...@mirantis.com 
> <mailto:rvya...@mirantis.com>> wrote:
> +1
> 
> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov <skula...@mirantis.com 
> <mailto:skula...@mirantis.com>> 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 
> <http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html>
> [2]. https://github.com/openstack/fuel-main 
> <https://github.com/openstack/fuel-main>
> [3]. https://github.com/openstack/fuel-virtualbox 
> <https://github.com/openstack/fuel-virtualbox>
> [4]. https://review.openstack.org/#/admin/groups/1299,members 
> <https://review.openstack.org/#/admin/groups/1299,members>
> [5]. https://github.com/openstack/fuel-virtualbox/commits/master 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> ---
> Best regards,
>Aleksey Zvyagintsev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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

2016-02-25 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 24 Feb 2016, at 16:02, Aleksandr Didenko <adide...@mirantis.com> wrote:
> 
> +1
> 
> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin <vkuk...@mirantis.com 
> <mailto:vkuk...@mirantis.com>> 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 as :
> 
> Master Node Upgrades and Backup
> Improvements to Fuel Infra
> Mitaka, Kilo and Juno Support
> Detachable Services Plugins
> RHOS Support in Fuel
> UCA Support
> Refactoring of Haproxy and Firewall pieces
> 
> He has also been known as our Fuel Master node and Docker guru and has been 
> continuously working on bugfixing where he scores as a bug squashing monster 
> with more than 150 bugfixes to all the parts of Fuel Library (#1 throughout 
> FL history).
> 
> As you can see, there is not a piece of Fuel Library that he has not yet 
> gained experience with.
> 
> And this can easily be fetched with simple statistics of Matt's contribution. 
> He is the topmost contributor to all Fuel projects among all Fuel Library 
> folks and is the 3rd contributor of Fuel Library.
> He also reviews a lot and has a fair amount of -1's (he is not as cruel as 
> me, though :-))
> 
> Having that said, I would like to open the vote to promote Matt to OpenStack 
> Fuel Library core reviewers.
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04>
> +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru <http://www.mirantis.ru/>
> vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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

2016-02-19 Thread Bulat Gaifullin 

> On 19 Feb 2016, at 17:09, Igor Kalnitsky <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?

> 
> 
> On Fri, Feb 19, 2016 at 1:06 PM, Bulat Gaifullin
> <bgaiful...@mirantis.com> wrote:
>> +1 to use wildcards for common tasks like netconfig and setup repositories.
>> This tasks should run on all nodes and it does not matter, the node has role
>> from plugin or core-role.
>> In my opinion we should one approach for basic configuration of node.
>> 
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>> 
>> 
>> 
>> On 19 Feb 2016, at 13:36, Kyrylo Galanov <kgala...@mirantis.com> wrote:
>> 
>> 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.openst

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

2016-02-19 Thread Bulat Gaifullin 
+1 to use wildcards for common tasks like netconfig and setup repositories. 
This tasks should run on all nodes and it does not matter, the node has role 
from plugin or core-role.
In my opinion we should one approach for basic configuration of node.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 19 Feb 2016, at 13:36, Kyrylo Galanov <kgala...@mirantis.com> wrote:
> 
> 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
>  
> <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 
> <mailto: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 
> <mailto: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/ 
> > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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][Plugins] Multi release packages

2016-02-10 Thread Bulat Gaifullin 
I agree with Stas, one rpm - one version.

But plugin builder allows to specify several releases as compatible. The 
deployment tasks and repositories can be specified per release, at the same 
time the deployment graph is one for all releases.
Currently it looks like half-implemented feature.  Can we drop this feature? or 
should we finish implementation of this feature.


Regards,
Bulat Gaifullin
Mirantis Inc.



> On 11 Feb 2016, at 02:41, Andrew Woodward <xar...@gmail.com> wrote:
> 
> 
> 
> On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <dborodae...@mirantis.com 
> <mailto:dborodae...@mirantis.com>> wrote:
> +1 to Stas, supplanting VCS branches with code duplication is a path to
> madness and despair. The dubious benefits of a cross-release backwards
> compatible plugin binary are not worth the code and infra technical debt
> that such approach would accrue over time.
> 
> Supporting multiple fuel releases will likely result in madness as discussed, 
> however as we look to support multiple OpenStack releases from the same 
> version of fuel, this methodology becomes much more important.
>  
> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
> > 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 least), pre_build hooks (also 6) and so on.
> > It will look as hell after just 3 years of development.
> >
> > Also I can't imagine how to deal with plugin licensing if you have Apache
> > for liberty but BSD for mitaka release, for example.
> >
> > Much easier way to develop a plugin is to keep it's source in VCS like Git
> > and just make a branches for every fuel release. It will give us
> > opportunity to not store a bunch of similar but a little bit different
> > files in repo. There is no reason to drag all different versions of code
> > for specific release.
> >
> >
> > On other hand there is a pros - your plugin can survive after upgrade if it
> > supports new release, no changes needed here.
> >
> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <ashtoko...@mirantis.com 
> > <mailto:ashtoko...@mirantis.com>>
> > wrote:
> >
> > > Fuelers,
> > >
> > > We are discussing the idea to extend the multi release packages for
> > > plugins.
> > >
> > > Fuel plugin builder (FPB) can create one rpm-package for all supported
> > > releases (from metadata.yaml) but we can specify only deployment scripts
> > > and repositories per release.
> > >
> > > Current release definition (in metadata.yaml):
> > > - os: ubuntu
> > >   version: liberty-8.0
> > >   mode: ['ha']
> > >   deployment_scripts_path: deployment_scripts/
> > >   repository_path: repositories/ubuntu
> > >
> 
> This will result in far too much clutter.
> For starters we should support nested over rides. for example the author may 
> have already taken account for the changes between one openstack version to 
> another. In this case they only should need to define the releases they 
> support and not specify any additional locations. Later they may determine 
> that they only need to replace packages, or one other file they should not be 
> required to code every location for each release
> 
> Also, at the same time we MUST clean up importing various yaml files. 
> Specifically, tasks, volumes, node roles, and network roles. Requiring that 
> they all be maintained in a single file doesn't scale, we don't require it 
> for tasks.yaml in fuel library, and we should not require it in plugins. We 
> should simply do the same thing as tasks.yaml in library, scan the subtree 
> for specific file names and just merge them all together. (This has been 
> expressed multiple times by people with larger plugins)
> 
> > > So the idea [0] is to make releases fully configurable.
> > > Suggested changes for release definition (in metadata.yaml):
> > >   components_path: components_liberty.yaml
> > >   deployment_tasks_path: deployment_tasks_liberty/ # <- folder 
> > >   environment_config_path: environment_config_liberty.yaml
> > >   network_roles_path: network_roles_liberty.yaml
> > >   node_roles_path: node_roles_liberty.yaml
> > >   volumes_path: volumes_liberty.yaml
> > >
> > > I see the issue: if we change anything for one relea

[openstack-dev] [All][Packetary] Release 0.1.0

2016-02-09 Thread Bulat Gaifullin 
We are happy to announce that Packetary[0] 0.1.0 has been successfully released.

New features:
* The structured format of input data (JSON or YAML).
* DEB and RPM repositories building.

Fixed bugs:
* https://bugs.launchpad.net/packetary/+bug/1539703


[0] https://wiki.openstack.org/wiki/Packetary

Regards,
Bulat Gaifullin
Mirantis Inc.

__
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] Task Based Deployment Is at Least Twice Faster

2016-02-08 Thread Bulat Gaifullin 
+1.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 08 Feb 2016, at 19:05, Igor Kalnitsky <ikalnit...@mirantis.com> wrote:
> 
> Hey Fuelers,
> 
> When we are going to enable it? I think since HCF is passed for
> stable/8.0, it's time to enable task-based deployment for master
> branch.
> 
> Opinion?
> 
> - Igor
> 
> On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya <bdobre...@mirantis.com> 
> wrote:
>> On 02.02.2016 17:35, Alexey Shtokolov wrote:
>>> Hi Fuelers!
>>> 
>>> As you may be aware, since [0] Fuel has implemented a new orchestration
>>> engine [1]
>>> We switched the deployment paradigm from role-based (aka granular) to
>>> task-based and now Fuel can deploy all nodes simultaneously using
>>> cross-node dependencies between deployment tasks.
>> 
>> That is great news! Please do not forget about docs updates as well.
>> Those docs are always forgotten like poor orphans... I submitted a patch
>> [0] to MOS docs, please review and add more details, if possible, for
>> plugins impact as well.
>> 
>> [0] https://review.fuel-infra.org/#/c/16509/
>> 
>>> 
>>> This feature is experimental in Fuel 8.0 and will be enabled by default
>>> for Fuel 9.0
>>> 
>>> Allow me to show you the results. We made some benchmarks on our bare
>>> metal lab [2]
>>> 
>>> Case #1. 3 controllers + 7 computes w/ ceph.
>>> Task-based deployment takes *~38* minutes vs *~1h15m* for granular (*~2*
>>> times faster)
>>> Here and below the deployment time is average time for 10 runs
>>> 
>>> Case #2. 3 controllers + 3 mongodb + 4 computes w/ ceph.
>>> Task-based deployment takes *~41* minutes vs *~1h32m* for granular
>>> (*~2.24* times faster)
>>> 
>>> 
>>> 
>>> Also we took measurements for Fuel CI test cases. Standard BVT (Master
>>> node + 3 controllers + 3 computes w/ ceph. All are in qemu VMs on one host)
>>> 
>>> Fuel CI slaves with *4 *cores *~1.1* times faster
>>> In case of 4 cores for 7 VMs they are fighting for CPU resources and it
>>> marginalizes the gain of task-based deployment
>>> 
>>> Fuel CI slaves with *6* cores *~1.6* times faster
>>> 
>>> Fuel CI slaves with *12* cores *~1.7* times faster
>> 
>> These are really outstanding results!
>> (tl;dr)
>> I believe the next step may be to leverage the "external install & svc
>> management" feature (example [1]) of the Liberty release (7.0.0) of
>> Puppet-Openstack (PO) modules. So we could use separate concurrent
>> cross-depends based tasks *within a single node* as well, like:
>> - task: install_all_packages - a singleton task for a node,
>> - task: [configure_x, for each x] - concurrent for a node,
>> - task: [manage_service_x, for each x] - some may be concurrent for a
>> node, while another shall be serialized.
>> 
>> So, one might use the "--tags" separator for concurrent puppet runs to
>> make things go even faster, for example:
>> 
>> # cat test.pp
>> notify
>> {"A": tag => "a" }
>> notify
>> {"B": tag => "b" }
>> 
>> # puppet apply test.pp
>> Notice: A
>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> Notice: B
>> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B'
>> 
>> # puppet apply test.pp --tags a
>> Notice: A
>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> 
>> # puppet apply test.pp --tags a & puppet apply test.pp --tags b
>> Notice: B
>> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B'
>> Notice: A
>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> 
>> Which is supposed to be faster, although not for this example.
>> 
>> [1] https://review.openstack.org/#/c/216926/3/manifests/init.pp
>> 
>>> 
>>> You can see additional information and charts in the presentation [3].
>>> 
>>> [0]
>>> - 
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html
>>> [1]
>>> - 
>>> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html
>>> [2] -  3 x HP ProLiant DL360p Gen8 (XeonE5 6 cores/64GB/SSD)  + 7 x HP
>>> ProLiant DL320p Gen8 (XeonE3 4 cores/8-16GB/HDD)
>>> [3] -
>>> https://docs.google.com/presentation/d/1jZCFZlXHs_VhjtVYS2VuWgdxge5Q6sOML

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

2016-02-08 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 08 Feb 2016, at 12:57, Evgeniy L <e...@mirantis.com> wrote:
> 
> +1
> 
> On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky <ikalnit...@mirantis.com 
> <mailto:ikalnit...@mirantis.com>> wrote:
> Hey Fuelers,
> 
> I'd like to nominate Fedor Zhadaev for the fuel-menu-core team.
> Fedor's doing good review with detailed feedback [1], and has
> contributes over 20 patches during Mitaka release cycle [2].
> 
> Fuel Cores, please reply back with +1/-1.
> 
> - igor
> 
> [1] http://stackalytics.com/?module=fuel-menu=mitaka 
> <http://stackalytics.com/?module=fuel-menu=mitaka>
> [2] http://stackalytics.com/?module=fuel-menu=mitaka_id=fzhadaev 
> <http://stackalytics.com/?module=fuel-menu=mitaka_id=fzhadaev>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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][Plugins] question on the is_hotpluggable feature

2016-02-05 Thread Bulat Gaifullin 
Hi Simon.
For running selected tasks on already deployed nodes you can use the following 
command of CLI (fuel command-line utility):

fuel node --node node_id1[,node_idN] --tasks task1[,taskN]

where node_id - is the unique identifier of node, where specified tasks shall 
be run.


>>>> Any plan to have a nicer experience in future Fuel releases?
Yes, we are working on this.


Regards,
Bulat Gaifullin
Mirantis Inc.



> On 05 Feb 2016, at 15:54, Igor Kalnitsky <ikalnit...@mirantis.com> wrote:
> 
> Simon,
> 
>> Nope, it doesn't work for me since it should run for *all* the nodes,
>> irrespective of their roles. AFAIK update_required doesn't support '*'.
> 
> If your plugin provides a new node role as well as additional tasks
> for other node roles, you may try to workaround that by using
> 
>  reexecute_on: [deploy_changes]
> 
> task marker. In that case, the task will be executed each time you hit
> "Deploy Changes" button, so make sure it's idempotent task.
> 
> - igor
> 
> 
> On Fri, Feb 5, 2016 at 1:04 PM, Evgeniy L <e...@mirantis.com> wrote:
>> Simon,
>> 
>>>> Any plan to have a nicer experience in future Fuel releases?
>> 
>> I haven't heard about any plans on improvements for that, but management
>> team should know better whether it's on roadmap or not.
>> 
>> Thanks,
>> 
>> On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier <spasqu...@mirantis.com>
>> wrote:
>>> 
>>> Thanks Evgeniy.
>>> 
>>> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L <e...@mirantis.com> wrote:
>>>> 
>>>> Hi Simon,
>>>> 
>>>> As far as I know it's expected behaviour (at least for the current
>>>> release), and it's expected that user reruns deployment on required nodes
>>>> using fuel cli, in order to install plugin on a live environment.
>>> 
>>> 
>>> Ok. For the record, this means running this command for every node that is
>>> already deployed:
>>> $ fuel node --node-id  --deploy
>>> 
>>> Any plan to have a nicer experience in future Fuel releases?
>>> 
>>>> 
>>>> It depends on specific role, but "update_required" field may help you, it
>>>> can be added to role description, Fuel reruns deployment on nodes with
>>>> roles, which are specified in the list, if new node with the role is added
>>>> to the environment.
>>> 
>>> 
>>> Nope, it doesn't work for me since it should run for *all* the nodes,
>>> irrespective of their roles. AFAIK update_required doesn't support '*'.
>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> [1]
>>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18
>>>> 
>>>> On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier <spasqu...@mirantis.com>
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> I'm testing the ability to install Fuel plugins in a an environment that
>>>>> is already deployed.
>>>>> My starting environment is quite simple: 1 controller + 1 compute. After
>>>>> the initial deployment, I've installed the 4 LMA plugins:
>>>>> - LMA collector
>>>>> - Elasticsearch-Kibana [*]
>>>>> - InfluxDB-Grafana [*]
>>>>> - Infrastructure Alerting [*]
>>>>> [*] adds a new role
>>>>> Of course, all plugins have "is_hotpluggable: true" in their metadata
>>>>> definition.
>>>>> My expectation is that I can add a new node with the new roles and that
>>>>> the LMA collector tasks are executed for all 3 nodes. So I've added the 
>>>>> new
>>>>> node and click the "Deploy changes" button. My re-deployment runs fine 
>>>>> but I
>>>>> notice that the plugins aren't installed on the existing nodes (eg
>>>>> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
>>>>> executed on already deployed nodes... Is this a known limitation? Am I
>>>>> missing something?
>>>>> Best regards,
>>>>> Simon
>>>>> 
>>>>> 
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>&

Re: [openstack-dev] [All][Packetary][Fuel] New project: Packetary (Repository management library)

2016-01-26 Thread Bulat Gaifullin 
Hi Igor,

Thank you for question! 
I will try to explain why we want to add functionality for building deb/rpm 
packages.

* We want to cover the whole workflow: from building a package till adding that 
package into the new or existing repository.
* We want to consolidate all knowledge about managing packages/repositories in 
one place.
* We want to have a common interface only, which will be based on the existing 
utilities for building packages. for example: sbuild[1] or Mock[2]


[1] https://wiki.debian.org/sbuild
[2] https://fedoraproject.org/wiki/Mock


Regards,
Bulat Gaifullin
Mirantis Inc.



> On 25 Jan 2016, at 13:35, Igor Kalnitsky <ikalnit...@mirantis.com> wrote:
> 
> Hey Bulat,
> 
> It's nice to hear that packetary finally got its own repo. However, I
> took a look at roadmap [1] and wonder why do you plan to add
> possibility to build RPM/DEB packages? It seems to me like it
> shouldn't be packetary's concern, and I'd like to see packetary as
> repo management tool, not a package build system. Each Linux
> distributive came out with its own set of tools to build packages, and
> that would be enough in my opinion. Maybe I'm wrong, though it'd be
> nice to see your input here. :)
> 
> Thanks,
> Igor
> 
> 
> 
> 
> 
> [1] https://wiki.openstack.org/wiki/Packetary/Roadmap
> 
> On Mon, Jan 25, 2016 at 10:25 AM, Bulat Gaifullin
> <bgaiful...@mirantis.com> wrote:
>> We are happy to introduce Packetary [0], which was separated from 
>> fuel-mirror [1].
>> 
>> Packetary provides flexible and data driven interface to manage 
>> (clone/build) rpm/deb repos and packages (not implemented yet).
>> Packetary provides object model and API.
>> One can use this framework to implement operations like building repository 
>> from a set of packages, clone repository, find package dependencies,
>> mix repositories, pull out a subset of packages into a separate repository, 
>> etc.
>> Packetary is to be used either as a library to easily integrate it with 
>> deployment tools and CI infrastructures and as CLI so a user can use it 
>> manually or in shell scripts.
>> 
>> In a nutshell Packetary is:
>> * Common interface to various package repositories (rpm/deb).
>> * Utility to build dependency graph for package(s).
>> * Utility to create mirror/partial mirror of a repository according to 
>> dependency graph.
>> 
>> Thanks!
>> 
>> [0] https://wiki.openstack.org/wiki/Packetary
>> [1] https://github.com/openstack/fuel-mirror/
>> __
>> 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] [All][Packetary][Fuel] New project: Packetary (Repository management library)

2016-01-25 Thread Bulat Gaifullin 
We are happy to introduce Packetary [0], which was separated from fuel-mirror 
[1].

Packetary provides flexible and data driven interface to manage (clone/build) 
rpm/deb repos and packages (not implemented yet).
Packetary provides object model and API.
One can use this framework to implement operations like building repository 
from a set of packages, clone repository, find package dependencies,
mix repositories, pull out a subset of packages into a separate repository, etc.
Packetary is to be used either as a library to easily integrate it with 
deployment tools and CI infrastructures and as CLI so a user can use it 
manually or in shell scripts.

In a nutshell Packetary is:
* Common interface to various package repositories (rpm/deb).
* Utility to build dependency graph for package(s).
* Utility to create mirror/partial mirror of a repository according to 
dependency graph.

Thanks!

[0] https://wiki.openstack.org/wiki/Packetary
[1] https://github.com/openstack/fuel-mirror/
__
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 Artem Panchenko for fuel-qa core

2015-12-23 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 23 Dec 2015, at 17:29, Aleksey Kasatkin <akasat...@mirantis.com> wrote:
> 
> +1
> 
> Aleksey Kasatkin 
> 
> 
> On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko <adide...@mirantis.com 
> <mailto:adide...@mirantis.com>> wrote:
> +1
> 
> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich <tleontov...@mirantis.com 
> <mailto:tleontov...@mirantis.com>> wrote:
> Absolutely agree 
> 
> +1 
> 
> 
> 
> 
> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy 
> <asledzins...@mirantis.com <mailto:asledzins...@mirantis.com>> 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
>  
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

2015-12-21 Thread Bulat Gaifullin 
Thank you.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 21 Dec 2015, at 13:11, Igor Kalnitsky <ikalnit...@mirantis.com> wrote:
> 
> Well, the agreement is reached. I added Bulat to both fuel-web-core
> and fuel-mirror-core groups.
> 
> Bulat, congratulations! Will be happy to see even more thorough
> reviews from you!
> 
> On Tue, Dec 15, 2015 at 11:49 AM, Evgeniy L <e...@mirantis.com> wrote:
>> +1
>> 
>> On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova
>> <aurlap...@mirantis.com> wrote:
>>> 
>>> +1
>>> 
>>> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov <rvya...@mirantis.com>
>>> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin
>>>> <akasat...@mirantis.com> wrote:
>>>>> 
>>>>> +1.
>>>>> 
>>>>> 
>>>>> Aleksey Kasatkin
>>>>> 
>>>>> 
>>>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov
>>>>> <vshars...@mirantis.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> +1 from me to Bulat.
>>>>>> 
>>>>>> On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky
>>>>>> <ikalnit...@mirantis.com> wrote:
>>>>>>> 
>>>>>>> Hi Fuelers,
>>>>>>> 
>>>>>>> I'd like to nominate Bulat Gaifulin [1] for
>>>>>>> 
>>>>>>> * fuel-web-core [2]
>>>>>>> * fuel-mirror-core [3]
>>>>>>> 
>>>>>>> Bulat's doing a really good review with detailed feedback and he's a
>>>>>>> regular participant in IRC. He's co-author of packetary and
>>>>>>> fuel-mirror projects, and he made valuable contribution to fuel-web
>>>>>>> (e.g. task-based deployment engine).
>>>>>>> 
>>>>>>> Fuel Cores, please reply back with +1/-1.
>>>>>>> 
>>>>>>> - Igor
>>>>>>> 
>>>>>>> [1] http://stackalytics.com/?module=fuel-web_id=bgaifullin
>>>>>>> [2] http://stackalytics.com/report/contribution/fuel-web/90
>>>>>>> [3] http://stackalytics.com/report/contribution/fuel-mirror/90
>>>>>>> 
>>>>>>> 
>>>>>>> __
>>>>>>> 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

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

2015-12-15 Thread Bulat Gaifullin 
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 15 Dec 2015, at 22:19, Andrew Maksimov <amaksi...@mirantis.com> wrote:
> 
> +1
> 
> Regards,
> Andrey Maximov
> Fuel Project Manager
> 
> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin <vkuk...@mirantis.com 
> <mailto:vkuk...@mirantis.com>> wrote:
> Folks
> 
> This email is a proposal to push Docker containers removal from the master 
> node to the date beyond 8.0 HCF. 
> 
> Here is why I propose to do so.
> 
> Removal of Docker is a rather invasive change and may introduce a lot of 
> regressions. It is well may affect how bugs are fixed - we might have 2 ways 
> of fixing them, while during SCF of 8.0 this may affect velocity of bug 
> fixing as you need to fix bugs in master prior to fixing them in stable 
> branches. This actually may significantly increase our bugfixing pace and put 
> 8.0 GA release on risk.
> 
>  
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru <http://www.mirantis.ru/>
> vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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] [murano] Fix order of arguments in assertEqual

2015-09-24 Thread Bulat Gaifullin 
+1

> On 24 Sep 2015, at 10:45, Tetiana Lashchova  wrote:
> 
> Hi folks!
> 
> Some tests in murano code use incorrect order of arguments in assertEqual.
> The correct order expected by the testtools is
> 
> def assertEqual(self, expected, observed, message=''):
> """Assert that 'expected' is equal to 'observed'.
> 
> :param expected: The expected value.
> :param observed: The observed value.
> :param message: An optional message to include in the error.
> """
> 
> Error message has the following format:
> 
> raise mismatch_error
> testtools.matchers._impl.MismatchError: !=:
> reference = 
> actual= 
> 
> Use of arguments in incorrect order could make debug output very confusing.
> Let's fix it to make debugging easier.
> 
> Best regards,
> Tetiana Lashchova
> __
> 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