Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for fuel-plugins-core
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 08 Sep 2016, at 12:05, Georgy Kibardin wrote: > > +1 > > On Thu, Sep 8, 2016 at 11:54 AM, Igor Kalnitsky <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&release=newton&metric=marks > <http://stackalytics.com/?module=fuel-plugins&release=newton&metric=marks> > [2] > http://stackalytics.com/?module=fuel-plugins&release=newton&metric=commits > <http://stackalytics.com/?module=fuel-plugins&release=newton&metric=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
+1, I think it is good idea. Regards, Bulat Gaifullin Mirantis Inc. > On 05 Sep 2016, at 20:17, Maksim Malchuk 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 <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 <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 <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 <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>__ > 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 Alexey Stepanov for fuel-qa and fuel-devops core
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 15 Jul 2016, at 16:08, Anastasia Urlapova wrote: > > +1 > > On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy > 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&module=fuel-qa&user_id=astepanov-m&metric=marks > > <http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks> > [1] > http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks > > <http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=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
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 > 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
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 22 Jun 2016, at 13:18, Sergey Kulanov 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&metric=commits&release=all > <http://stackalytics.com/?module=fuel-mirror&metric=commits&release=all> > [2]. http://stackalytics.com/?module=fuel-mirror&metric=patches&release=all > <http://stackalytics.com/?module=fuel-mirror&metric=patches&release=all> > [3]. http://stackalytics.com/?module=fuel-mirror&metric=marks&release=all > <http://stackalytics.com/?module=fuel-mirror&metric=marks&release=all> > [4]. http://stackalytics.com/?module=fuel-mirror&release=all > <http://stackalytics.com/?module=fuel-mirror&release=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
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 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
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 09 Jun 2016, at 12:25, Aleksey Kasatkin 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
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
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 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
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 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
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
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
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 03 Mar 2016, at 17:03, Dmitry Klenov 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 > mailto:azvyagint...@mirantis.com>> wrote: > +1 > > On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko <mailto:adide...@mirantis.com>> wrote: > +1 > > On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov <mailto:kgala...@mirantis.com>> wrote: > +1 > > On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov <mailto:rvya...@mirantis.com>> wrote: > +1 > > On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov <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
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 24 Feb 2016, at 16:02, Aleksandr Didenko wrote: > > +1 > > On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin <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 > +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] [Fuel] Wildcards instead of
> On 19 Feb 2016, at 17:09, Igor Kalnitsky 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 > 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 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 >> 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 >>> 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://lis
Re: [openstack-dev] [Fuel] Wildcards instead of
+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 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 <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 <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
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 wrote: > > > > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <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 > <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 release (e.g. > > > deployment_task typo) revalid
[openstack-dev] [All][Packetary] Release 0.1.0
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
+1. Regards, Bulat Gaifullin Mirantis Inc. > On 08 Feb 2016, at 19:05, Igor Kalnitsky 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 > 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
Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 08 Feb 2016, at 12:57, Evgeniy L wrote: > > +1 > > On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky <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&release=mitaka > <http://stackalytics.com/?module=fuel-menu&release=mitaka> > [2] http://stackalytics.com/?module=fuel-menu&release=mitaka&user_id=fzhadaev > <http://stackalytics.com/?module=fuel-menu&release=mitaka&user_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
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 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 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 >> wrote: >>> >>> Thanks Evgeniy. >>> >>> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L 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 >>>> 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: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> http://lists.openst
Re: [openstack-dev] [All][Packetary][Fuel] New project: Packetary (Repository management library)
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 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 > 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)
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
+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 <mailto:adide...@mirantis.com>> wrote: > +1 > > On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich <mailto:tleontov...@mirantis.com>> wrote: > Absolutely agree > > +1 > > > > > On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy > 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&release=all&project_type=all&module=fuel-qa > > <http://stackalytics.com/?user_id=apanchenko-8&release=all&project_type=all&module=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
Thank you. Regards, Bulat Gaifullin Mirantis Inc. > On 21 Dec 2015, at 13:11, Igor Kalnitsky 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 wrote: >> +1 >> >> On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova >> wrote: >>> >>> +1 >>> >>> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov >>> wrote: >>>> >>>> +1 >>>> >>>> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin >>>> wrote: >>>>> >>>>> +1. >>>>> >>>>> >>>>> Aleksey Kasatkin >>>>> >>>>> >>>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> +1 from me to Bulat. >>>>>> >>>>>> On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky >>>>>> 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&user_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
+1 Regards, Bulat Gaifullin Mirantis Inc. > On 15 Dec 2015, at 22:19, Andrew Maksimov wrote: > > +1 > > Regards, > Andrey Maximov > Fuel Project Manager > > On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin <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
+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