Re: [openstack-dev] [Fuel] Getting rid of ISO

[Roman Prykhodchenko]

This is so awesome! Thanks!

On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes  wrote:

> On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
> > Dear colleagues,
> >
> > We finally have working custom deployment job that deploys Fuel admin
> > node using online RPM repositories (not ISO) on vanilla Centos 7.0.
>
> Bravo! :)
>
> > Currently all Fuel system and deployment tests use ISO and we are
> > planning to re-implement all these jobs (including BVT, SWARM, and Fuel
> > CI jobs) to exclude ISO from the pipeline. That will allow us to get rid
> > of ISO as our deliverable and instead rely totally on package
> > repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
> > already delivered via ISO/qcow2/etc. images and we'd better stop
> > reinventing a wheel and support our own ISO build code. That will allow
> > us to make Fuel admin node deployment more flexible.
> >
> > I will infrom about our next steps here in the thread.
>
> Thanks, Vova, this is an excellent step forward for ease-of-use with Fuel.
>
> Nice work,
> -jay
>
> __
> 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] Deprecating old CLI in python-fuelclient

[Roman Prykhodchenko]

Fuelers,

We are proud to announce that we finally managed to reach the point when the 
old CLI in python-fuelclient (aka the old Fuel Client) can be deprecated and 
replaced with fuel2 — a cliff based CLI. Support of the full set of commands 
that are required to operate Fuel was already implemented in fuel2. After the 
deprecation plan is done, users will no longer be able to use old commands 
unless they install an older version of python-fuelclient from PyPi.

I have published a specification [1] that describes in details what changes are 
going to be made and how can different users can live with those changes. The 
specification also contains a table that compares old and new CLI, so the 
migration process will be as smooth as possible.


References:

1. https://review.openstack.org/#/c/361049


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

[Roman Prykhodchenko]

Folks,

It’s been several days when the entire python-fuelclient team is blocked by a 
broken CI job. Please make it non-voting ASAP.


- romcheg

> 8 серп. 2016 р. о 12:19 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Vladimir,
> 
> Thanks you for the update on this. Is there any ETA available?
> 
> On Mon, Aug 8, 2016 at 12:09 PM Vladimir Kozhukalov <vkozhuka...@mirantis.com 
> <mailto:vkozhuka...@mirantis.com>> wrote:
> We are working on this. Will fix soon.
> 
> Vladimir Kozhukalov
> 
> On Mon, Aug 8, 2016 at 12:52 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> If it’s not possible to fix this job during next few hours, let’s mark in as 
> non-voting until the bug(s) are fixed.
> 
> > 8 серп. 2016 р. о 11:48 Roman Prykhodchenko <m...@romcheg.me 
> > <mailto:m...@romcheg.me>> написав(ла):
> >
> > Folks,
> >
> > Since the end of last week 
> > master.python-fuelclient.pkgs.ubuntu.review_fuel_client [1] blocks all 
> > patches to python-fuelclient. As logs suggest this issue is caused by the 
> > Xenial merge party.
> >
> > Please resolve the issue ASAP because some folks are blocked and cannot 
> > finish their jobs in time.
> >
> >
> > 1. 
> > https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/
> >  
> > <https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/>
> >
> > - romcheg
> >
> >
> >
> 
> 
> __
> 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>



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

[Roman Prykhodchenko]

Vladimir,

Thanks you for the update on this. Is there any ETA available?

On Mon, Aug 8, 2016 at 12:09 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> We are working on this. Will fix soon.
>
> Vladimir Kozhukalov
>
> On Mon, Aug 8, 2016 at 12:52 PM, Roman Prykhodchenko <m...@romcheg.me>
> wrote:
>
>> If it’s not possible to fix this job during next few hours, let’s mark in
>> as non-voting until the bug(s) are fixed.
>>
>> > 8 серп. 2016 р. о 11:48 Roman Prykhodchenko <m...@romcheg.me>
>> написав(ла):
>> >
>> > Folks,
>> >
>> > Since the end of last week
>> master.python-fuelclient.pkgs.ubuntu.review_fuel_client [1] blocks all
>> patches to python-fuelclient. As logs suggest this issue is caused by the
>> Xenial merge party.
>> >
>> > Please resolve the issue ASAP because some folks are blocked and cannot
>> finish their jobs in time.
>> >
>> >
>> > 1.
>> https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/
>> >
>> > - romcheg
>> >
>> >
>> >
>>
>>
>> __
>> 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] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

[Roman Prykhodchenko]

If it’s not possible to fix this job during next few hours, let’s mark in as 
non-voting until the bug(s) are fixed.

> 8 серп. 2016 р. о 11:48 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Folks,
> 
> Since the end of last week 
> master.python-fuelclient.pkgs.ubuntu.review_fuel_client [1] blocks all 
> patches to python-fuelclient. As logs suggest this issue is caused by the 
> Xenial merge party.
> 
> Please resolve the issue ASAP because some folks are blocked and cannot 
> finish their jobs in time.
> 
> 
> 1. 
> https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/
> 
> - romcheg
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

[Roman Prykhodchenko]

Folks,

Since the end of last week 
master.python-fuelclient.pkgs.ubuntu.review_fuel_client [1] blocks all patches 
to python-fuelclient. As logs suggest this issue is caused by the Xenial merge 
party.

Please resolve the issue ASAP because some folks are blocked and cannot finish 
their jobs in time.


1. 
https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/

- romcheg





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 Vitalii Kulanov for python-fuelclient-core

[Roman Prykhodchenko]

The entire core team has voted for the nomination so I’m putting it to power. 
Let’s all welcome Vitalii as a new core reviewer. Congratulations!

> 1 серп. 2016 р. о 08:55 Aleksey Kasatkin <akasat...@mirantis.com> написав(ла):
> 
> +1
> 
> 
> Aleksey Kasatkin
> 
> 
> On Mon, Jul 25, 2016 at 7:46 PM, Igor Kalnitsky <ikalnit...@mirantis.com 
> <mailto:ikalnit...@mirantis.com>> wrote:
> Vitaly's doing a great job. +2, no doubts!
> 
> On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich
> <tleontov...@mirantis.com <mailto:tleontov...@mirantis.com>> wrote:
> > A huge +1
> >
> > On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko <yko...@mirantis.com 
> > <mailto:yko...@mirantis.com>> wrote:
> >>
> >> +1
> >>
> >> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko <m...@romcheg.me 
> >> <mailto:m...@romcheg.me>>
> >> wrote:
> >>>
> >>> Hi Fuelers,
> >>>
> >>> Vitalii has been providing great code reviews and patches for some time.
> >>> His recent commitment to help consolidating both old and new fuel clients
> >>> and his bug-squashing activities show his willingness to step up and take
> >>> responsibilities within the community. He can often be found in #fuel as
> >>> vkulanov.
> >>>
> >>>
> >>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
> >>>  
> >>> <http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka>
> >>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t 
> >>> <http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t>
> >>>
> >>>
> >>> P. S. Sorry for sending this email twice — I realized I didn’t put a
> >>> topic to the subject.
> >>>
> >>>
> >>> - romcheg
> >>>
> >>>
> >>> __
> >>> 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>
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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]Nominating Vitalii Kulanov for python-fuelclient-core

[Roman Prykhodchenko]

Hi Fuelers,

Vitalii has been providing great code reviews and patches for some time. His 
recent commitment to help consolidating both old and new fuel clients and his 
bug-squashing activities show his willingness to step up and take 
responsibilities within the community. He can often be found in #fuel as 
vkulanov.

http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t


P. S. Sorry for sending this email twice — I realized I didn’t put a topic to 
the subject.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Nominating Vitalii Kulanov for python-fuelclient-core

[Roman Prykhodchenko]

Hi Fuelers,

Vitalii has been providing great code reviews and patches for some time. His 
recent commitment to help consolidating both old and new fuel clients and his 
bug-squashing activities show his willingness to step up and take 
responsibilities within the community. He can often be found in #fuel as 
vkulanov.

http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t 



- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Merge IRC channels

[Roman Prykhodchenko]

Since Fuel is a part of OpenStack now, should we rename #fuel to 
#openstack-fuel?

- romcheg
> 24 черв. 2016 р. о 18:49 Andrew Woodward  написав(ла):
> 
> There is also #fuel-devops
> 
> I never liked having all the channels, so +1
> 
> On Fri, Jun 24, 2016 at 4:25 AM Anastasia Urlapova  > wrote:
> Vova,
> please don't forget merge #fuel-qa into a #fuel
> 
> On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov 
> > wrote:
> Nice. #fuel-infra is to merged as well.
> 
> Vladimir Kozhukalov
> 
> On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova  > wrote:
> And +1 for #fuel-infra
> 
> As of now it will be more useful if infra issues related to project will be 
> visible for project developers. We don't have much infra-related traffic on 
> IRC for now, and we will be able to split again if we got it.
> 
> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov 
> > wrote:
> Dear colleagues,
> 
> We have a few IRC channels but the level of activity there is quite low.
> 
> #fuel
> #fuel-dev
> #fuel-python
> #fuel-infra
> 
> My suggestion is to merge all these channels into a single IRC channel #fuel.
> Other #fuel-* channels are to be deprecated.
> 
> What do you think of this?
> 
> 
> 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 
> 
> 
> 
> 
> 
> --
> Aleksandra Fedorova
> Fuel CI Engineer
> bookwar
> 
> __
> 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 
> 
> --
> --
> 
> Andrew Woodward
> 
> Mirantis
> 
> Fuel Community Ambassador
> 
> Ceph Community
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

[Roman Prykhodchenko]

A big +1

> 23 черв. 2016 р. о 14:59 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 > > 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 
>> 
>> [1] https://github.com/openstack/python-fuelclient 
>> 
>> [2] 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Storing deployment configuration before or after a successful deployment

[Roman Prykhodchenko]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] release version numbers: let's use semvers

[Roman Prykhodchenko]

The only thing I would like to mention here is that scripts for making 
automatic releases on PyPi using OpenStack Infra won’t work, if the version is 
not formatted according to semver.

- romcheg

> 24 трав. 2016 р. о 14:34 Igor Kalnitsky  написав(ла):
> 
> Hey Zigo,
> 
> In Python community there's a PEP-440 [1] that defines a versioning scheme. 
> The thing you should know is, the PEP __is not__ compatible with semver, and 
> it's totally fine to have two components version.
> 
> So I don't think we should force version changes from two-components to 
> three-components scheme, since it won't be compatible with semver anyway.
> 
> Thanks,
> Igor
> 
> [1]: https://www.python.org/dev/peps/pep-0440/
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 9.0 is released

[Roman Prykhodchenko]

Jeremy,

Thanks for checking! Probably that is missing in the the release checklist.

- romcheg
> 26 квіт. 2016 р. о 17:35 Jeremy Stanley <fu...@yuggoth.org> написав(ла):
> 
> On 2016-04-26 17:29:40 +0200 (+0200), Roman Prykhodchenko wrote:
>> I still don’t see python-fuelclient-9.0.0 on PyPi: 
>> https://pypi.python.org/pypi/python-fuelclient 
>> <https://pypi.python.org/pypi/python-fuelclient>
>> 
>> Shouldn’t someone investigate this?
> 
> It hasn't been tagged yet as far as I can tell (no 9.0.0 in the git
> repo for openstack/python-fuelclient).
> --
> Jeremy Stanley
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 9.0 is released

[Roman Prykhodchenko]

I still don’t see python-fuelclient-9.0.0 on PyPi: 
https://pypi.python.org/pypi/python-fuelclient 


Shouldn’t someone investigate this?

> 25 квіт. 2016 р. о 18:33 Daniele Pizzolli  
> написав(ла):
> 
> On Mon, Apr 25 2016, you wrote:
> 
>> Can we support alternative way to download ISO since p2p may be prevented in 
>> some company IT?
> 
> Hello,
> 
> It is supported... but not advertised. I am not sure if this is by
> purpose (maybe because in http there is no additional checksum, see
> later for offline verification). For example to download:
> 
> fuel-community-9.0.iso.torrent
> 
> you can use http:
> 
> http://seed-cz1.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso
> http://seed-us1.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso
> 
> You can get the links by yourself, by getting the torrent and for
> example using:
> 
> set -- fuel-community-9.0.iso.torrent
> aria2c --show-files -- "$1" \
>| awk '/^[a-zA-Z]/{p=0};/^URL List:/{q=1};/^ http/{p=1};p&{print $1}'
> 
> Sorry for the heavy awk usage... I do not know a simple way to print
> them!  Maybe some bittorrent client has an option for that.
> 
> If you are able to get the torrent file, you can also verify the
> checksum off line, for example by using btcheck.
> 
>> 
>> Thanks,
> 
> Best,
> Daniele
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] CI may be broken for about 2 hours

[Roman Prykhodchenko]

We’ve organized a tiger team in order to merge two patches with a series of 
patches [1,2] in order to fix a swarm blocker. Our plan is the following:

1) Merge [1] and [2]
2) Trigger a build
3) Upload the new ISO to the CI system while it lasses the BVT
4) If the BVT is fine, switch the CI system to the new ISO

We anticipate the whole process to take about 2 hours.


References:

1. https://review.openstack.org/#/c/295731/2
2. https://review.openstack.org/#/c/295737/1


- romcheg



> 31 бер. 2016 р. о 14:15 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Folks,
> 
> There is a bug that is tagged as a swarm blocker [1] and two patches that fix 
> it. One of them is for nailgun [2] and another one is for fuel-library [3]. 
> The reason I write here is that those patches seem to fix the issue but they 
> will never pass tests on the CI when they are tested apart of each other.
> 
> I have built and ISO [4] and pushed it for the BVT in order to check that 
> everything works and passes tests with no problems. The results of the BVT 
> [5] indeed displayed that everything works correctly. Thus my proposal is to 
> coordinate core reviewers from both fuel-web and fuel-library to merge [2] 
> and [3] together ASAP.
> 
> 
> References:
> 
> 1. https://bugs.launchpad.net/fuel/+bug/1548776
> 2. https://review.openstack.org/#/c/295731/2
> 3. https://review.openstack.org/#/c/295737/1
> 4. http://jenkins-product.srt.mirantis.net:8080/job/9.0.custom.iso/1318/
> 5. 
> http://jenkins-product.srt.mirantis.net:8080/job/9.0.custom.ubuntu.bvt_2/453
> 
> 
> - romcheg
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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][Swarm blocker] Release data contain liberty name on mitaka packages

[Roman Prykhodchenko]

Folks,

There is a bug that is tagged as a swarm blocker [1] and two patches that fix 
it. One of them is for nailgun [2] and another one is for fuel-library [3]. The 
reason I write here is that those patches seem to fix the issue but they will 
never pass tests on the CI when they are tested apart of each other.

I have built and ISO [4] and pushed it for the BVT in order to check that 
everything works and passes tests with no problems. The results of the BVT [5] 
indeed displayed that everything works correctly. Thus my proposal is to 
coordinate core reviewers from both fuel-web and fuel-library to merge [2] and 
[3] together ASAP.


References:

1. https://bugs.launchpad.net/fuel/+bug/1548776
2. https://review.openstack.org/#/c/295731/2
3. https://review.openstack.org/#/c/295737/1
4. http://jenkins-product.srt.mirantis.net:8080/job/9.0.custom.iso/1318/
5. http://jenkins-product.srt.mirantis.net:8080/job/9.0.custom.ubuntu.bvt_2/453


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] New version of fuel-devops (2.9.20)

[Roman Prykhodchenko]

I’ve just tried to look up for fuel-devops on PyPi and found nothing. Let’s set 
up everything to let OpenStack CI release this package to PyPi and start 
publish releases there.

Also it’s better to use openstack-announce to announce new releases.

- romcheg



> 31 бер. 2016 р. о 11:52 Dennis Dmitriev  написав(ла):
> 
> Hi All,
> 
> We are going to update the 'fuel-devops' framework on our product CI to
> the version 2.9.20.
> 
> Changes since 2.9.17:
> 
> * Fixes:
> 
> - Fixes related to time synchronization issues: [1], [2], [10]
> - Fix for 'dos.py create' CLI command [4]
> - Use 0644 access mode for libvirt volumes created by fuel-devops [8]
> - Do not raise an exception while removing a libvirt object, if the
> object is missing in libvirt. Just skip it. [9]
> - Add timeout parameter to the tcp_ping method [7]
> 
> * Features:
> 
> - Allow to pass custom SSH credentials for slave nodes in environment
> variables: ENV_SLAVE_LOGIN and ENV_SLAVE_PASSWORD [3]
> - Get unique bridges/interfaces prefixes for each environment on the
> host using a 3-digits hash calculated from ENV_NAME and DATABASES
> objects as a salt for names of libvirt bridges and qemu network
> interfaces [5]
> - Extend Interface and Network models with methods for blocking traffic
> (for failover/destructive tests) [6]
> - Emulate multipath disk devices for libvirt VMs. Environment variable
> SLAVE_MULTIPATH_DISKS_COUNT is a multiplier for 'system' and 'cinder'
> volume names for slave nodes. 'multipath_count' key can be used for
> volumes in YAML template for more flexible configuration [11]
> - Enable NUMA for libvirt VMs [12]. To use NUMA, the following
> environment variables should be specified:
>  $ export NUMA_NODES=2  # amount of NUMA nodes on each VM (including
> Fuel master)
>  $ export DRIVER_ENABLE_ACPI=true  # required for NUMA
>  $ export IFACE_0=ens3  # can be required for fuel-qa system tests
> because of enabled ACPI
>  ...
>  $ export IFACE_5=ens8
> 
> 
> All changes since 2.9.17: [13]
> 
> [1] https://review.openstack.org/#/c/272200/
> [2] https://review.openstack.org/#/c/277900/
> [3] https://review.openstack.org/#/c/281262/
> [4] https://review.openstack.org/#/c/282007/
> [5] https://review.openstack.org/#/c/282732/
> [6] https://review.openstack.org/#/c/275134/
> [7] https://review.openstack.org/#/c/284422/
> [8] https://review.openstack.org/#/c/285241/
> [9] https://review.openstack.org/#/c/294143/
> [10] https://review.openstack.org/#/c/294002/
> [11] https://review.openstack.org/#/c/286804/
> [12] https://review.openstack.org/#/c/292352/
> 
> [13] https://github.com/openstack/fuel-devops/compare/2.9.17...2.9.20
> 
> --
> Regards,
> Dennis Dmitriev
> QA Engineer,
> Mirantis Inc. http://www.mirantis.com
> e-mail/jabber: ddmitr...@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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Extra red tape for filing bugs

[Roman Prykhodchenko]

We also often use bugtracker as a TODO tracker. This template does not work for 
TODOs at all. I understand that it’s not technically mandatory to follow it, 
but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes 
will overflow.

> 30 бер. 2016 р. о 17:37 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Guys,
> 
> I’m not trying to be a foreteller but with a bug template this huge and 
> complicated people will either not follow it or track bugs somewhere else. 
> Perhaps we should make it simpler?
> 
> Detailed bug description:
> 
> Steps to reproduce:
> 
> Expected results:
> 
> Actual result:
> 
> Reproducibility:
> 
> Workaround:
> 
> Impact:
> 
> Description of the environment:
> Operation system: 
> Versions of components: 
> Reference architecture: 
> Network model: 
> Related projects installed: 
> Additional information:
> 
> 
> 
> - romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Extra red tape for filing bugs

[Roman Prykhodchenko]

Guys,

I’m not trying to be a foreteller but with a bug template this huge and 
complicated people will either not follow it or track bugs somewhere else. 
Perhaps we should make it simpler?

Detailed bug description:
 
Steps to reproduce:
 
Expected results:
 
Actual result:
 
Reproducibility:
 
Workaround:
 
Impact:
 
Description of the environment:
 Operation system: 
 Versions of components: 
 Reference architecture: 
 Network model: 
 Related projects installed: 
Additional information:
 


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

+1 to discarding shotgun. Should we register a BP for that?

> 30 бер. 2016 р. о 12:03 Igor Kalnitsky <ikalnit...@mirantis.com> написав(ла):
> 
> Hey Fuelers,
> 
> I know that you probably wouldn't like to hear that, but in my opinion
> Fuel has to stop using Shotgun. It's nothing more but a command runner
> over SSH. Besides, it has well known issues such as retrieving remote
> directories with broken symlinks inside.
> 
> So I propose to find a modern alternative and reuse it. If we stop
> supporting Shotgun, we can spend extra time to focus on more important
> things.
> 
> As an example, we can consider to use Ansible. It should not be tricky
> to generate Ansible playbook instead of generating Shotgun one.
> Ansible is a  well known tool for devops and cloud operators, and they
> we will only benefit if we provide possibility to extend diagnostic
> recipes in usual (for them) way. What do you think?
> 
> Thanks,
> - Igor
> 
> On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:
>> Please, propose your options here then:
>> https://etherpad.openstack.org/p/shotgun-rename
>> 
>> 29 бер. 2016 р. о 18:15 Jay Pipes <jaypi...@gmail.com> написав(ла):
>> 
>> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>> 
>> Should we propose options and then arrange a poll?
>> 
>> 
>> Yup, ++ :)
>> 
>> 29 бер. 2016 р. о 16:40 Neil Jerram <neil.jer...@metaswitch.com>
>> написав(ла):
>> 
>> On 29/03/16 15:17, Jay Pipes wrote:
>> 
>> Hi!
>> 
>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>> something different? I know in the past that Anita and a few others
>> thought the name was not something we should really be encouraging in
>> the OpenStack ecosystem.
>> 
>> Just something to consider since it's being decoupled anyway and may be
>> a good opportunity to rename at that point...
>> 
>> Best,
>> -jay
>> 
>> 
>> +1
>> 
>> Neil
>> 
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

Please, propose your options here then: 
https://etherpad.openstack.org/p/shotgun-rename

> 29 бер. 2016 р. о 18:15 Jay Pipes <jaypi...@gmail.com> написав(ла):
> 
> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>> Should we propose options and then arrange a poll?
> 
> Yup, ++ :)
> 
>>> 29 бер. 2016 р. о 16:40 Neil Jerram <neil.jer...@metaswitch.com> 
>>> написав(ла):
>>> 
>>> On 29/03/16 15:17, Jay Pipes wrote:
>>>> Hi!
>>>> 
>>>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>>>> something different? I know in the past that Anita and a few others
>>>> thought the name was not something we should really be encouraging in
>>>> the OpenStack ecosystem.
>>>> 
>>>> Just something to consider since it's being decoupled anyway and may be
>>>> a good opportunity to rename at that point...
>>>> 
>>>> Best,
>>>> -jay
>>> 
>>> +1
>>> 
>>> Neil
>>> 
>>> 
>>> __
>>> 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 
> <mailto: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>


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Shotgun] Decoupling Shotgun from Fuel

[Roman Prykhodchenko]

Should we propose options and then arrange a poll?

> 29 бер. 2016 р. о 16:40 Neil Jerram  написав(ла):
> 
> On 29/03/16 15:17, Jay Pipes wrote:
>> Hi!
>> 
>> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
>> something different? I know in the past that Anita and a few others
>> thought the name was not something we should really be encouraging in
>> the OpenStack ecosystem.
>> 
>> Just something to consider since it's being decoupled anyway and may be
>> a good opportunity to rename at that point...
>> 
>> Best,
>> -jay
> 
> +1
> 
>   Neil
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

+1

> 25 бер. 2016 р. о 13:31 Dmitry Pyzhov <dpyz...@mirantis.com> написав(ла):
> 
> As we are going to deprecate logs on UI I'm going to mark following bugs as 
> "won't fix". Any objections?
> High priority bug:
> https://bugs.launchpad.net/fuel/+bug/1553170 
> <https://bugs.launchpad.net/fuel/+bug/1553170>
> Medium priority:
> https://bugs.launchpad.net/fuel/+bug/1554546 
> <https://bugs.launchpad.net/fuel/+bug/1554546>
> https://bugs.launchpad.net/fuel/+bug/1539508 
> <https://bugs.launchpad.net/fuel/+bug/1539508>
> 
> On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Folks, I’ve registered a blueprint [1] and created an etherpad document [2] 
> where we can co-work on the spec before posting it to a formal review. Let’s 
> cooperate to summarize what we need to do.
> 
> 
> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun 
> <https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun>
> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun 
> <https://etherpad.openstack.org/p/remove-logs-from_Nailgun>
> 
> - romcheg
> 
> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya <bdobre...@mirantis.com 
> > <mailto:bdobre...@mirantis.com>> написав(ла):
> >
> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
> >> +1 to Vitaliy, it would be nice find somewhere a details for migration.
> >> And one more concern I should highlight - for some users logless UI may
> >> be challenging thing.
> >> The logs removing shouldn't affect the UX.
> >
> > Logs will still live at the master node's /var/log/remote
> >
> >>
> >>
> >> Nastya.
> >>
> >>
> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xar...@gmail.com 
> >> <mailto:xar...@gmail.com>
> >> <mailto:xar...@gmail.com <mailto:xar...@gmail.com>>> wrote:
> >>
> >>I think we can address it by retaining deployment logs in
> >>nailgun/ui, this also removes the chicken and egg problem. after LMA
> >>is deployed it can be allowed to re-own 'logs' button on UI once
> >>it's deployed, including redirecting fuel logs there.
> >>
> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
> >><mscherba...@mirantis.com <mailto:mscherba...@mirantis.com> 
> >> <mailto:mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>>> wrote:
> >>
> >>We can sort out details later. In a worst case, the warning will
> >>be there in Newton too, and feature will go away only in O*
> >>release. So let's proceed with the bug..
> >>
> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
> >><vkramsk...@mirantis.com <mailto:vkramsk...@mirantis.com> 
> >> <mailto:vkramsk...@mirantis.com <mailto:vkramsk...@mirantis.com>>> wrote:
> >>
> >>We can add the warning, but I think before we do this we
> >>should have clear migration plan. According to this thread,
> >>some parts are still not clear.
> >>
> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
> >><mscherba...@mirantis.com <mailto:mscherba...@mirantis.com> 
> >> <mailto:mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>>>:
> >>
> >>Deprecation warning for Fuel
> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244 
> >> <https://bugs.launchpad.net/fuel/+bug/1556244>.
> >>
> >>
> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
> >><m...@romcheg.me <mailto:m...@romcheg.me> 
> >> <mailto:m...@romcheg.me <mailto:m...@romcheg.me>>> wrote:
> >>
> >>Since there are a lot of supporters for this idea,
> >>what do you folks think about creating a BP spec
> >>where we can describe what we should do in order to
> >>remove logs from UI and Nailgun? I also propose to
> >>file a bug about adding a deprecation warning to
> >>Mitaka release of Fuel.
> >>
> >>
> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
> >>><bdobre...@mirantis.com <mailto:bdobre...@mirantis.com>

[openstack-dev] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

[Roman Prykhodchenko]

Folks,

We have been analyzing a bunch of random failures in Fuel tests and encountered 
several ones caused by detector raising errors occasionally [1]. After attempts 
to reproduce the same behavior have failed we’ve decided to run the same test 
suit on overloaded nodes. Those test-runs allowed us to catch the same behavior 
we’ve seen on CI slaves. After analyzing both PostgreSQL logs and Nailgun’s 
code we’ve found no reasons for those deadlocks to occur.

Thinking about the facts mentioned we came up with the idea that those random 
deadlocks occur in cases when CI slaves are overloaded by other jobs and 
transactions start hitting deadlock timeout. Thus I propose to change 
PostgreSQL’s deadlock_timeout value from the default one to 3-5 seconds. That 
will slow down tests, if they run on an overloaded CI slave but will help to 
avoid random and false-positive deadlock warnings.


References:

1. https://bugs.launchpad.net/fuel/+bug/1556070


- romcheg
__
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][Infra] Nailgun extensions testing

[Roman Prykhodchenko]

The idea is to write python (or shell) script which will:
> - clone all required repos (like fuel-web, extensions repos) using
>   probably zuul-cloner

Doesn’t nodepool automatically do that?

> - checkout to appropriate stable branches / will cherry-pick some
>   commit / stay on master

As far as I understand extensions have Nailgun as their Python requirement so 
it would be reasonable to just install it from PyPi (first we need to release 
Nailgun to PyPi). Master of Nailgun can run its own non-voting job to check 
compatibility with the existing extensions and notify authors about any 
compatibility issues.

> 17 бер. 2016 р. о 14:42 Sylwester Brzeczkowski  
> написав(ла):
> 
> Hi everyone!
> 
> I’m looking for boilerplates/good practices regarding to testing
> extensions with core code.
> 
> Since we unlocked Nailgun extensions system [0] and now there
> is a possibility to install the extensions from external sources we
> want to also provide a way to test your own extensions against
> Nailgun and some other extensions. Here is the spec for this activity [1]
> 
> The idea is to write python (or shell) script which will:
> - clone all required repos (like fuel-web, extensions repos) using
>   probably zuul-cloner
> - checkout to appropriate stable branches / will cherry-pick some
>   commit / stay on master
> - run tests
> 
> This script will be used to:
> - test extension with different Nailgun versions (to check if it’s compatible)
>   locally and on extension’s jenkins gate jobs
> - test extension with different Nailgun versions and with other extensions
>   enabled (depending on needs)
> - test Nailgun with some core extensions locally and on fuel-web
>   jenkins gate jobs
> 
> The script will be placed in fuel-web repo as extensions will need
> to have Nailgun in its requirements anyway.
> 
> There will be new jenkins job which will consume names of
> extensions to test and the branches/commits/versions which
> the tests should be run against. The job will basically fetch fuel-web
> repo, and run the script mentioned above.
> 
> What do you think about the idea? Is it a good approach?
> Am I missing some already existing solutions for this problem?
> 
> Regards
> 
> [0] 
> https://blueprints.launchpad.net/fuel/+spec/stevedore-extensions-discovery 
> 
> [1] https://review.openstack.org/#/c/281749/ 
> 
> 
> 
> --
> Sylwester Brzeczkowski
> Python Software Engineer
> Product Development-Core : Product Engineering
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Getting rid of cluster status

[Roman Prykhodchenko]

Fuelers,

I would like to continue the series of "Getting rid of …" emails. This time I’d 
like to talk about statuses of clusters.

The issues with that attribute is that it is not actually related to real world 
very much and represents nothing. A few month ago I proposed to make it more 
real-world-like [1] by replacing a simple string by an aggregated value. 
However, after task based deployment was introduced even that approach lost its 
connection to the real world.

My idea is to get rid of that attribute from a cluster and start working with 
status of every single node in it. Nevertheless, we only have tasks that are 
executed on nodes now, so we cannot apply the "status" term to them. What if we 
replace that with a sort of boolean value called maintenance_mode (or similar) 
that we will use to tell if the node is operational or not. After that we will 
be able to use an aggregated property for cluster and check, if there are any 
nodes that are under a progress of performing some tasks on them.

Thoughts, ideas?


References:

1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Rewriting nailgun agent on Python proposal

[Roman Prykhodchenko]

My opition on this is that we have too many re-invented wheels in Fuel and it’s 
better think about replacing them with something we can re-use than 
re-inventing them one more time.

Let’s take a look at Ironic and try to figure out how we can use its features 
for the same purpose.


- romcheg
> 15 бер. 2016 р. о 10:38 Neil Jerram  написав(ла):
> 
> On 15/03/16 07:11, Vladimir Kozhukalov wrote:
>> Alexander,
>> 
>> We have many other places where use Ruby (astute, puppet custom types,
>> etc.). I don't think it is a good reason to re-write something just
>> because it is written in Ruby. You are right about tests, about plugins,
>> but let's look around. Ironic community has already invented discovery
>> component (btw written in python) and I can't see any reason why we
>> should continue putting efforts in nailgun agent and not try to switch
>> to ironic-inspector.
> 
> +1 in general terms.  It's strange to me that there are so many
> OpenStack deployment systems that each do each piece of the puzzle in
> their own way (Fuel, Foreman, MAAS/Juju etc.) - and which also means
> that I need substantial separate learning in order to use all these
> systems.  It would be great to see some consolidation.
> 
> Regards,
>   Neil
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

Folks, I’ve registered a blueprint [1] and created an etherpad document [2] 
where we can co-work on the spec before posting it to a formal review. Let’s 
cooperate to summarize what we need to do.


1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun

- romcheg

> 14 бер. 2016 р. о 09:53 Bogdan Dobrelya <bdobre...@mirantis.com> написав(ла):
> 
> On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
>> +1 to Vitaliy, it would be nice find somewhere a details for migration.
>> And one more concern I should highlight - for some users logless UI may
>> be challenging thing.
>> The logs removing shouldn't affect the UX.
> 
> Logs will still live at the master node's /var/log/remote
> 
>> 
>> 
>> Nastya.
>> 
>> 
>> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xar...@gmail.com
>> <mailto:xar...@gmail.com>> wrote:
>> 
>>I think we can address it by retaining deployment logs in
>>nailgun/ui, this also removes the chicken and egg problem. after LMA
>>is deployed it can be allowed to re-own 'logs' button on UI once
>>it's deployed, including redirecting fuel logs there.
>> 
>>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
>><mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>> wrote:
>> 
>>We can sort out details later. In a worst case, the warning will
>>be there in Newton too, and feature will go away only in O*
>>release. So let's proceed with the bug..
>> 
>>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
>><vkramsk...@mirantis.com <mailto:vkramsk...@mirantis.com>> wrote:
>> 
>>We can add the warning, but I think before we do this we
>>should have clear migration plan. According to this thread,
>>some parts are still not clear.
>> 
>>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
>>    <mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>>:
>> 
>>Deprecation warning for Fuel
>>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
>> 
>> 
>>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
>><m...@romcheg.me <mailto:m...@romcheg.me>> wrote:
>> 
>>Since there are a lot of supporters for this idea,
>>what do you folks think about creating a BP spec
>>where we can describe what we should do in order to
>>remove logs from UI and Nailgun? I also propose to
>>file a bug about adding a deprecation warning to
>>Mitaka release of Fuel.
>> 
>> 
>>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
>>><bdobre...@mirantis.com
>>><mailto:bdobre...@mirantis.com>> написав(ла):
>>> 
>>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>>>>+1 to remove logs from Fuel UI in Fuel Newton.
>>>>In Fuel Mitaka we'd need to put a deprecation
>>>>warning somewhere.
>>> 
>>>I agree, there is not much sense having non
>>>flexible (no content
>>>filters) logs view in UI. LMA plugins shall cover
>>>this area as well.
>>> 
>>>> 
>>>> 
>>>>On Fri, Mar 11, 2016, 04:57 Patrick Petit
>>>><ppe...@mirantis.com <mailto:ppe...@mirantis.com>
>>>><mailto:ppe...@mirantis.com>> wrote:
>>>> 
>>>> 
>>>>   On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>>>   (ikalnit...@mirantis.com
>>>><mailto:ikalnit...@mirantis.com> 
>>>> <mailto:ikalnit...@mirantis.com>)
>>>>wrote:
>>>> 
>>>>>   Patrick,
>>>>> 
>>>>>   Sorry, but I meant another question. I
>>>>>thought that LMA plugin should
>>>>>   be installed in some environment before we
>>>>>can start use it. Is
>>>>>   this a
>>>

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

Since there are a lot of supporters for this idea, what do you folks think 
about creating a BP spec where we can describe what we should do in order to 
remove logs from UI and Nailgun? I also propose to file a bug about adding a 
deprecation warning to Mitaka release of Fuel.


> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya <bdobre...@mirantis.com> написав(ла):
> 
> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>> +1 to remove logs from Fuel UI in Fuel Newton.
>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
> 
> I agree, there is not much sense having non flexible (no content
> filters) logs view in UI. LMA plugins shall cover this area as well.
> 
>> 
>> 
>> On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppe...@mirantis.com 
>> <mailto:ppe...@mirantis.com>
>> <mailto:ppe...@mirantis.com <mailto:ppe...@mirantis.com>>> wrote:
>> 
>> 
>>On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>(ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com> 
>> <mailto:ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>>) wrote:
>> 
>>>Patrick,
>>> 
>>>Sorry, but I meant another question. I thought that LMA plugin should
>>>be installed in some environment before we can start use it. Is
>>>this a
>>>case? If so, it means we can't use for master node until some
>>>environment is deployed.
>> 
>>Right. This is the chicken and egg problem I mentioned earlier...
>> 
>>But this is not a “problem” specific to Fuel. My take on this is is
>>that ops management tooling (logging, monitoring) should be
>>installed off-band before any OpenStack deployment. In fact, in
>>real-world usage, we frequently get asks to have the monitoring and
>>logging services of StackLight installed permanently for
>>multi-enviroments. And so, one approach would be to make Stacklight
>>backend services the first bits of software installed by Fuel (if
>>not already there), then reconfigure Fuel to hook into those
>>services and only then, enter into the regular OpenStack
>>provisioning mode.
>> 
>>> 
>>> 
>>>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>><ppe...@mirantis.com <mailto:ppe...@mirantis.com> 
>>> <mailto:ppe...@mirantis.com <mailto:ppe...@mirantis.com>>> wrote:
>>>> 
>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com 
>>>> <mailto:ikalnit...@mirantis.com> <mailto:ikalnit...@mirantis.com 
>>>> <mailto:ikalnit...@mirantis.com>>)
>>>> wrote:
>>>> 
>>>> Hey Roman,
>>>> 
>>>> Thank you for bringing this up. +1 from my side, especially taking
>>>> into account the patch where we tried to solve logrotated logs problem
>>>> [1]. It's complex and unsupportable, as well as already existed
>>>> logview code in Nailgun.
>>>> 
>>>> Patrick, Simon,
>>>> 
>>>> Does LMA plugin support logs from master node? Or it's designed to
>>>> watch environment's logs?
>>>> 
>>>> No it’s not designed specifically for environment logs. Can be adapted to
>>>> any log format.
>>>> 
>>>> Would just need to write a parser like you would with logstach when logs 
>>>> are
>>>> not standard.
>>>> 
>>>> Patrick
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> Igor
>>>> 
>>>> 
>>>> [1]: https://review.openstack.org/#/c/243240/ 
>>>> <https://review.openstack.org/#/c/243240/>
>>>> 
>>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com 
>>>> <mailto:ppe...@mirantis.com> <mailto:ppe...@mirantis.com 
>>>> <mailto:ppe...@mirantis.com>>> wrote:
>>>>> Fuelers,
>>>>> 
>>>>> As Simon said, we already have a log centralisation solution for MOS
>>>>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>>>>> objectively, there is no need to have log management in Nailgun anymore.
>>>>> To
>>>>> go one step further we suggested several times to have a StackLight agent
>>>>> installed on the Fuel master node to also collect and centralise those
>>>>> logs.
>>>>> There is a little bit of a chicken and egg problem to resolve but I th

[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

Fuelers,

I remember we’ve discussing this topic in our couloirs before but I’d like to 
bring that discussion to a more official format.

Let me state a few reasons to do this:

- Log management code in Nailgun is overcomplicated
- Working with logs on big scale deployments is barely possible given the 
current representation
- Due to overcomplexity and ineffectiveness of the code we always get recurring 
bugs like [1]. That eats tons of time to resolve.
- There are much better specialized tools, say Logstash [2], that can deal with 
logs much more effectively.


There may be more reasons bus I think even the already mentioned ones are 
enough to think about the following proposal:

- Remove Logs tab from Fuel Web UI
- Remove logs support from Nailgun
- Create mechanism that allows to configure different log management software, 
say Logstash, Loggly, etc
- Choose a default software to install and provide a plugin for it from the box


References
1.  https://bugs.launchpad.net/fuel/+bug/1553170
2. https://www.elastic.co/products/logstash


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] URL of Horizon is hard to find on the dashboard

[Roman Prykhodchenko]

Cannot we use display the same link we use in the title?

> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh <vkramsk...@mirantis.com> написав(ла):
> 
> Hi, Roman,
> 
> I think the only solution here is to underline the title so it would look 
> like a link. I don't think it's a good idea to show full URL because:
> If SSL is enabled, there will be 2 links - HTTP and HTTPS.
> Plugins can provide their own links for their dashboards, and they would be 
> shown using exactly the same representation which is used for Horizon. These 
> links could be quite long.
> 
> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>>:
> Whoops! I forgot to attach the link. Sorry!
> 
> 1. http://i.imgur.com/8GaUtDq.png <http://i.imgur.com/8GaUtDq.png>
> 
> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko <m...@romcheg.me 
> > <mailto:m...@romcheg.me>> написав(ла):
> >
> > Hi fuelers!
> >
> > I’m not sure, if it’s my personal problem or the UX can be improved a 
> > little, but I’ve literary spend more than 5 minutes trying to figure out 
> > how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to 
> > add a full a link with the full URL in its test after "The OpenStack 
> > dashboard Horizon is now available". That would make things much more 
> > usable.
> >
> >
> > - romcheg
> >
> > __
> > 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>
> 
> 
> 
> 
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] URL of Horizon is hard to find on the dashboard

[Roman Prykhodchenko]

Hi fuelers!

I’m not sure, if it’s my personal problem or the UX can be improved a little, 
but I’ve literary spend more than 5 minutes trying to figure out how to find a 
URL of Horizon. I’ve made a screenshot [1] and I suggest to add a full a link 
with the full URL in its test after "The OpenStack dashboard Horizon is now 
available". That would make things much more usable.


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] virtualenv fails with SSLError: [Errno 20] Not a directory

[Roman Prykhodchenko]

Folks,

as some of you may have noticed, there is a high rate of job failures on Fuel 
CI in python-fuelclient. That happens because there are some weird issues with 
virtualenv utility not being able to create new virtual environments. I’ve 
tested that on my local environment and the problem appears to happen 
constantly with rare exceptions:

I’ve tried running $virtualenv test and that’s what I’m getting: 
http://paste.openstack.org/show/485962/
Let’s find out what happened and resolve the issue.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] virtualenv fails with SSLError: [Errno 20] Not a directory

[Roman Prykhodchenko]

UPD: on Fuel-CI it fails with SSLError: [Errno 185090050] _ssl.c:344: 
error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib as 
could be found in [1].

This is very important issue to fix because it blocks development of 
python-fuelclient. It requires attention ASAP.

References:
1. https://ci.fuel-infra.org/job/verify-python-fuelclient/1324/console

> 4 лют. 2016 р. о 15:50 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Folks,
> 
> as some of you may have noticed, there is a high rate of job failures on Fuel 
> CI in python-fuelclient. That happens because there are some weird issues 
> with virtualenv utility not being able to create new virtual environments. 
> I’ve tested that on my local environment and the problem appears to happen 
> constantly with rare exceptions:
> 
> I’ve tried running $virtualenv test and that’s what I’m getting: 
> http://paste.openstack.org/show/485962/
> Let’s find out what happened and resolve the issue.
> 
> 
> - romcheg
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

This is basically why I proposed to allow users to set per cluster priority for 
every enabled plugin. That would allow users to select results they need. 
Putting too many logic into checks whether two plugins are incompatible is 
error-prone and won’t stop anyone from shooting their feet.


> 29 січ. 2016 р. о 16:10 Igor Kalnitsky <ikalnit...@mirantis.com> написав(ла):
> 
> Roman P. wrote:
>> Putting extra checks will create a more fool-proof but less configurable
>> software. I’d vote for letting users shoot their feet using their plugins
>> but making Fuel more flexible.
> 
> I won't agree here. You see, what if two plugins wants to override the
> core network role? Consider that plugin A wants to extend VIPs:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip:
>- name: "management"
>  namespace: "haproxy"
># new VIP we want to add
>- name: "myvip"
>  namespace: "haproxy"
> 
> while plugin B wants to remove them:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip: []
> 
> How do you suppose to resolve this action? We don't know in which
> order they will be resolved, and I'm strongly against unpredictable
> situation (especiall it may be different time-to-time and depends on
> which order plugins will be selected).
> 
> Moreover, it makes a little sense to try to resolve this situation. If
> two plugins change something in core, they are probably incompatible.
> Manual actions are required.
> 
> So that's, basically, why I think we should warn user about
> incompatible changes to core stuff. Just like we do for deployment
> tasks.
> 
> - igor
> 
> On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:
>> I would not check that. We are not talking about installing browser plugins
>> when users may not know what they want. Putting extra checks will create a
>> more fool-proof but less configurable software. I’d vote for letting users
>> shoot their feet using their plugins but making Fuel more flexible.
>> 
>> 
>> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin <akasat...@mirantis.com>
>> написав(ла):
>> 
>>> jsonpatch
>> 
>> There were +1's regarding overriding VIPs above. I'd stick with that. It is
>> done for tasks now. But we will need to check conflicts between plugins
>> there (as for tasks).
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:
>>> 
>>> Frankly, I have not though about how to deal with multiple plugins yet.
>>> However, what I think is that we must not restrict this too much and let
>>> users configure it more flexibly even if it allows to shoot one’s foot.
>>> Perhaps we can add a per-cluster priority for enabled plugins which users
>>> can configure via UI, CLI or API. My other thought is that we should not
>>> invent our own mechanics for changing a configuration and use an existing
>>> one, say, jsonpatch. What do you guys think?
>>> 
>>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>>> please check it out. If it does not break anything, lets merge it ASAP.
>>> 
>>> - romcheg
>>> 
>>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin <akasat...@mirantis.com>
>>> написав(ла):
>>> 
>>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>>> what VIPs you are removing.
>>> Another option - remove "built-in" VIPs using some specific expression.
>>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>>> you cannot remove them this way.
>>> 
>>> And the order of plugins processing is not defined so there is no warranty
>>> you will remove all VIPs on those network roles.
>>> Seems, checking for such conflict between plugins is needed.
>>> 
>>> The original goal, actually, was to remove VIPs for controllers (or for
>>> some particular node role, maybe),
>>> so we should maybe find a way to do exactly this.
>>> 
>>> 
>>> 
>>> Aleksey Kasatkin
>>> 
>>> 
>>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko <adide...@mirantis.com>
>>> wrote:
>>>> 
>>>>> How are we handling this now for multiple plugins?
>>>> 
>>>> OK, so right now we can only add VIPs to array, we can't 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

I would not check that. We are not talking about installing browser plugins 
when users may not know what they want. Putting extra checks will create a more 
fool-proof but less configurable software. I’d vote for letting users shoot 
their feet using their plugins but making Fuel more flexible.


> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin <akasat...@mirantis.com> написав(ла):
> 
> > jsonpatch
> 
> There were +1's regarding overriding VIPs above. I'd stick with that. It is 
> done for tasks now. But we will need to check conflicts between plugins there 
> (as for tasks).
> 
> 
> Aleksey Kasatkin
> 
> 
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Frankly, I have not though about how to deal with multiple plugins yet. 
> However, what I think is that we must not restrict this too much and let 
> users configure it more flexibly even if it allows to shoot one’s foot. 
> Perhaps we can add a per-cluster priority for enabled plugins which users can 
> configure via UI, CLI or API. My other thought is that we should not invent 
> our own mechanics for changing a configuration and use an existing one, say, 
> jsonpatch. What do you guys think?
> 
> P. S. [0] is really needed for 8.0 for implementing an important epic, so 
> please check it out. If it does not break anything, lets merge it ASAP.
> 
> - romcheg
> 
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin <akasat...@mirantis.com 
>> <mailto:akasat...@mirantis.com>> написав(ла):
>> 
>> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
>> VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
>> cannot remove them this way.
>> 
>> And the order of plugins processing is not defined so there is no warranty 
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>> 
>> The original goal, actually, was to remove VIPs for controllers (or for some 
>> particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>> 
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko <adide...@mirantis.com 
>> <mailto:adide...@mirantis.com>> wrote:
>> > How are we handling this now for multiple plugins?
>> 
>> OK, so right now we can only add VIPs to array, we can't remove them. So 
>> overriding would disable such possibility of adding VIPs from different 
>> plugins. But with [0] patch it will be still possible to add and to remove 
>> by providing empty array. But we'll have the problem with multiple plugins 
>> in such case.
>> I've changed my mind :) I vote for leaving as in [0] since it's less 
>> destructive comparing to what we have now.
>> 
>> Regards,
>> Alex
>> 
>> [0] https://review.openstack.org/#/c/273169/1 
>> <https://review.openstack.org/#/c/273169/1>
>> 
>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko <adide...@mirantis.com 
>> <mailto:adide...@mirantis.com>> wrote:
>> Well, with merging instead of overriding, I believe, this problem with 
>> multiple plugins still exists, right? How are we handling this now for 
>> multiple plugins?
>> Since VIPs is array I also vote for overriding, since merging it could be a 
>> pain (how do you remove existing element during array merge?).
>> 
>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin <akasat...@mirantis.com 
>> <mailto:akasat...@mirantis.com>> wrote:
>> Roman, please provide more details on how VIPs are overridden. And how do 
>> you deal with multiple plugins.
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <akasat...@mirantis.com 
>> <mailto:akasat...@mirantis.com>> wrote:
>> Good idea, overally.
>> 
>> How about multiple plugins? We don't have any sequence or priorities between 
>> them.
>> What if one plugin assumes that VIP is present but other one wants to remove 
>> it?
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <sgolovat...@mirantis.com 
>> <mailto:sgolovat...@mirantis.com>> wrote:
>> +1 to overriding VIPs
>> 
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>> 
>> On Thu, Jan 28, 2016 at 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

Frankly, I have not though about how to deal with multiple plugins yet. 
However, what I think is that we must not restrict this too much and let users 
configure it more flexibly even if it allows to shoot one’s foot. Perhaps we 
can add a per-cluster priority for enabled plugins which users can configure 
via UI, CLI or API. My other thought is that we should not invent our own 
mechanics for changing a configuration and use an existing one, say, jsonpatch. 
What do you guys think?

P. S. [0] is really needed for 8.0 for implementing an important epic, so 
please check it out. If it does not break anything, lets merge it ASAP.

- romcheg

> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin <akasat...@mirantis.com> написав(ла):
> 
> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
> VIPs you are removing.
> Another option - remove "built-in" VIPs using some specific expression.
> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
> cannot remove them this way.
> 
> And the order of plugins processing is not defined so there is no warranty 
> you will remove all VIPs on those network roles.
> Seems, checking for such conflict between plugins is needed.
> 
> The original goal, actually, was to remove VIPs for controllers (or for some 
> particular node role, maybe),
> so we should maybe find a way to do exactly this.
> 
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko <adide...@mirantis.com 
> <mailto:adide...@mirantis.com>> wrote:
> > How are we handling this now for multiple plugins?
> 
> OK, so right now we can only add VIPs to array, we can't remove them. So 
> overriding would disable such possibility of adding VIPs from different 
> plugins. But with [0] patch it will be still possible to add and to remove by 
> providing empty array. But we'll have the problem with multiple plugins in 
> such case.
> I've changed my mind :) I vote for leaving as in [0] since it's less 
> destructive comparing to what we have now.
> 
> Regards,
> Alex
> 
> [0] https://review.openstack.org/#/c/273169/1 
> <https://review.openstack.org/#/c/273169/1>
> 
> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko <adide...@mirantis.com 
> <mailto:adide...@mirantis.com>> wrote:
> Well, with merging instead of overriding, I believe, this problem with 
> multiple plugins still exists, right? How are we handling this now for 
> multiple plugins?
> Since VIPs is array I also vote for overriding, since merging it could be a 
> pain (how do you remove existing element during array merge?).
> 
> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin <akasat...@mirantis.com 
> <mailto:akasat...@mirantis.com>> wrote:
> Roman, please provide more details on how VIPs are overridden. And how do you 
> deal with multiple plugins.
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <akasat...@mirantis.com 
> <mailto:akasat...@mirantis.com>> wrote:
> Good idea, overally.
> 
> How about multiple plugins? We don't have any sequence or priorities between 
> them.
> What if one plugin assumes that VIP is present but other one wants to remove 
> it?
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <sgolovat...@mirantis.com 
> <mailto:sgolovat...@mirantis.com>> wrote:
> +1 to overriding VIPs
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <vkuk...@mirantis.com 
> <mailto:vkuk...@mirantis.com>> wrote:
> +1 to overriding VIPs
> 
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Folks,
> 
> currently merge policy for network roles only allows to add new VIPs to 
> already existing roles [1]. If a plugin supplies a VIP with a name that 
> already exists but with different parameters, Nailgun will not allow to do 
> that. We faced a need to override configuration of several VIPs by completely 
> removing them from network roles by supplying something like [2]. To enable 
> that I’ve made a temporary workaround [3] to the merging policy that only 
> handles one cornerstone.
> 
> I’ve talked to ikalnitsky and we realized that this functionality of merging 
> new VIPs from plugins to an existing network role is actually wrong and 
> should be replaced by complete overriding. Let’s discuss this possibility 
> here.
> 
> 
> References:
> 
> 1. 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>  
> <https://

[openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

Folks,

currently merge policy for network roles only allows to add new VIPs to already 
existing roles [1]. If a plugin supplies a VIP with a name that already exists 
but with different parameters, Nailgun will not allow to do that. We faced a 
need to override configuration of several VIPs by completely removing them from 
network roles by supplying something like [2]. To enable that I’ve made a 
temporary workaround [3] to the merging policy that only handles one 
cornerstone.

I’ve talked to ikalnitsky and we realized that this functionality of merging 
new VIPs from plugins to an existing network role is actually wrong and should 
be replaced by complete overriding. Let’s discuss this possibility here.


References:

1. 
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
2. http://xsnippet.org/361361/
3. https://review.openstack.org/#/c/273169/1


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [fuelclient] Pre-release versions of fuelclient for testing purposes

[Roman Prykhodchenko]

Releasing a beta version sounds like a good plan but does OpenStack Infra 
actually support this?

> 20 січ. 2016 р. о 12:05 Oleg Gelbukh  написав(ла):
> 
> Hi,
> 
> Currently we're experiencing issues with Python dependencies of our package 
> (fuel-octane), specifically between fuelclient's dependencies and 
> keystoneclient dependencies.
> 
> New keystoneclient is required to work with the new version of Nailgun due to 
> introduction of SSL in the latter. On the other hand, fuelclient is released 
> along with the main release of Fuel, and the latest version available from 
> PyPI is 7.0.0, and it has very old dependencies (based on packages available 
> in centos6/python26).
> 
> The solution I'd like to propose is to release beta version of fuelclient 
> (8.0.0b1) with updated requirements ASAP. With --pre flag to pip/tox, this 
> will allow to run unittests against the proper set of requirements. On the 
> other hand, it will not break the users consuming the latest stable (7.0.0) 
> version with old requirements from PyPI.
> 
> Please, share your thoughts and considerations. If no objections, I will 
> create a corresponding bug/blueprint against fuelclient to be fixed in the 
> current release cycle.
> 
> --
> Best regards,
> Oleg Gelbukh
> Mirantis
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] nova-network removal

[Roman Prykhodchenko]

I’d like to add that nova-network support was removed from python-fuelclient in 
8.0.

> 14 січ. 2016 р. о 17:54 Vitaly Kramskikh  
> написав(ла):
> 
> Folks,
> 
> We have a request on review which prohibits creating new envs with 
> nova-network: https://review.openstack.org/#/c/261229/ 
>  We're 3 weeks away from HCF, and I 
> think this is too late for such a change. What do you think? Should we 
> proceed and remove nova-network support in 8.0, which is deprecated since 7.0?
> 
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Different versions for different components

[Roman Prykhodchenko]

Aleksandra,

thank you for the clarification, it makes sense to me now.

In my opinion our current approach is not flexible at all and very outdated. 
After splitting fuel-web to smaller components we realized that some of them 
may be actually used outside of a master node as standalone things. In this 
case it is required for some of them to be distributable and upgradable over 
PyPi. It’s also required for different components to be able to make minor 
releases to release important bug fixes and improvements for users that use 
them outside their master nodes. For that we should be able to modify the minor 
version independently.

Do you think it is possible to achieve in the observable future.


- romcheg

> 15 груд. 2015 р. о 12:21 Aleksandra Fedorova <afedor...@mirantis.com> 
> написав(ла):
> 
> Roman,
> 
> we use 8.0 version everywhere in Fuel code _before_ 8.0 release. We
> don't use bump approach, rather bump version, run a development
> and test cycle, then create release and tag it.
> 
> In more details:
> 
> 1) there is a master branch, in which development for upcoming release
> (currently 8.0) happens. All hardcoded version parameters in master
> branch are set to 8.0.
> 
> 2) at Soft Code Freeze (which is one week from now) we create
> stable/8.0 branch from current master. Then we immediately bump
> versions in master branches of all Fuel projects to 9.0.
> Since SCF we have stable/8.0 branch with 8.0 version and master with
> 9.0, but there is still bugfixing in progress, so there might be
> changes in stable/8.0 code.
> 
> 3) On RTM day we finally create 8.0 tags on stable/8.0 branch, and
> this is the time when we should release packages to PyPI and other
> resources.
> 
> 
> 
> On Tue, Dec 15, 2015 at 2:03 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:
>> Folks,
>> 
>> I can see that version for python-fuelclient package is already [1] set to
>> 8.0.0. However, there’s still no corresponding tag and so the version was
>> not released to PyPi.
>> The question is it finally safe to tag different versions for different
>> components? As for Fuel client we need to tag 8.0.0 to push a Debian package
>> for it.
>> 
>> 
>> 1. https://github.com/openstack/python-fuelclient/blob/master/setup.cfg#L3
>> 
>> 
>> - romcheg
>> 
>> 
>> __
>> 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
>> 
> 
> 
> 
> --
> Aleksandra Fedorova
> Fuel CI Team Lead
> bookwar
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Different versions for different components

[Roman Prykhodchenko]

Folks,

I can see that version for python-fuelclient package is already [1] set to 
8.0.0. However, there’s still no corresponding tag and so the version was not 
released to PyPi.
The question is it finally safe to tag different versions for different 
components? As for Fuel client we need to tag 8.0.0 to push a Debian package 
for it.


1. https://github.com/openstack/python-fuelclient/blob/master/setup.cfg#L3 



- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Dropping Python 2.6

[Roman Prykhodchenko]

Fuelers,

Since Mitaka OpenStack Infra has no resources to test python 2.6 support so the 
corresponding jobs are not running anymore. Since Fuel master node is on CentOS 
7 now, let’s drop Python 2.6 support in Fuel.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Dropping Python 2.6

[Roman Prykhodchenko]

Sorry for duplicating discussions. os-dev subsription was broken for me for a 
while so I missed a lot :(

> 14 груд. 2015 р. о 15:23 Evgeniy L <e...@mirantis.com> написав(ла):
> 
> Hi Roman,
> 
> We've discussed it [1], so +1
> 
> [1] 
> https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility
>  
> <https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility>
> 
> On Mon, Dec 14, 2015 at 5:05 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Fuelers,
> 
> Since Mitaka OpenStack Infra has no resources to test python 2.6 support so 
> the corresponding jobs are not running anymore. Since Fuel master node is on 
> CentOS 7 now, let’s drop Python 2.6 support in Fuel.
> 
> 
> - romcheg
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Important: Functional tests are back. Please rebase

[Roman Prykhodchenko]

Fuelers,

for a long time functional tests in Fuel Client were not triggered by Fuel CI 
because of a pesky bug [1] in our tox.ini. The fix [2] for it was landed a few 
minutes ago.

Since we don’t have gate jobs that trigger functional tests, I gently ask you 
to rebase your patches for Fuel Client to the latest master in order to not 
break master branch.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Private links

[Roman Prykhodchenko]

Folks,

on the last two days I have marked several bugs as incomplete because they were 
referring to one or more private resources that are not accessible by anyone 
who does not have a @mirantis.com  account.

Please keep in mind that Fuel is an open source project and the bug tracker we 
use is absolutely public. There should not be any private links in public bugs 
on Launchpad. Please don’t attach links to files on corporate Google Drive or 
tickets to Jira. The same rule should be applied for code reviews.

That said, I’d like to confirm that we can submit world-accessible links to BVT 
results. If not — that should be fixed ASAP.


- romcheg




signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 Roman Prykhodchenko to python-fuelclient cores

[Roman Prykhodchenko]

Guys,

thank you for your trust, I will keep working on improving this small but 
significant part of Fuel’s ecosystem.


- romcheg

> 9 груд. 2015 р. о 21:09 Dmitry Pyzhov <dpyz...@mirantis.com> написав(ла):
> 
> Thank you guys. As there are no objections for a week I'm adding Roman to 
> python-fuelclient-core group. Roman, congratulations! Use your power wisely =)
> 
> On Wed, Dec 2, 2015 at 12:43 PM, Roman Vyalov <rvya...@mirantis.com 
> <mailto:rvya...@mirantis.com>> wrote:
> +1
> 
> On Wed, Dec 2, 2015 at 12:35 PM, Aleksandr Didenko <adide...@mirantis.com 
> <mailto:adide...@mirantis.com>> wrote:
> +1
> 
> On Wed, Dec 2, 2015 at 9:13 AM, Julia Aranovich <jkirnos...@mirantis.com 
> <mailto:jkirnos...@mirantis.com>> wrote:
> +1
> 
> On Tue, Dec 1, 2015 at 10:29 PM Sergii Golovatiuk <sgolovat...@mirantis.com 
> <mailto:sgolovat...@mirantis.com>> wrote:
> +1
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Tue, Dec 1, 2015 at 6:15 PM, Aleksey Kasatkin <akasat...@mirantis.com 
> <mailto:akasat...@mirantis.com>> wrote:
> +1.
> No doubts. )
> 
> 
> Aleksey Kasatkin
> 
> 
> On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov <dpyz...@mirantis.com 
> <mailto:dpyz...@mirantis.com>> wrote:
> Guys,
> 
> I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is 
> the main contributor and maintainer of this repo. And he did a great job 
> making changes toward OpenStack recommendations. Cores, please reply with 
> your +1/-1.
> 
> __
> 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>
> 
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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]Security problem in Fuel 7.0

[Roman Prykhodchenko]

Alexey,

thank you for bringing this up. IMO discussing security problems is better to 
be done in a special kind of Launchpad bugs.

- romcheg


> 7 груд. 2015 р. о 17:36 Alexey Elagin  написав(ла):
> 
> Hello all,
> 
> We have a security problem in Fuel 7.0. It's related to plugin
> development and allows to execute code in mcollective docker container
> on Fuel master node. Any fuel plugin may contains a yaml file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
> an ability to run some code on node with role "master". It's also
> possible to connect to any target node via ssh without a password from
> within the container.
> 
> As i understood, it was made to simplify some deployment cases. I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
> 
> What do you think about it? What deployment cases which require
> execution of code on role "master" do you know?
> 
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Patch size limit

[Roman Prykhodchenko]

Maciej, thanks for bringing this topic up for the discussion!

I absolutely agree with the idea that at this point we have a problem with 
patch size. Patches that are too big usually have two major issues: they either 
don’t get reviewed for a very long time or get random +1s from people who don’t 
even bother reading all the changes there.

Splitting a patch when it’s already published may be pretty problematic, so we 
should think about granularity of every feature on the design stage. Only in 
that way we will be able to submit small patches w/o making compromises on test 
coverage, stability or any other important aspect of the code quality.

Folks proposed two different solutions here:
  1. Set a CI job that puts a -1 to every patch that’s bigger than a certain 
limit.
  2. Make reviewers responsible for -1ing a patch.

Most of the patches that are bigger than 500 LOC can be split. However, there 
is a lot of corner cases we have to carry about, if we are going to put a -1 to 
all of them automatically. In my opinion we should not do that. Instead, we can 
send warning emails to core teams if this kind of patch set is submitted. Then 
a core team may easily analyze whether this patch can be split and propose a 
meaningful way to do that.

Huge patches cause a different story — they are incredibly hard for making a 
good review, merging or reverting them can lead to a major regression in a lot 
of places, they cause conflicts for a lot of other patches and so on. A huge 
patch ALWAYS means exclusively one of the following:
  1. It can be split
  2. The design of the feature is completely wrong.

We need to set a treshold for a huge patch and block all patches that exceed it 
by putting -2 scores.

Summary:

- Let’s set two thresholds — one for to big and one for huge patches.
- Let’s create a job that will warn an appropriate core team if a too big patch 
is submitted and block huge patches.


- romcheg



> 7 груд. 2015 р. о 11:23 Stanislaw Bogatkin  
> написав(ла):
> 
> > What if you're not sure how the improved code should look like, but
> > you definitely sure that it shouldn't look like proposed one? :)
> 
> I believe you should ask other people if you are right, as set '-1' to code 
> that you
> cannot improve is not the best option, so
> 
> 
> > If you are not sure how the improved code would look like, just let it go!
> is right
> 
> 
> Also I think that set some strict boundaries, like 400 LOC per patch is 
> wrong. For example, if you
> introduce new test fixture for fuel-library, it usually about 800+ LOC and 
> you can't split it
> out, so we should either move such fixtures out of code or make an exeption 
> for such type of code.
> 
> On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky  > wrote:
> Hey Andrii,
> 
> I'm totally agree with you about contribution guides, except one thing
> - we need and should force users to split huge patches into set of
> small ones. Mostly because it will simplify support and review of
> patches. Previously we ignored this rule pretty often, and get a lot
> of troubles due to buggy code.
> 
> Also, see some comments below.
> 
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch.
> 
> No one is suggesting to set -1 without leaving a comment how the patch
> could be divided.
> 
> 
> > If you are not sure how the improved code would look like, just let it go!
> 
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
> 
> I'd say it's a good reason to set -1 and start discussion. Not only
> with author, but with other folks, since everyone in community is
> responsible of code quality of the project.
> 
> - I
> 
> On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov  > wrote:
> > I believe this is against the code review guidelines.
> >
> > «Comments must be meaningful and should help an author to change the
> > code the right way.» [1]
> >
> > If you get a comment that says «split this change into the smaller
> > commit» I'm sorry, but it doesn't help at all.
> >
> > «Leave constructive comments
> >
> > Not everyone in the community is a native English speaker, so make
> > sure your remarks are meaningful and helpful for the patch author to
> > change his code, but also polite and respectful.
> >
> > The review is not really about the score. It's all about the
> > comments. When you are reviewing code, always make sure that your
> > comments are useful and helpful to the author of the patch. Try to
> > avoid leaving comments just to show that you reviewed something if
> > they don't really add anything meaningful» [2]
> >
> > So, when an author of a 

Re: [openstack-dev] [Fuel] Patch size limit

[Roman Prykhodchenko]

Following up on my previous email:

Every blueprint specification has a Work items section. That section should 
describe granular work items, not just things in general. We should encourage 
components leads to put their attention to this aspect.



> 7 груд. 2015 р. о 12:23 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Maciej, thanks for bringing this topic up for the discussion!
> 
> I absolutely agree with the idea that at this point we have a problem with 
> patch size. Patches that are too big usually have two major issues: they 
> either don’t get reviewed for a very long time or get random +1s from people 
> who don’t even bother reading all the changes there.
> 
> Splitting a patch when it’s already published may be pretty problematic, so 
> we should think about granularity of every feature on the design stage. Only 
> in that way we will be able to submit small patches w/o making compromises on 
> test coverage, stability or any other important aspect of the code quality.
> 
> Folks proposed two different solutions here:
>   1. Set a CI job that puts a -1 to every patch that’s bigger than a certain 
> limit.
>   2. Make reviewers responsible for -1ing a patch.
> 
> Most of the patches that are bigger than 500 LOC can be split. However, there 
> is a lot of corner cases we have to carry about, if we are going to put a -1 
> to all of them automatically. In my opinion we should not do that. Instead, 
> we can send warning emails to core teams if this kind of patch set is 
> submitted. Then a core team may easily analyze whether this patch can be 
> split and propose a meaningful way to do that.
> 
> Huge patches cause a different story — they are incredibly hard for making a 
> good review, merging or reverting them can lead to a major regression in a 
> lot of places, they cause conflicts for a lot of other patches and so on. A 
> huge patch ALWAYS means exclusively one of the following:
>   1. It can be split
>   2. The design of the feature is completely wrong.
> 
> We need to set a treshold for a huge patch and block all patches that exceed 
> it by putting -2 scores.
> 
> Summary:
> 
> - Let’s set two thresholds — one for to big and one for huge patches.
> - Let’s create a job that will warn an appropriate core team if a too big 
> patch is submitted and block huge patches.
> 
> 
> - romcheg
> 
> 
> 
>> 7 груд. 2015 р. о 11:23 Stanislaw Bogatkin <sbogat...@mirantis.com 
>> <mailto:sbogat...@mirantis.com>> написав(ла):
>> 
>> > What if you're not sure how the improved code should look like, but
>> > you definitely sure that it shouldn't look like proposed one? :)
>> 
>> I believe you should ask other people if you are right, as set '-1' to code 
>> that you
>> cannot improve is not the best option, so
>> 
>> 
>> > If you are not sure how the improved code would look like, just let it go!
>> is right
>> 
>> 
>> Also I think that set some strict boundaries, like 400 LOC per patch is 
>> wrong. For example, if you
>> introduce new test fixture for fuel-library, it usually about 800+ LOC and 
>> you can't split it
>> out, so we should either move such fixtures out of code or make an exeption 
>> for such type of code.
>> 
>> On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky <ikalnit...@mirantis.com 
>> <mailto:ikalnit...@mirantis.com>> wrote:
>> Hey Andrii,
>> 
>> I'm totally agree with you about contribution guides, except one thing
>> - we need and should force users to split huge patches into set of
>> small ones. Mostly because it will simplify support and review of
>> patches. Previously we ignored this rule pretty often, and get a lot
>> of troubles due to buggy code.
>> 
>> Also, see some comments below.
>> 
>> > So, when an author of a patch gets -1 with the statement «split this
>> > code», I believe it is not constructive. At least you should roughly
>> > describe how you see it, how the patch could be split, you should be
>> > helpful to the author of a patch.
>> 
>> No one is suggesting to set -1 without leaving a comment how the patch
>> could be divided.
>> 
>> 
>> > If you are not sure how the improved code would look like, just let it go!
>> 
>> What if you're not sure how the improved code should look like, but
>> you definitely sure that it shouldn't look like proposed one? :)
>> 
>> I'd say it's a good reason to set -1 and start discussion. Not only
>> with author, but with other folks, since everyone in community is
>> responsible of code quality of the project.
>>

[openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

[Roman Prykhodchenko]

Hi fulers!
I’d like to let you know that because of the bug [1] in tox 2.2.1 we had to 
change [2] tox.ini temporarily to unlock the gate until the author of tox is 
working on the fix for the problem. Those changes in tox.ini revoke all freedom 
of configuring how tests on one’s local environment are run, so all environment 
variables except FUEL_WEB_ROOT and TEST_NAILGUN_DB are ignored.
Please also note, that setting those two variables is now _mandatory_ — tests 
will fail with strange errors, if that is not done. I will keep you updated as 
soon as tox is fixed and the temporary changes to tox.ini are reverted.

- romcheg




signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Important notice about running tests for python-fuelclient

[Roman Prykhodchenko]

Maciej,

thank you very much for providing the links. Sorry for inconvenience.


- romcheg
> 23 лист. 2015 р. о 12:48 Maciej Kwiek <mkw...@mirantis.com> написав(ла):
> 
> Missing links from this email:
> [1] 
> https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files
>  
> <https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files>
> [2] https://review.openstack.org/#/c/247452/6 
> <https://review.openstack.org/#/c/247452/6>
> 
> On Mon, Nov 23, 2015 at 12:45 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Hi fulers!
> I’d like to let you know that because of the bug [1] in tox 2.2.1 we had to 
> change [2] tox.ini temporarily to unlock the gate until the author of tox is 
> working on the fix for the problem. Those changes in tox.ini revoke all 
> freedom of configuring how tests on one’s local environment are run, so all 
> environment variables except FUEL_WEB_ROOT and TEST_NAILGUN_DB are ignored.
> Please also note, that setting those two variables is now _mandatory_ — tests 
> will fail with strange errors, if that is not done. I will keep you updated 
> as soon as tox is fixed and the temporary changes to tox.ini are reverted.
> 
> - romcheg
> 
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Changing APIs and API versioning

[Roman Prykhodchenko]

Folks.

This happened again. Nailgun’s API was silently changed [1] breaking 
python-fuelclient and everything else that was relying on it.

I feel like this is the point when just discussing the issue is not enough so I 
call for a vote: Let’s separate Nailgun from Fuel UI and put them into 
different repositories now.

Please cast your votes (either +1 or -1) to this thread. You can also provide 
your reasoning and more thoughts.


- romcheg


1. https://review.openstack.org/#/c/240234/ 
<https://review.openstack.org/#/c/240234/>

> 26 жовт. 2015 р. о 11:11 Sebastian Kalinowski <skalinow...@mirantis.com> 
> написав(ла):
> 
> 2015-10-23 11:36 GMT+02:00 Igor Kalnitsky <ikalnit...@mirantis.com 
> <mailto:ikalnit...@mirantis.com>>:
> Roman, Vitaly,
> 
> You're both saying right things, and you guys bring a sore topic up again.
> 
> The thing is that Nailgun's API isn't the best one.. but we're trying
> to improve it step-by-step, from release to release. We have so many
> things to reconsider and to fix that it'd require a huge effort to
> make backward compatible changes and support it. So we decided ignore
> backward compatibility for clients for awhile and consider our API as
> unstable.
> 
> I agree with Roman that such changes must not be made secretly, and we
> should at least announce about them. Moreover, every core must think
> about consequences before approving them.
> 
> So I propose to do the following things when backward incompatible
> change to API is required:
> 
> * Announce this change in openstack-dev ML.
> * Wait 1 week before approving it, so anyone can prepare.
> * Change author has to work with QA in order make sure they are
> prepared for this change.
> 
> Any thoughts?
> 
> 
> +1.
> 
> Although there is one thing that you didn't mention (but probably everyone 
> know about it)
> is to solve the issue with fuelclient not beign tested against changes in 
> nailgun.
> We need not only run it for every change in nailgun (or for only those that 
> touch files under "api"
> dir) but also cover more endpoints with fuelclient tests against real API, 
> not mocks, to discover
> such issues earlier.
> 
> 
> Thanks,
> Igor
> 
> On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh
> <vkramsk...@mirantis.com <mailto:vkramsk...@mirantis.com>> wrote:
> > JFYI: (re-)start of this discussion was instigated by merge of this change
> > (and here is revert).
> >
> > And this is actually not the first time when we make backward incompatible
> > changes in our API. AFAIR, the last time it was also about the network
> > configuration handler. We decided not to consider our API frozen, make the
> > changes and break backward compatibility. So now is the time to reconsider
> > this.
> >
> > API backward compatibility is a must for good software, but we also need to
> > understand that introducing API versioning is not that easy and will
> > increase efforts needed to make new changes in nailgun.
> >
> > I'd go this way:
> >
> > Estimate the priority of introducing API versioning - maybe we have other
> > things we should invest our resources to
> > Estimate all the disadvantages this decision might have
> > Fix all the issues in the current API (like this one)
> > Implement API versioning support (yes, we don't have this mechanism yet, so
> > we can't just "bump API version" like Sergii suggested in another thread)
> > Consider the current API as frozen v1, so backward incompatible changes (or
> > maybe all the changes?) should go to v2
> >
> >
> > 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko <m...@romcheg.me 
> > <mailto:m...@romcheg.me>>:
> >>
> >> Hi folks,
> >>
> >> I’d like to touch the aspect of Fuel development process that seems to be
> >> as wrong as possible. That aspect is how we change the API.
> >>
> >> The issue is that in Fuel anyone can change API at any point of time
> >> without even warning the rest of the same component’s team. Relying on this
> >> kind of API is basically impossible. We constantly have problems when even
> >> components of Fuel stop working due to unexpected changes in the API.
> >> Thinking about another software that must be integrated with Fuel is hardly
> >> possible with the current approach.
> >>
> >> As for a grown-up project there is a strong need for Fuel in general and
> >> for Nailgun in particular to work on a policy for making changes to their
> >> APIs. Living in OpenStack ecosystem we must at least take a look how it’s
> >> done in 

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Roman Prykhodchenko]

Folks, we should resurrect this thread and find a consensus.

> 1 вер. 2015 р. о 15:00 Andrey Danin <ada...@mirantis.com> написав(ла):
> 
> +1 to Igor.
> 
> It's definitely not a High bug. The biggest problem I see here is a confusing 
> error message with a wrong number of required IPs. AFAIU we cannot fix it 
> easily now so let's postpone it to 8.0 but change a message itself [0] in 7.0.
> 
> [0] 
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>  
> <https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163>
> 
> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com 
> <mailto:ikalnit...@mirantis.com>> wrote:
> Hello,
> 
> My 5 cents on it.
> 
> I don't think it's really a High or Critical bug for 7.0. If there's
> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
> actually Ok, it may fail by different reason without starting actual
> deployment (sending message to Astute).
> 
> But I agree it's kinda strange that we don't check IPs during network
> verification step. The good fix in my opinion is to move this check
> into network checker (perhaps keep it here either), but that
> definitely shouldn't be done in 7.0.
> 
> Thanks,
> Igor
> 
> 
> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> > Hi folks!
> >
> > Recently a problem that network check does not tell whether there’s enough 
> > IP addresses in a public network [1] was reported. That check is performed 
> > by CheckBeforeDeployment task, but there is two problems that happen 
> > because this verification is done that late:
> >
> >  - A deployment fails, if there’s not enough addresses in specified ranges
> >  - If a user wants to get network configuration they will get an error
> >
> > The solution for this problems seems to be easy and a straightforward patch 
> > [2] was proposed. However, there is a hidden problem which is that patch 
> > does not address which is that installed plugins may reserve VIPs for their 
> > needs. The issue is that they do it just before deployment and so it’s not 
> > possible to get those reservations when a user wants to check their network 
> > set up.
> >
> > The important issue we have to address here is that network configuration 
> > generator will fail, if specified ranges don’t fit all VIPs. There were 
> > several proposals to fix that, I’d like to highlight two of them:
> >
> >  a) Allow VIPs to not have an IP address assigned, if network config 
> > generator works for API output.
> >  That will prevent GET requests from failure, but since IP addresses 
> > for VIPs are required, generator will have to fail, if it generates a 
> > configuration for the orchestrator.
> >  b) Add a release note that users have to calculate IP addresses manually 
> > and put sane ranges in order to not shoot their own legs. Then it’s also 
> > possible to change network verification output to remind users to check the 
> > ranges before starting a deployment.
> >
> > In my opinion we cannot follow (a) because it only masks a problem instead 
> > of providing a fix. Also it requires to change the API which is not a good 
> > thing to do after the SCF. If we choose (b), then we can work on a firm 
> > solution in 8.0 and fix the problem for real.
> >
> >
> > P. S. We can still merge [2], because it checks, if IP ranges can at least 
> > fit the basic configuration. If you agree, I will update it soon.
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1487996 
> > <https://bugs.launchpad.net/fuel/+bug/1487996>
> > [2] https://review.openstack.org/#/c/217267/ 
> > <https://review.openstack.org/#/c/217267/>
> >
> >
> >
> > - romcheg
> >
> >
> >
> >
> > __
> > 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 
> <

[openstack-dev] [Fuel] Changing APIs and API versioning

[Roman Prykhodchenko]

Hi folks,

I’d like to touch the aspect of Fuel development process that seems to be as 
wrong as possible. That aspect is how we change the API.

The issue is that in Fuel anyone can change API at any point of time without 
even warning the rest of the same component’s team. Relying on this kind of API 
is basically impossible. We constantly have problems when even components of 
Fuel stop working due to unexpected changes in the API. Thinking about another 
software that must be integrated with Fuel is hardly possible with the current 
approach.

As for a grown-up project there is a strong need for Fuel in general and for 
Nailgun in particular to work on a policy for making changes to their APIs. 
Living in OpenStack ecosystem we must at least take a look how it’s done in its 
components and try to do something similar. After working with Nova, Keystone, 
Ironic and other components I would propose to start with the following: let’s 
not make any changes to the API. Instead, let’s create a new version of 
Nailgun’s API that will appear in Fuel 8.0 and make all the changes there. That 
is the thing that will instantaneously make lives of other components much 
easier, if we make it now.

After doing the essential part let’s think about how we are going to live with 
that in the future. There are several APIs in Fuel, the rest of the email is 
only touching Nailgun’s REST API. I can see the things somehow like the 
following:

 - Introduce API documentation by embedding Swagger and Swagger UI.
   The current approach when we leave API docs for documentation team is not 
effective. Swagger generates the documentation and resolves this issue.
 - After releasing a version of Fuel, it’s API is called stable and frozen for 
any changes, unless they allign API to the documentation or documentation to 
the API.
 - All changes to a stable APIs must be backported to the stable version of 
Fuel that introduced the corresponding API.
 - In order to guarantee that a stable API is not changed, Jenkins jobs should 
make automatic checks for every new patch set

Details about all the above mentioned proposals can be discussed in separate 
threads so this one will stay uncluttered. I'd like to also summon those 
OpenStack folks, who tried to resolve the same issue and ask them about any 
common solutions in the ecosystem.


- romcheg






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Assigning VIPs on network config serialization

[Roman Prykhodchenko]

Then we should close [1] as invalid, shoudn’t we?

> 20 жовт. 2015 р. о 15:55 Igor Kalnitsky <ikalnit...@mirantis.com> написав(ла):
> 
> Roman,
> 
>> This behavior is actually described in [1]. Should we allocate
>> VIPs on network check as well?
> 
> No, we shouldn't. We should check whether it's enough IPs for nodes /
> VIPs with current network configuration, but no more.
> 
> - igor
> 
> On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky <ikalnit...@mirantis.com> 
> wrote:
>> Andrew,
>> 
>>> but the problem lies that VIP's need to already be allocated.
>> 
>> Why? Fuel doesn't use them on this stage.
>> 
>> 
>>> They need to be allocated on network update, or when a node role requiring
>>> one is added to the environment.
>> 
>> It looks like either you or me misunderstood something. AFAIK, node
>> role itself has nothing in common with VIPs. It doesn't require any of
>> them.
>> 
>> Currently VIPs are requested by network roles, and network roles are
>> the same for all nodes (except Network Templating case). Network roles
>> are assigned on network, and if VIP is required for network role it
>> will be allocated in the assigned network.
>> 
>> So basically, it requires a huge effort to redesign our allocation
>> system to achieve what you want, because:
>> 
>> * Each time you reassign network role, the corresponding VIP should be
>> re-allocated in the database either.
>> * Each time you enable/disable plugins, the VIPs should be
>> re-allocated, because plugins may export network roles.
>> * Each time you add new node to cluster, the VIPs should be
>> re-allocated, because with new node you simply may run out of free
>> IPs. And, btw, should we assign IP on added nodes here? Or maybe
>> postpone to serialization step?
>> 
>> Well, Andrew, I believe we don't have enough resources to implement
>> your proposal. Moreover, the proposed approach requires a lot of
>> discussions and design meetings. And it definitely should be
>> implemented in scope of some blueprint, not a bugfix.
>> 
>> 
>>> Not knowing the address until serialization for deployment is too late.
>> 
>> Once again - why? I agree, perhaps it would be useful, but there's no
>> strict requirement on this and we should resolve our issues
>> step-by-step. See my response above.
>> 
>> 
>>> No, Again, this is too late.
>> 
>> Too late for what?
>> 
>> 
>> - Igor
>> 
>> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko <m...@romcheg.me> 
>> wrote:
>>> My concern here is that there is also a Network check feature that 
>>> according to its name should check things like whether or not there’s 
>>> enough IP addresses in all ranges in a network. The problem is that it may 
>>> be run at any time, even when VIPs are not yet allocated. From a user-side 
>>> the workflow may look a little wrong:
>>> 
>>> 1. Check network => get "Everything is fine"
>>> 2. Right after that press Apply Changes => get "Network configuration is 
>>> bad"
>>> 
>>> This behavior is actually described in [1]. Should we allocate VIPs on 
>>> network check as well?
>>> 
>>> 
>>> 1. https://bugs.launchpad.net/fuel/+bug/1487996
>>> 
>>> 
>>> - romcheg
>>> 
>>> 
>>>> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky <ikalnit...@mirantis.com> 
>>>> написав(ла):
>>>> 
>>>> Hi Roman,
>>>> 
>>>>> Not assign addresses to VIPs is a network configuration is being
>>>>> serialized for API output.
>>>> 
>>>> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
>>>> So we can keep only *public* VIP, and do not assign / show others.
>>>> 
>>>>> Check number of IP addresses wherever it is possible to "spoil" network
>>>>> configuration: when a role get’s assigned to a node, when network
>>>>> changes or network templates are applied.
>>>> 
>>>> It won't work that way. What if you enable plugin when all roles are
>>>> assigned? What if you change networks, and now it's not enough IPs? Or
>>>> what if enable plugin that requires 5 VIPs in public network by
>>>> default, and it's not enough. But by using network templates you
>>>> assign this netrole to management network?
>>>> 
>>>> From what I can

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

[Roman Prykhodchenko]

My concern here is that there is also a Network check feature that according to 
its name should check things like whether or not there’s enough IP addresses in 
all ranges in a network. The problem is that it may be run at any time, even 
when VIPs are not yet allocated. From a user-side the workflow may look a 
little wrong:

 1. Check network => get "Everything is fine"
 2. Right after that press Apply Changes => get "Network configuration is bad"

This behavior is actually described in [1]. Should we allocate VIPs on network 
check as well?


1. https://bugs.launchpad.net/fuel/+bug/1487996


- romcheg


> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky <ikalnit...@mirantis.com> написав(ла):
> 
> Hi Roman,
> 
>> Not assign addresses to VIPs is a network configuration is being
>> serialized for API output.
> 
> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
> So we can keep only *public* VIP, and do not assign / show others.
> 
>> Check number of IP addresses wherever it is possible to "spoil" network
>> configuration: when a role get’s assigned to a node, when network
>> changes or network templates are applied.
> 
> It won't work that way. What if you enable plugin when all roles are
> assigned? What if you change networks, and now it's not enough IPs? Or
> what if enable plugin that requires 5 VIPs in public network by
> default, and it's not enough. But by using network templates you
> assign this netrole to management network?
> 
> From what I can say the proposed approach requires to put checks
> here-and-there around the code. Let's do not overcomplicate things
> without real need.
> 
> So let me share my thoughts regarding this issue.
> 
> * We shouldn't *allocate* VIPs when we make GET request on network
> configuration handler. It should return only *already allocated* VIPs
> and no more.
> * VIP allocation should be performed when we run deployment.
> * Before deployment checks should fail, if there's not enough VIPs or
> other resources. So users fix them, and try again.
> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
> it's safe to return allocated VIPs on that stage.
> 
> So what do you think guys?
> 
> Thanks,
> Igor
> 
> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:
>> Hi folks!
>> 
>> I’ve been discussing several bugs [1-3] with some folks and noticed that 
>> they share the same root cause which is that network serialization fails, if 
>> there’s not enough IP addresses in all available ranges of one of the 
>> available networks to assign them to all VIPs. There are several possible 
>> solutions for this issue:
>> 
>> a. Not assign addresses to VIPs is a network configuration is being 
>> serialized for API output.
>> A lot of external tools and modules, i. e., OSTF, rely on that information 
>> so this relatively small change in Nailgun will require big cross-components 
>> changes. Therefore this change can only be done as a feature but it seems to 
>> be the way this issue must be fixed.
>> 
>> b. Leave some VIPs without IP addresses
>> If network configuration is generated for API output it is possible to leave 
>> some VIPs without IP addresses assigned. This will only create more mess 
>> around Nailgun and bring more issues that it will resolve.
>> 
>> c. Check number of IP addresses wherever it is possible to "spoil" network 
>> configuration: when a role get’s assigned to a node, when network changes or 
>> network templates are applied.
>> 
>> 
>> The proposal is to follow [c] as a fast solution and file a blueprint for 
>> [a]. Opinions?
>> 
>> 
>> 1 https://bugs.launchpad.net/fuel/+bug/1487996
>> 2 https://bugs.launchpad.net/fuel/+bug/1500394
>> 3 https://bugs.launchpad.net/fuel/+bug/1504572
>> 
>> 
>> - romcheg
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Assigning VIPs on network config serialization

[Roman Prykhodchenko]

Hi folks!

I’ve been discussing several bugs [1-3] with some folks and noticed that they 
share the same root cause which is that network serialization fails, if there’s 
not enough IP addresses in all available ranges of one of the available 
networks to assign them to all VIPs. There are several possible solutions for 
this issue:

a. Not assign addresses to VIPs is a network configuration is being serialized 
for API output.
A lot of external tools and modules, i. e., OSTF, rely on that information so 
this relatively small change in Nailgun will require big cross-components 
changes. Therefore this change can only be done as a feature but it seems to be 
the way this issue must be fixed.

b. Leave some VIPs without IP addresses
If network configuration is generated for API output it is possible to leave 
some VIPs without IP addresses assigned. This will only create more mess around 
Nailgun and bring more issues that it will resolve.

c. Check number of IP addresses wherever it is possible to "spoil" network 
configuration: when a role get’s assigned to a node, when network changes or 
network templates are applied.


The proposal is to follow [c] as a fast solution and file a blueprint for [a]. 
Opinions?


1 https://bugs.launchpad.net/fuel/+bug/1487996
2 https://bugs.launchpad.net/fuel/+bug/1500394
3 https://bugs.launchpad.net/fuel/+bug/1504572


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 related functionality in Fuel Client

[Roman Prykhodchenko]

Since there are already two services Fuel Client has to interact with, I filed 
a bug, for using service discovery: https://bugs.launchpad.net/fuel/+bug/1504471

> 9 жовт. 2015 р. о 11:25 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> In that case I would suggest to also use Keystone service directory for 
> discovering services.
> 
>> 9 жовт. 2015 р. о 11:00 Evgeniy L <e...@mirantis.com 
>> <mailto:e...@mirantis.com>> написав(ла):
>> 
>> >> I’d say even if it will be a separate service it’s better to proxy 
>> >> requests through Nailgun’s API to have a single entry point.
>> 
>> I don't think that application such as Nailgun should be responsible for 
>> proxying
>> requests, we solved similar problem for OSTF with adding proxy rule in Nginx.
>> 
>> Thanks,
>> 
>> On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko <m...@romcheg.me 
>> <mailto:m...@romcheg.me>> wrote:
>> I’d say even if it will be a separate service it’s better to proxy requests 
>> through Nailgun’s API to have a single entry point.
>> 
>>> 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com 
>>> <mailto:e...@mirantis.com>> написав(ла):
>>> 
>>> Hi,
>>> 
>>> +1, but I think it's better to spawn separate service, instead of adding it 
>>> to Nailgun.
>>> 
>>> Thanks,
>>> 
>>> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me 
>>> <mailto:m...@romcheg.me>> wrote:
>>> Folks,
>>> 
>>> it’s time to speak about Fuel Plugins and the way they are managed.
>>> 
>>> Currently we have some methods in Fuel Client that allow to install, remove 
>>> and do some other things to plugins. Everything looks great except that 
>>> functionality requires Fuel Client to be installed on a master node and be 
>>> running under a root user. It’s time for us to grow up and realize that 
>>> nothing can require Fuel Client to be installed on a specific computer and 
>>> of course we cannot require root permissions for any actions.
>>> 
>>> I’d like to move all that code to Nailgun, utilizing mules and hide it 
>>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and 
>>> I’d like to ask Fuel Enhancements subgroup of developers to take a close 
>>> look at it.
>>> 
>>> 
>>> 1. https://bugs.launchpad.net/fuel/+bug/1504338 
>>> <https://bugs.launchpad.net/fuel/+bug/1504338>
>>> 
>>> 
>>> - romcheg
>>> 
>>> 
>>> __
>>> 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 
>>> <mailto: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 
>> <mailto: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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 related functionality in Fuel Client

[Roman Prykhodchenko]

In that case I would suggest to also use Keystone service directory for 
discovering services.

> 9 жовт. 2015 р. о 11:00 Evgeniy L <e...@mirantis.com> написав(ла):
> 
> >> I’d say even if it will be a separate service it’s better to proxy 
> >> requests through Nailgun’s API to have a single entry point.
> 
> I don't think that application such as Nailgun should be responsible for 
> proxying
> requests, we solved similar problem for OSTF with adding proxy rule in Nginx.
> 
> Thanks,
> 
> On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> I’d say even if it will be a separate service it’s better to proxy requests 
> through Nailgun’s API to have a single entry point.
> 
>> 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com 
>> <mailto:e...@mirantis.com>> написав(ла):
>> 
>> Hi,
>> 
>> +1, but I think it's better to spawn separate service, instead of adding it 
>> to Nailgun.
>> 
>> Thanks,
>> 
>> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me 
>> <mailto:m...@romcheg.me>> wrote:
>> Folks,
>> 
>> it’s time to speak about Fuel Plugins and the way they are managed.
>> 
>> Currently we have some methods in Fuel Client that allow to install, remove 
>> and do some other things to plugins. Everything looks great except that 
>> functionality requires Fuel Client to be installed on a master node and be 
>> running under a root user. It’s time for us to grow up and realize that 
>> nothing can require Fuel Client to be installed on a specific computer and 
>> of course we cannot require root permissions for any actions.
>> 
>> I’d like to move all that code to Nailgun, utilizing mules and hide it 
>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d 
>> like to ask Fuel Enhancements subgroup of developers to take a close look at 
>> it.
>> 
>> 
>> 1. https://bugs.launchpad.net/fuel/+bug/1504338 
>> <https://bugs.launchpad.net/fuel/+bug/1504338>
>> 
>> 
>> - romcheg
>> 
>> 
>> __
>> 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 
>> <mailto: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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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 related functionality in Fuel Client

[Roman Prykhodchenko]

I’d say even if it will be a separate service it’s better to proxy requests 
through Nailgun’s API to have a single entry point.

> 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com> написав(ла):
> 
> Hi,
> 
> +1, but I think it's better to spawn separate service, instead of adding it 
> to Nailgun.
> 
> Thanks,
> 
> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko <m...@romcheg.me 
> <mailto:m...@romcheg.me>> wrote:
> Folks,
> 
> it’s time to speak about Fuel Plugins and the way they are managed.
> 
> Currently we have some methods in Fuel Client that allow to install, remove 
> and do some other things to plugins. Everything looks great except that 
> functionality requires Fuel Client to be installed on a master node and be 
> running under a root user. It’s time for us to grow up and realize that 
> nothing can require Fuel Client to be installed on a specific computer and of 
> course we cannot require root permissions for any actions.
> 
> I’d like to move all that code to Nailgun, utilizing mules and hide it behind 
> Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d like to 
> ask Fuel Enhancements subgroup of developers to take a close look at it.
> 
> 
> 1. https://bugs.launchpad.net/fuel/+bug/1504338 
> <https://bugs.launchpad.net/fuel/+bug/1504338>
> 
> 
> - romcheg
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Thank you guys for all your help! Special thanks to Robert who helped to find a 
workaround for an issue [1] that didn’t let us use testr for Fuel Client. The 
patch [2] was merged and both unit and functional tests are launched by subunit 
and the data is maintained by testrepository.

Please also note that in order to facilitate debugging two additional tox 
environments —  dbgunit or dbgfunc,  were introduced for either unit or 
functional tests.


1. https://bugs.launchpad.net/testrepository/+bug/1504310 
<https://bugs.launchpad.net/testrepository/+bug/1504310>
2. https://review.openstack.org/#/c/227895/


- romcheg


> 9 жовт. 2015 р. о 01:51 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Folks,
> 
> Since we’ve reached the consensus here I’d like to invite you to review the 
> patch [1] that replaces py.test with testr without making debuging or running 
> specific tests harder. Please also note that it has a dependency which needs 
> to be reviewed and merged first one.
> 
> 1. https://review.openstack.org/#/c/227895
> 
> 
> - romcheg
> 
> 
>> 7 жовт. 2015 р. о 14:41 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
>> 
>> Michał,
>> 
>> some comments in-line
>> 
>>>> - testrepository and related components are used in OpenStack Infra
>>>> environment for much more tasks than just running tests
>>> 
>>> If by "more tasks" you mean parallel testing, py.test also has a
>>> possibility to do that by pytest-xdist.
>> 
>> As Monthy mentioned, it’s not only about testing, it’s more about deeper 
>> integration with OpenStack Infra.
>> 
>> 
>>>> - py.test won’t be added to global-requirements so there always be a chance
>>>> of another dependency hell
>>> 
>>> As Igor Kalnitsky said, py.test doesn't have much requirements.
>>> https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
>>> It's only argparse, which already is in global requirements without
>>> any version pinned.
>> 
>> It’s not only about py.test, there is an up-to-date objective of sticking 
>> all requirements to global-requirements because we have big problems because 
>> of that every release.
>> 
>>> 
>>> Cheers,
>>> Michal
>>> 
>>> __
>>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Plugins related functionality in Fuel Client

[Roman Prykhodchenko]

Folks,

it’s time to speak about Fuel Plugins and the way they are managed.

Currently we have some methods in Fuel Client that allow to install, remove and 
do some other things to plugins. Everything looks great except that 
functionality requires Fuel Client to be installed on a master node and be 
running under a root user. It’s time for us to grow up and realize that nothing 
can require Fuel Client to be installed on a specific computer and of course we 
cannot require root permissions for any actions.

I’d like to move all that code to Nailgun, utilizing mules and hide it behind 
Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d like to 
ask Fuel Enhancements subgroup of developers to take a close look at it.


1. https://bugs.launchpad.net/fuel/+bug/1504338


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Folks,

Since we’ve reached the consensus here I’d like to invite you to review the 
patch [1] that replaces py.test with testr without making debuging or running 
specific tests harder. Please also note that it has a dependency which needs to 
be reviewed and merged first one.

1. https://review.openstack.org/#/c/227895


- romcheg


> 7 жовт. 2015 р. о 14:41 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Michał,
> 
> some comments in-line
> 
>>> - testrepository and related components are used in OpenStack Infra
>>> environment for much more tasks than just running tests
>> 
>> If by "more tasks" you mean parallel testing, py.test also has a
>> possibility to do that by pytest-xdist.
> 
> As Monthy mentioned, it’s not only about testing, it’s more about deeper 
> integration with OpenStack Infra.
> 
> 
>>> - py.test won’t be added to global-requirements so there always be a chance
>>> of another dependency hell
>> 
>> As Igor Kalnitsky said, py.test doesn't have much requirements.
>> https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
>> It's only argparse, which already is in global requirements without
>> any version pinned.
> 
> It’s not only about py.test, there is an up-to-date objective of sticking all 
> requirements to global-requirements because we have big problems because of 
> that every release.
> 
>> 
>> Cheers,
>> Michal
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

What I can extract now from this thread is that Fuel should switch to testr 
because of the following reasons:

- Diversity of tools is a bad idea on a project scale
- testrepository and related components are used in OpenStack Infra environment 
for much more tasks than just running tests
- py.test won’t be added to global-requirements so there always be a chance of 
another dependency hell
- Sticking to global requirements is an idea which is in the scope of 
discussions around Fuel.

Sounds like that’s the point when we should just file appropriate bugs and use 
testr in smaller components, e. g., Fuel Client, first and then try in in 
Nailgun.


- romcheg

> 7 жовт. 2015 р. о 02:06 Monty Taylor <mord...@inaugust.com> написав(ла):
> 
> On 10/06/2015 06:01 PM, Thomas Goirand wrote:
>> On 10/06/2015 01:14 PM, Yuriy Taraday wrote:
>>> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko <m...@romcheg.me
>>> <mailto:m...@romcheg.me>> wrote:
>>> 
>>> Atm I have the following pros. and cons. regarding testrepository:
>>> 
>>> pros.:
>>> 
>>> 1. It’s ”standard" in OpenStack so using it gives Fuel more karma
>>> and moves it more under big tent
>>> 
>>> 
>>> I don't think that big tent model aims at eliminating diversity of tools
>>> we use in our projects. A collection of web frameworks used in big tent
>>> is an example of that.
>> 
>> From the downstream distro point of view, I don't agree in general, and
>> with the web framework in particular. (though it's less a concern for
>> the testr vs pbr). We keep adding dependencies and duplicates, but never
>> remove them. For example, tablib and suds/sudsjurko need to be removed
>> because they are not maintainable, there's not much work to do so, but
>> nobody does the work...
> 
> The Big Tent has absolutely no change in opinion about eliminating diversity 
> of tools. OpenStack has ALWAYS striven to reduce diversity of tools. Big Tent 
> applies OpenStack to more things that request to be part of OpenStack.
> 
> Nothing has changed in the intent.
> 
> Diversity of tools in a project this size is a bad idea. Always has been. 
> Always will be.
> 
> The amount of web frameworks in use is a bug.
> 
>>> 2. It’s in global requirements, so it doesn’t cause dependency hell
>>> 
>>> That can be solved by adding py.test to openstack/requirements.
> 
> No, it cannot. py.test/testr is not about dependency management. It's about a 
> much bigger picture of how OpenStack does development and how that 
> development can be managed.
> 
>> I'd very much prefer if we could raise the barrier for getting a 3rd
>> party new dependency in. I hope we can talk about this in Tokyo. That
>> being said, indeed, adding py.test isn't so much of a problem, as it is
>> widely used, already packaged, and maintained upstream. I'd still prefer
>> if all projects were using the same testing framework and test runner
>> though.
> 
> As I said earlier in this thread, it has already been decided by the TC long 
> ago that we will use testr. Barring a (very unlikely) TC rescinding of that 
> decision, OpenStack projects use testr. There is zero value in expanding the 
> number of test runners.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> <mailto: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>


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Yuri,

sticking to global requirements and interacting deeper with OpenStack Infra are 
up-to-date objectives for Fuel and those are pretty much technical question. 
However, software development is not only solving technical tasks, it also 
incorporates interaction between people and other teams so you cannot separate 
those thinks, even if it sounds too much like politics.

- romcheg

> 7 жовт. 2015 р. о 13:20 Yuriy Taraday  написав(ла):
> 
> On Wed, Oct 7, 2015 at 12:51 AM Monty Taylor  > wrote:
> On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote:
> > I've already wrote in the review that caused this thread that I do not want
> > to blindly follow rules for using one or another. We should always consider
> > technical requirements. And I do not see a reason to leave py.test (and
> > nobody
> > show me such reason) and replace it with something else.
> 
> Hi!
> 
> The reason is that testrepository is what OpenStack uses and as I
> understand it, Fuel wants to join the Big Tent.
> 
> It saddens me that once again choice of library is being forced upon a 
> project based on what other projects use, not on technical merit. py.test is 
> more than just a (way better) test runner, it allows to write tests with less 
> boilerplate and more power. While its features are not extensively used in 
> Fuel code, switching to testr would still require changing test logic which 
> is generally bad (that's why mox is still in use in OpenStack). Can we avoid 
> that?
> 
> The use of testr is documented in the Project Testing Interface:
> 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/project-testing-interface.rst#n78
>  
> 
> 
> There are many reasons for it, but in large part we are continually
> adding more and more tools to process subunit output across the board in
> the Gate. subunit2sql is an important one, as it will be feeding into
> expanded test result dashboards.
> 
> We also have zuul features in the pipeline to be able to watch the
> subunit streams in real time to respond more quickly to issues in test runs.
> 
> We also have standard job builders based around tox and testr. Having
> project divergence in this area is a non-starter when there are over 800
> repositories.
> 
> So it seems that all that's needed to keep py.test as an option is a plugin 
> for py.test that generates subunit stream like Robert said, is that right?
> 
> In short, while I understand that this seems like an area where a
> project can do whatever it wants to, it really isn't. If it's causing
> you excessive pain, I recommend connecting with Robert on ways to make
> improvements to testrepository. Those improvements will also have the
> effect of improving life for the rest of OpenStack, which is also a
> great reason why we all use the same tools rather than foster an
> environment of per-project snowflakes.
> 
> I wouldn't call py.test a snowflake. It's a very well-established testing 
> tool and OpenStack projects could benefit from using it if we integrate it 
> with testr well.
> __
> 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 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Michał,

some comments in-line

>> - testrepository and related components are used in OpenStack Infra
>> environment for much more tasks than just running tests
> 
> If by "more tasks" you mean parallel testing, py.test also has a
> possibility to do that by pytest-xdist.

As Monthy mentioned, it’s not only about testing, it’s more about deeper 
integration with OpenStack Infra.


>> - py.test won’t be added to global-requirements so there always be a chance
>> of another dependency hell
> 
> As Igor Kalnitsky said, py.test doesn't have much requirements.
> https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
> It's only argparse, which already is in global requirements without
> any version pinned.

It’s not only about py.test, there is an up-to-date objective of sticking all 
requirements to global-requirements because we have big problems because of 
that every release.

> 
> Cheers,
> Michal
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] py.test vs testrepository

[Roman Prykhodchenko]

Disclaimer:
I didn’t want to fire up this war but it silently hit one of my patches so now 
I think it’s better to spread it to a wide audience.


When I was dealing with one of the regular dependency hell in Fuel Client I 
noticed, that stuff which is not in global requirements may make the mentioned 
hell hotter, even if those requirements are test requirements. After that 
discovery I started aligning all *requirements.txt to Kilo’s global 
requirements and trying to remove everything which it not there. A special 
dependency is of course py.test: replacing it is a very controversial thing 
which I’d like to discuss here.

Atm I have the following pros. and cons. regarding testrepository:

pros.:

1. It’s ”standard" in OpenStack so using it gives Fuel more karma and moves it 
more under big tent
2. It’s in global requirements, so it doesn’t cause dependency hell

cons.:

1. Debugging is really hard


I’d like to head your thoughts.


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] python-jobs now vote on Fuel Client

[Roman Prykhodchenko]

Good news folks!

Since python jobs worked well on a number of patches, their mode was switched 
to voting. They were also added to the gate pipeline.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Number of IP addresses in a public network

[Roman Prykhodchenko]

Hi folks!

Recently a problem that network check does not tell whether there’s enough IP 
addresses in a public network [1] was reported. That check is performed by 
CheckBeforeDeployment task, but there is two problems that happen because this 
verification is done that late:

 - A deployment fails, if there’s not enough addresses in specified ranges
 - If a user wants to get network configuration they will get an error

The solution for this problems seems to be easy and a straightforward patch [2] 
was proposed. However, there is a hidden problem which is that patch does not 
address which is that installed plugins may reserve VIPs for their needs. The 
issue is that they do it just before deployment and so it’s not possible to get 
those reservations when a user wants to check their network set up.

The important issue we have to address here is that network configuration 
generator will fail, if specified ranges don’t fit all VIPs. There were several 
proposals to fix that, I’d like to highlight two of them:

 a) Allow VIPs to not have an IP address assigned, if network config generator 
works for API output.
 That will prevent GET requests from failure, but since IP addresses for 
VIPs are required, generator will have to fail, if it generates a configuration 
for the orchestrator.
 b) Add a release note that users have to calculate IP addresses manually and 
put sane ranges in order to not shoot their own legs. Then it’s also possible 
to change network verification output to remind users to check the ranges 
before starting a deployment.

In my opinion we cannot follow (a) because it only masks a problem instead of 
providing a fix. Also it requires to change the API which is not a good thing 
to do after the SCF. If we choose (b), then we can work on a firm solution in 
8.0 and fix the problem for real.


P. S. We can still merge [2], because it checks, if IP ranges can at least fit 
the basic configuration. If you agree, I will update it soon.

[1] https://bugs.launchpad.net/fuel/+bug/1487996
[2] https://review.openstack.org/#/c/217267/



- romcheg





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Branching strategy vs feature freeze

[Roman Prykhodchenko]

Dmitry,

thank you for a well described plan.
May I please ask you for a little TL;DR excerpt of what’s going to be changed, 
because I’m affraid some folks may get lost or may not have enough time to 
analyze it deeply (I actually see that happening but I won’t do fingerpointing 
:) ).


- romcheg

 24 серп. 2015 о 20:29 Dmitry Borodaenko dborodae...@mirantis.com 
 написав(ла):
 
 We have several problems with Fuel branching strategy that have become
 enough of a bottleneck to consider re-thinking our whole release
 management process. In this email, I will describe the problems, propose
 a couple of alternative strategies, and try to analyze their relative
 merits and associated risks.
 
 I have my opinions and preferences, but I will try my best to
 objectively compare all available options. My goal is to improve
 efficiency of the existing team and make it significantly easier for new
 people to contribute to Fuel, even when their schedule and their agenda
 is not 100% aligned with those of Fuel core team and Mirantis OpenStack.
 
 It is essential for the new process to be acceptable for Fuel
 contributors, and is is just as essential to reach a consensus quickly:
 with Fuel 7.0 Hard Code Freeze less than two weeks away [0], we're
 already late with planning 8.0, and we absolutely must have the whole
 plan for 8.0 before Fuel 7.0 is released (September 24).
 
 [0] https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule
 
 I propose a time-bound rough consensus to make this decision: raise all
 concerns and risks before end of this week (Friday, August 28), propose
 and discuss ways to address the raised concerns, and make final decision
 before end of next week (Friday, September 4).
 
 Here's how Fuel versions, branches, and release milestones work now.
 
 Major Fuel version corresponds to an OpenStack release. For example,
 Fuel 7.0 is the first version to support Kilo. Minor version denotes a
 feature release. For example, Fuel 6.1 is still based on Juno but
 contains new features relative to Fuel 6.0. Tiny versions (e.g. 5.1.1)
 and maintenance updates (e.g. 6.1-mu-1) include only bugfixes.
 
 Most Fuel development happens on the master branch. On Hard Code Freeze,
 a stable branch is created in all Fuel git repositories (e.g. stable/7.0
 will be created on September 3). After that, all changes targeted to
 that release series must be proposed, reviewed, and merged to master
 before they are proposed for any stable branches [1]. One release series
 and one stable branch is created per minor Fuel version (e.g. stable/6.1
 for 6.1.x).
 
 [1] 
 https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series
 
 Fuel release cycle starts from Hard Code freeze of the previous release:
 
 - Hard Code Freeze: stable branch created, master branch is open for all
 changes
 - Design Complete: all release features have specs merged in fuel-specs
 - Feature Freeze: feature changes no longer accepted in master branch
 - Soft Code Freeze: medium and lower priority bugfixes no longer
 accepted in master branch
 
 Looks similar to the way OpenStack branch model works [2], but there's
 an important difference.
 
 [2] https://wiki.openstack.org/wiki/Branch_Model
 
 In OpenStack, master branch is closed for feature commits for 2 weeks
 per release [3], or 1/13th of the whole 26-week release cycle.
 
 [3] https://wiki.openstack.org/wiki/Liberty_Release_Schedule
 
 In Fuel, master branch remains closed for almost half of the release
 cycle:
 
 5.0 -- 32 of 81 days
 5.1 -- 63 of 119 days
 6.0 -- 35 of 93 days
 6.1 -- 85 of 180 days
 7.0 -- 42 of 93 days (planned)
 
 This renders it unusable as an integration branch: if you are bound by a
 schedule that is not aligned with Fuel release milestones and have more
 changes than a single commit which you could keep rebasing until Fuel
 master is open again, you're better off merging your changes into your
 own integration branch (i.e. fork Fuel).
 
 The same problem is even worse if you're working on the next OpenStack
 release. Even when Fuel master is open, it's developed and tested
 against latest stable release of OpenStack. For example, even though
 OpenStack developers started working on Liberty features in May,
 reflecting that work in Fuel master is blocked until September.
 
 There are 4 partially overlapping solutions to this problem:
 
 1) Future branch: create a future integration branch on FF, rebase it
 weekly onto master (or merge weekly from master to future), merge future
 to master after stable branch is created on HCF.
 
 2) Short FF: create stable branch 2 weeks after FF (same as OpenStack)
 instead of waiting for HCF.
 
 3) Short FF and internal fork: create stable branch 2 weeks after FF,
 create an internal fork of stable branch for Mirantis OpenStack.
 
 4) CI for external forks: package and document Fuel development
 infrastructure so that anyone who wants to fork Fuel can set up their
 own CI.
 
 In theory, we 

[openstack-dev] [Fuel] fuel-dev-tools package is not published on PyPi

[Roman Prykhodchenko]

Folks,

I can see fuel-dev-tools packaged registered on PyPi [1] but when I tried to 
install it, I got a message that pip could not find a version that satisfies 
the requirement.

These utils are extremely useful and really help to avoid much pain while 
testing something on a live environment or troubleshooting a problem. However, 
it sounds reasonable for me that one doesn’t have to clone a repo [2] in order 
to work on Fuel. Instead pip install the utils should do all the job.

We must publish this package to PyPi. In order to do that easier, I filed a 
patch [3] that adds release-to-pypi template to the appropriate project on 
Zuul. Please review it.


1. https://pypi.python.org/pypi/fuel-dev-tools/1.0.0 
https://pypi.python.org/pypi/fuel-dev-tools/1.0.0
2. https://github.com/stackforge/fuel-dev-tools 
https://github.com/stackforge/fuel-dev-tools
3. https://review.openstack.org/216174 https://review.openstack.org/216174

- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Great updates to tests and CI jobs

[Roman Prykhodchenko]

It looks like Sebastian’s concern was right and there indeed were not 4-5 
patches for Fuel Client. Therefore I will not switch python jobs to voting 
mode. Once there are some new patches, I will do that and notify you folks.

- romcheg


 20 серп. 2015 о 14:13 Sebastian Kalinowski skalinow...@mirantis.com 
 написав(ла):
 
 If there will be 4-5 patches, then I do not have anything against it. I'm 
 just skeptic that we will have so many ;)
 
 2015-08-20 14:05 GMT+02:00 Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me:
 I think, that if there are 4-5 patches that pass python jobs w/o any 
 problems, we can switch the jobs to voting. They are really simple with a 
 very little room for a failure so should we wait longer?
 
 
 19 серп. 2015 о 19:50 Sebastian Kalinowski skalinow...@mirantis.com 
 mailto:skalinow...@mirantis.com написав(ла):
 
 Indeed, great news!
 
 I would only suggest to wait a little bit more that a few days with switching
 to the voting mode since it looks like there will be not so many patches
 proposed to python-fuelclient as we are heading towards Hard Code Freeze.
 
 I hope that the next step will be to enable Python 3 pipepline for our 
 client so
 we could finally test all the code that uses six library for Python 2  3 
 compatibility.
 
 Best,
 Sebastian
 
 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com 
 mailto:bpavlo...@mirantis.com:
 Roman,
 
 well done! ;)
 
 Best regards,
 Boris Pavlovic
 
 On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Today I’m proud to announce that since this moment python-fuelclient has 
 it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me 
 making Fuel Client compatible with the upstream CI.
 Besides sharing great news I think it’s necessary to share changes we had to 
 do, in order to accomplish this result.
 
 First of all tests were reorganized: now functional and unit tests have 
 their own separate folders inside the fuelclient/tests directory. That 
 allowed us to distinguish them from both the CI and a developer’s point of 
 view, so there will be no mess we used to have.
 
 The other change we’ve made is deleting run_tests.sh*. It is possible to run 
 and manage all the tests via tox which is a de-facto standard in OpenStack 
 ecosystem. That also means anyone who is familiar with any of OpenStack 
 projects will be able to orchestrate tests without a need to learn anything. 
 Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
 environments. py26 and py27 only run unit tests and cover also involves 
 calculating coverage. functional fires up Nailgun and launches functional 
 tests. cleanup stops Nailgun, deletes its DB and any files left after 
 functional tests and what you will definitely like — cleans up all *.pyc 
 files. By default tox executes environments in the following order: 
 py26-py27-pep8-functional-cleanup.
 
 Minimal tox was updated to 2.1 which guarantees no external environment 
 variable is passed to tests.
 
 The jobs on OpenStack CI are set to be non-voting for a few days to give it 
 a better try. On the next week we will switch them to voting. At the same 
 time we will remove unit tests from FuelCI to not waste extra time.
 
 
 * Technically it is kept in place to keep compatibility with FuelCI but it 
 only invokes tox from inside. It will be removed later, when it’s time to 
 switch off unit tests on FuelCI.
 
 
 - romcheg
 
 __
 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 
 mailto: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] [Fuel] Changes to the blueprint specification template

[Roman Prykhodchenko]

Folks,

as you may remember, we were about to merge some changes to the blueprint spec 
template to make our specifications in Fuel more specific regarding different 
components and subsystems.
That time we decided to move the changes to 8.0, so new specs in 8.0 will have 
to follow the new template. I restored the patch with the changes and now it’s 
ready for reviews https://review.openstack.org/#/c/193070/ 
https://review.openstack.org/#/c/193070/


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Great updates to tests and CI jobs

[Roman Prykhodchenko]

I think, that if there are 4-5 patches that pass python jobs w/o any problems, 
we can switch the jobs to voting. They are really simple with a very little 
room for a failure so should we wait longer?


 19 серп. 2015 о 19:50 Sebastian Kalinowski skalinow...@mirantis.com 
 написав(ла):
 
 Indeed, great news!
 
 I would only suggest to wait a little bit more that a few days with switching
 to the voting mode since it looks like there will be not so many patches
 proposed to python-fuelclient as we are heading towards Hard Code Freeze.
 
 I hope that the next step will be to enable Python 3 pipepline for our client 
 so
 we could finally test all the code that uses six library for Python 2  3 
 compatibility.
 
 Best,
 Sebastian
 
 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com 
 mailto:bpavlo...@mirantis.com:
 Roman,
 
 well done! ;)
 
 Best regards,
 Boris Pavlovic
 
 On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Today I’m proud to announce that since this moment python-fuelclient has it’s 
 own python-jobs in OpenStack CI. Thanks to all of you who helped me making 
 Fuel Client compatible with the upstream CI.
 Besides sharing great news I think it’s necessary to share changes we had to 
 do, in order to accomplish this result.
 
 First of all tests were reorganized: now functional and unit tests have their 
 own separate folders inside the fuelclient/tests directory. That allowed us 
 to distinguish them from both the CI and a developer’s point of view, so 
 there will be no mess we used to have.
 
 The other change we’ve made is deleting run_tests.sh*. It is possible to run 
 and manage all the tests via tox which is a de-facto standard in OpenStack 
 ecosystem. That also means anyone who is familiar with any of OpenStack 
 projects will be able to orchestrate tests without a need to learn anything. 
 Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
 environments. py26 and py27 only run unit tests and cover also involves 
 calculating coverage. functional fires up Nailgun and launches functional 
 tests. cleanup stops Nailgun, deletes its DB and any files left after 
 functional tests and what you will definitely like — cleans up all *.pyc 
 files. By default tox executes environments in the following order: 
 py26-py27-pep8-functional-cleanup.
 
 Minimal tox was updated to 2.1 which guarantees no external environment 
 variable is passed to tests.
 
 The jobs on OpenStack CI are set to be non-voting for a few days to give it a 
 better try. On the next week we will switch them to voting. At the same time 
 we will remove unit tests from FuelCI to not waste extra time.
 
 
 * Technically it is kept in place to keep compatibility with FuelCI but it 
 only invokes tox from inside. It will be removed later, when it’s time to 
 switch off unit tests on FuelCI.
 
 
 - romcheg
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Great updates to tests and CI jobs

[Roman Prykhodchenko]

Mike,

there were indeed several issues with the new Jenkins script. It seems we fixed 
them.


- Roman
 20 серп. 2015 о 02:00 Mike Scherbakov mscherba...@mirantis.com написав(ла):
 
 Sounds great. Thank you Roman!
 I've heard complains about tests not passing for [1]. Now it's passed, so I 
 hope that issues are resolved.
 
 [1] https://review.openstack.org/#/c/212906/ 
 https://review.openstack.org/#/c/212906/
 On Wed, Aug 19, 2015 at 10:51 AM Sebastian Kalinowski 
 skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote:
 Indeed, great news!
 
 I would only suggest to wait a little bit more that a few days with switching
 to the voting mode since it looks like there will be not so many patches
 proposed to python-fuelclient as we are heading towards Hard Code Freeze.
 
 I hope that the next step will be to enable Python 3 pipepline for our client 
 so
 we could finally test all the code that uses six library for Python 2  3 
 compatibility.
 
 Best,
 Sebastian
 
 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com 
 mailto:bpavlo...@mirantis.com:
 Roman,
 
 well done! ;)
 
 Best regards,
 Boris Pavlovic
 
 On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Today I’m proud to announce that since this moment python-fuelclient has it’s 
 own python-jobs in OpenStack CI. Thanks to all of you who helped me making 
 Fuel Client compatible with the upstream CI.
 Besides sharing great news I think it’s necessary to share changes we had to 
 do, in order to accomplish this result.
 
 First of all tests were reorganized: now functional and unit tests have their 
 own separate folders inside the fuelclient/tests directory. That allowed us 
 to distinguish them from both the CI and a developer’s point of view, so 
 there will be no mess we used to have.
 
 The other change we’ve made is deleting run_tests.sh*. It is possible to run 
 and manage all the tests via tox which is a de-facto standard in OpenStack 
 ecosystem. That also means anyone who is familiar with any of OpenStack 
 projects will be able to orchestrate tests without a need to learn anything. 
 Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
 environments. py26 and py27 only run unit tests and cover also involves 
 calculating coverage. functional fires up Nailgun and launches functional 
 tests. cleanup stops Nailgun, deletes its DB and any files left after 
 functional tests and what you will definitely like — cleans up all *.pyc 
 files. By default tox executes environments in the following order: 
 py26-py27-pep8-functional-cleanup.
 
 Minimal tox was updated to 2.1 which guarantees no external environment 
 variable is passed to tests.
 
 The jobs on OpenStack CI are set to be non-voting for a few days to give it a 
 better try. On the next week we will switch them to voting. At the same time 
 we will remove unit tests from FuelCI to not waste extra time.
 
 
 * Technically it is kept in place to keep compatibility with FuelCI but it 
 only invokes tox from inside. It will be removed later, when it’s time to 
 switch off unit tests on FuelCI.
 
 
 - romcheg
 
 __
 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
 --
 Mike Scherbakov
 #mihgen
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

[openstack-dev] [Fuel] Great updates to tests and CI jobs

[Roman Prykhodchenko]

Hi folks!

Today I’m proud to announce that since this moment python-fuelclient has it’s 
own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel 
Client compatible with the upstream CI.
Besides sharing great news I think it’s necessary to share changes we had to 
do, in order to accomplish this result.

First of all tests were reorganized: now functional and unit tests have their 
own separate folders inside the fuelclient/tests directory. That allowed us to 
distinguish them from both the CI and a developer’s point of view, so there 
will be no mess we used to have.

The other change we’ve made is deleting run_tests.sh*. It is possible to run 
and manage all the tests via tox which is a de-facto standard in OpenStack 
ecosystem. That also means anyone who is familiar with any of OpenStack 
projects will be able to orchestrate tests without a need to learn anything. 
Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
environments. py26 and py27 only run unit tests and cover also involves 
calculating coverage. functional fires up Nailgun and launches functional 
tests. cleanup stops Nailgun, deletes its DB and any files left after 
functional tests and what you will definitely like — cleans up all *.pyc files. 
By default tox executes environments in the following order: 
py26-py27-pep8-functional-cleanup.

Minimal tox was updated to 2.1 which guarantees no external environment 
variable is passed to tests.

The jobs on OpenStack CI are set to be non-voting for a few days to give it a 
better try. On the next week we will switch them to voting. At the same time we 
will remove unit tests from FuelCI to not waste extra time.


* Technically it is kept in place to keep compatibility with FuelCI but it only 
invokes tox from inside. It will be removed later, when it’s time to switch off 
unit tests on FuelCI.


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Get rid of run_test.sh in Fuel Client

[Roman Prykhodchenko]

Hi Fuelers!


I was working on enabling Python tests in Fuel Client to run on OpenStack CI 
and I figured out that we actually have a piece of legacy code which can be 
removed now. That piece is run_tests.sh file. For those who’s not aware, that 
script allows to run different tests under different environments. I don’t know 
how it was a thousand years ago when I was not involved to Fuel project, but 
the situation at this particular moment looks like that:

- Tests are actually orchestrated by tox
- The biggest job of run_tests.sh is to translate its options to tox’es options
- The only useful job of run_tests.sh is to start Nailgun correctly for 
functional tests

As you can see the profit of that script is tiny. However, the problems it 
brings are pretty much big and looks as follows:

- It is unstable — tiniest changes to tests require big changes to the script
- The CLI it provides is confusing
- Working on that file looks like doing the same job that is already done in tox
- Among the active Fuel Client’s community there are only a few guys who are 
proficient in bash enough, to support that script effectively


My proposal is to extract the code responsible for starting Nailgun into to a 
small utility script and let tox do the rest by removing run_test.sh 
completely. That will bring us the following advantages:

- No need to support a complex bash script.
- Closer to being able to run functional tests on DSVM gates.
- Test CLI will be more compatible with other OpenStack projects.

I foresee a few questions and the answers for them follow:

Q: How is verify-job from FuelCI going to run tests without that file?
A: Fuel Client has its own job on FuelCI, so it will be just necessary to 
change the invocation there.

Q: But run_test.sh is in all Fuel projects, shouldn’t we keep them all similar.
A: Why does it have to be similar? This kind of difference is minor and it 
brings more advantages, than just having the same file. In fact the set of 
options in run_tests.sh is already different from run_tests.sh in fuel-web.

Q: Why should we look ad other OpenStack projects?
A: Fuel is living in the OpenStack ecosystem so being compatible with it is a 
big advantage. It’s also a must for going big tent.


- romcheg






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Release of python-fuelclient today

[Roman Prykhodchenko]

Привет, нет, обычный how to contribute.

 31 лип. 2015 о 15:01 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 Folks,
 
 today I’m going to make a new public release of Fuel Client.
 If you badly need to merge something before that or have any objections, 
 please let me know before 17:00 CEST (UTC+2).
 
 
 - romcheg
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Release of python-fuelclient today

[Roman Prykhodchenko]

Sorry, folks, I pressed a wrong button for replying.

 31 лип. 2015 о 15:56 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 Привет, нет, обычный how to contribute.
 
 31 лип. 2015 о 15:01 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 Folks,
 
 today I’m going to make a new public release of Fuel Client.
 If you badly need to merge something before that or have any objections, 
 please let me know before 17:00 CEST (UTC+2).
 
 
 - romcheg
 
 __
 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
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Release of python-fuelclient today

[Roman Prykhodchenko]

Folks,

today I’m going to make a new public release of Fuel Client.
If you badly need to merge something before that or have any objections, please 
let me know before 17:00 CEST (UTC+2).


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [FFE] FF Exception request for Custom node attributes feature

[Roman Prykhodchenko]

+1 to merging the CLI part, if all our comments there are filed as High 
priority bugs and then fixed ASAP

- romcheg


 24 лип. 2015 о 07:58 Mike Scherbakov mscherba...@mirantis.com написав(ла):
 
 Colleagues,
 it sounds like we need to complete what was requested by Julia here (and it 
 would take about a day as I understand), plus Andrey's request (which seems 
 to be very important for partner story and flexibility), plus additional 
 pieces which turned into bugs [1].
 
 I'd like to hear opinion from fuel-web cores on this. I don't think we can do 
 all of what is requested.
 
 [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli 
 https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli
 On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com 
 mailto:ada...@mirantis.com wrote:
 Hi, folks.
 
 I understand it may be not a good time but I want to make a proposal 
 regarding this feature.
 The feature may be extremely useful for plugin developers if these labels 
 would be serialized into astute.yaml. They may be used by plugin tasks to do 
 node-specific modifications. Let me provide some examples:
 * For Xen integration we need to provide unique Xen Server credentials for 
 each Compute node. But with current architecture we don't have any 
 customizable per-node parameters.
 * It may be possible to use special labels to override global values (i.e. 
 libvirt_type, thus implementing BP 
 https://blueprints.launchpad.net/fuel/+spec/auto-virt-type 
 https://blueprints.launchpad.net/fuel/+spec/auto-virt-type).
 * Another case may be the fencing. A user may put IPMI credentials into 
 labels.
 And there are more cases like that.
 
 Despite the original spec doesn't have this idea I propose to implement that. 
 Moreover, I've already did it. Here are my two commits with a spec update [0] 
 and an implementation[1]. They are pretty simple.
 
 [0] https://review.openstack.org/#/c/205105/ 
 https://review.openstack.org/#/c/205105/
 [1] https://review.openstack.org/#/c/205113/ 
 https://review.openstack.org/#/c/205113/
 
 
 Please grant FFE to this feature with my additions till tomorrow evening.
 
 On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com 
 mailto:jkirnos...@mirantis.com wrote:
 
 Mike, thanks for the important points you've provided.
 
 My main argument for this FFE is the following: we've already got a 
 confirmation from SME for this patch. But also got some not critical comments 
 at the last minute before we were going to merge it and have to handle it 
 now. But it looks that these comments don't block the feature and we can fix 
 it after merging a base patch.
 
 We tested the patch and it matches an acceptance criteria for the feature 
 with some not critical known issues that already converted to launchpad 
 tickets.
 
 I believe we can land it in master tomorrow with +1 from SME.
 
 BTW, I see no intersection in reviewers with this patch 
 https://review.openstack.org/#/c/204321/ 
 https://review.openstack.org/#/c/204321/.
 
 Thank you,
 Julia
 
 
 On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com 
 mailto:mscherba...@mirantis.com wrote:
 -1
 My concerns are the following:
 This feature is of a High priority, not Essential [1]
 We already had to give exception for flexible networking CLI part [2], as it 
 is essential one. So basically that means we have a conflict of focus for 
 SMEs in the area.
 Just by working on this, we don't spend time on bugs. Which increases risk of 
 delivering on time with expected level of quality
 +390, -35 LOC also scare me a little bit, it's not a tiny change.
 
 One of the possible workarounds can be, if we deliver this patch after HCF, 
 and have an updated package of client. If someone want it in experimental 
 mode, then the one could update client package and have this functionality.
 
 If you convince me though that it can be finished by end of the week with 
 only code reviews from SMEs (and only after flexible networking part is 
 done), only after it I can change my mind.
 
 [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes 
 https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes
 [2] https://review.openstack.org/#/c/204321/ 
 https://review.openstack.org/#/c/204321/
 
 On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski 
 skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote:
 +1 for this FFE as it's important to have this functionality covered in CLI
 
 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com 
 mailto:ikalnit...@mirantis.com:
 Hi Julia,
 
 I'm ok with FF exception for CLI part. I don't think it can somehow
 decrease product quality, so as a core I'll help to land it.
 
 Thanks,
 Igor
 
 On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich
 jkirnos...@mirantis.com mailto:jkirnos...@mirantis.com wrote:
  Team,
 
  I would like to request an exception from the Feature Freeze for CLI changes
  

[openstack-dev] [Fuel] python-fuelclient-6.1.2

[Roman Prykhodchenko]

Folks,

I’m glad to announse that verison 6.1.2 of Fuel Client was released. The team 
fixed a few important issues in order to make it possible to interact with Fuel 
6.1 using the official client.

CHANGELOG
===

6.1.2
---

* Change version to 6.1.2
* Update link to developers' manual
* Fix typo and output of fuel env --help
* Pin oslo.i18n for keystoneclient
* Return realistic data from mocked library
* Reconfigure the wheel
* Fix manual assignment of nodes to node groups
* Block deploy/provision action for unassigned nodes
* Bump version to 7.0
* Fix test for creating env with ha mode
* Change default network mode for env creation to neutron

As usual, you can install or upgrade python-fuelclient package from PyPi: 
https://pypi.python.org/pypi/python-fuelclient


-- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Improvement of the blueprint specs template

[Roman Prykhodchenko]

Guys,

I’d like to ask all Fuel component leads to take a look at the proposed changes 
and check whether all important sections were added.


- romcheg
 18 черв. 2015 о 13:14 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 I realize, that discussing this topic in the email is hard. I filed a review 
 request with some changes to the template and invite you folks to take a look 
 at that: https://review.openstack.org/193070 
 https://review.openstack.org/193070
 
 
 16 черв. 2015 о 17:08 Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me написав(ла):
 
 Hi folks!
 
 I was reviewing one of specs for Fuel 7.0 and realized the information there 
 is messed up and it’s pretty hard to put it all together. The reason for 
 that is basically that Fuel is a multicomponent project but the template 
 does not consider that — there is a Proposed change section which is used to 
 define all the changes in the entire project; then there is the API and Data 
 impact sections that are specific to only specific components but still have 
 to be filled in.
 
 Since most of new features consider changes to several components I propose 
 to stick to the following structure. It eliminates the need to create 
 several specs to describe one feature and allows to organize everything in 
 one document without messing it up:
 
 -- Title
 -- Excerpt (short version of the Problem description, proposed solution and 
 final results)
 -- Problem description
 -- Proposed changes
 -- Web UI
 -- Nailgun
 -- General
 -- REST API
 -- Data model
 -- Astute
 -- General
 -- RPC protocol
 -- Fuel Client
 -- Plugins
 -- Impact
 -- End-user
 -- QA
 -- Developer
 -- Infrastructure (operations)
 -- Upgrade
 -- Performance
 -- Implementation
 -- Assignee
 -- Work items
 -- Web UI
 -- Nailgun
 -- Astute
 -- Fuel Client
 -- Plugins
 -- Documentation
 -- References
 
 
 - romcheg
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto: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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Improvement of the blueprint specs template

[Roman Prykhodchenko]

I realize, that discussing this topic in the email is hard. I filed a review 
request with some changes to the template and invite you folks to take a look 
at that: https://review.openstack.org/193070 
https://review.openstack.org/193070


 16 черв. 2015 о 17:08 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 Hi folks!
 
 I was reviewing one of specs for Fuel 7.0 and realized the information there 
 is messed up and it’s pretty hard to put it all together. The reason for that 
 is basically that Fuel is a multicomponent project but the template does not 
 consider that — there is a Proposed change section which is used to define 
 all the changes in the entire project; then there is the API and Data impact 
 sections that are specific to only specific components but still have to be 
 filled in.
 
 Since most of new features consider changes to several components I propose 
 to stick to the following structure. It eliminates the need to create several 
 specs to describe one feature and allows to organize everything in one 
 document without messing it up:
 
 -- Title
 -- Excerpt (short version of the Problem description, proposed solution and 
 final results)
 -- Problem description
 -- Proposed changes
 -- Web UI
 -- Nailgun
 -- General
 -- REST API
 -- Data model
 -- Astute
 -- General
 -- RPC protocol
 -- Fuel Client
 -- Plugins
 -- Impact
 -- End-user
 -- QA
 -- Developer
 -- Infrastructure (operations)
 -- Upgrade
 -- Performance
 -- Implementation
 -- Assignee
 -- Work items
 -- Web UI
 -- Nailgun
 -- Astute
 -- Fuel Client
 -- Plugins
 -- Documentation
 -- References
 
 
 - romcheg
 
 
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Improvement of the blueprint specs template

[Roman Prykhodchenko]

Hi folks!

I was reviewing one of specs for Fuel 7.0 and realized the information there is 
messed up and it’s pretty hard to put it all together. The reason for that is 
basically that Fuel is a multicomponent project but the template does not 
consider that — there is a Proposed change section which is used to define all 
the changes in the entire project; then there is the API and Data impact 
sections that are specific to only specific components but still have to be 
filled in.

Since most of new features consider changes to several components I propose to 
stick to the following structure. It eliminates the need to create several 
specs to describe one feature and allows to organize everything in one document 
without messing it up:

-- Title
-- Excerpt (short version of the Problem description, proposed solution and 
final results)
-- Problem description
-- Proposed changes
-- Web UI
-- Nailgun
-- General
-- REST API
-- Data model
-- Astute
-- General
-- RPC protocol
-- Fuel Client
-- Plugins
-- Impact
-- End-user
-- QA
-- Developer
-- Infrastructure (operations)
-- Upgrade
-- Performance
-- Implementation
-- Assignee
-- Work items
-- Web UI
-- Nailgun
-- Astute
-- Fuel Client
-- Plugins
-- Documentation
-- References


- romcheg





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Oleg,

Thanks for the feedback. I have the following as a response:

1. This spec is just an excerpt for scoping in the proposed improvement to the 
7.0 release plan. If it get’s scope the full specification will go through a 
standard review process so it will be possible to discuss names along with the 
rest of details then.

2. It’s already noticed in the spec the status is is generated using an 
aggregate query like you described so I don’t propose to store it. Storing that 
data will require sophisticated algorithms to work with it and also will lead 
to more locks or race conditions in the database. So yes, it’s going to be a 
method.


- romcheg


 27 трав. 2015 о 08:19 Oleg Gelbukh ogelb...@mirantis.com написав(ла):
 
 Roman,
 
 This looks like a great solution to me, and I like your proposal very much. 
 The status of cluster derived directly from statuses of nodes is exactly what 
 I was thinking about.
 
 I have to notes to the proposal, and I can copy them to etherpad if you think 
 they deserve it:
 
 1) status name 'operational' seem a bit unclear to me, as it sounds more like 
 something Monitoring should report: it implies that the actual OpenStack 
 environment is operational, which might or might not be a case, and Fuel has 
 no way to tell. I would really prefer if that status name was 'Deployed' or 
 something along those lines.
 
 2) I'm not sure if we need to keep the complex status of the cluster 
 explicitly in 'cluster' table in the format you suggest. This information can 
 be taken directly from 'nodes' table in Nailgun DB. For example, getting it 
 in the second form you propose is as simple as:
 
 nailgun= SELECT status,count(status) FROM nodes GROUP BY status;
 discover|1
 ready|5
 
 What do you think about making it a method rather then an element of data 
 model? Or that's exactly the complexity you want to get rid of?
 
 --
 Best regards,
 Oleg Gelbukh
 
 
 On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Oleg,
 
 Aleksander also proposed a nice proposed a nice solution [1] which is to have 
 a complex status for cluster. That, however, looks like a BP so I’ve created 
 an excerpt [2] for it and we will try to discuss it scope it for 7.0, if 
 there is a consensus.
 
 
 References:
 
 1. http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html 
 http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html
 2. https://etherpad.openstack.org/p/fuel-cluster-complex-status 
 https://etherpad.openstack.org/p/fuel-cluster-complex-status
 
 
 - romcheg
 
 22 трав. 2015 о 22:32 Oleg Gelbukh ogelb...@mirantis.com 
 mailto:ogelb...@mirantis.com написав(ла):
 
 Roman,
 
 I'm totally for fixing Nailgun. However, the status of environment is not 
 simply function of statuses of nodes in it. Ideally, it should depend on 
 whether appropriate number of nodes of certain roles are in 'ready' status. 
 For the meantime, it would be enough if environment was set to 'operational' 
 when all nodes in it become 'ready', no matter how they were deployed (i.e. 
 via Web UI or CLI).
 
 --
 Best regards,
 Oleg Gelbukh
 
 On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Recently I encountered an issue [1] that the Deploy Changes button in the 
 web ui is still active when a provisioning of single node is started using 
 the command line client.
 The background for that issue is that the provisioning task does not seem to 
 update the cluster status correctly and Nailgun’s API returns it as NEW even 
 while some of the node are been provisioned.
 
 The reason for raising this thread in the mailing list is that provisioning 
 a node is a feature for developers and basically end-users should not do 
 that. What is the best solution for that: fix Nailgun to set the correct 
 status, or make this provisioning feature available only for developers?
 
 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086 
 https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
 
 
 - romcheg
 
 
 __
 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 
 mailto: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

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Aleksey,
thank you for your feedback.

The first thing I’d like to highlight is that both web ui and the cli use the 
same Nailgun API to perform the same actions so basically we must not treat the 
command line client any differently.

The idea of having a complex status for environment actually seems to be pretty 
good one. However, that requires a BP so I’ve created an excerpt [1] which I’d 
like to share.
If this feature is scoped, it will get life of many folks easier since it will 
allow to discard some sophisticated algorithms.


- romcheg

1. https://etherpad.openstack.org/p/fuel-cluster-complex-status 
https://etherpad.openstack.org/p/fuel-cluster-complex-status

 25 трав. 2015 о 10:39 Aleksey Kasatkin akasat...@mirantis.com написав(ла):
 
 AFAIC, there are several problems (in API) here:
 1. We cannot stop/reset particular nodes.
 2. Cluster status doesn't address changes which were done via CLI.
 3. Cluster status in its current form is not enough to manage cluster (i.e. 
 to determine actions what can be applied to cluster at the moment). It 
 doesn't reflect the fact that some nodes can be in 'provisioned' state, some 
 are in 'provisioning', 'deploying', 'ready' statuses.
 
 First two seem clear enough. We could add ability to stop/reset particular 
 nodes and reflect CLI-driven changes in the cluster status.
 To address the last point my proposal was (bug/1449086/comments/7 
 https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086/comments/7) to break 
 status into several binary states, i.e. binaries: 'new', 'deployment', 
 'ready', etc., each of which is set to true when cluster has at least one 
 node in corresponding status (I united 'provisioning', 'provisioned' and 
 'deploying' into one as it is done now).
 
 Now it looks more reasonable to me to keep the original status as is and add 
 bitwise one mentioned above (to address states of different nodes) because 
 'error' state is determinative for cluster (when cluster is in 'error' state 
 it is no matter that some nodes are in 'ready' state).
 So,
 cluster is in 'new' state when all nodes are in 'discover' state,
 it is in 'operational' state when all nodes are in 'ready' state,
 cluster is in 'deployment' state when not all of its nodes are in 'discover' 
 or 'ready' state but there are no nodes in 'error' and 'removing' states.
 New bitwise status is actual in 'deployment' state of cluster. It gives to 
 UI/CLI sufficient data to determine what actions can be applied to cluster at 
 the moment.
 
 I've combined some of the states combinations into the table:
 'new' flag
 
 'deployment' flag
 
 'ready' flag
 
 description, actions allowed
 false
 
 false
 
 false
 
 There are no nodes in cluster or all nodes are in 'error'/'removing' state. 
 Cluster is in 'new'/'error'/'remove' state here so we don't care about these 
 flags.
 
 false
 
 true
 
 false
 
 All nodes are under provisioning/deployment. Deployment can be stopped.
 
 true
 
 true
 
 false
 
 Part of nodes is in 'discover' state, remaining part is under 
 provisioning/deployment. Deployment can be started for the first part 
 or/and stopped for the second part of nodes.
 
 true
 
 false
 
 true
 
 Part of nodes is in 'discover' state, remaining part is in 'ready' state. 
 Deployment can be started for the first part and second part can be reset.
 
 true
 
 true
 
 true
 
 We have some nodes in every of the states: 'discover', 
 provisioning/deployment, 'ready'. So, we can allow different actions for 
 nodes in different states.
 
 false
 
 true
 
 true
 
 Part of nodes is under provisioning/deployment, remaining part is in 'ready' 
 state. Deployment can be stopped for the first part and second part can be 
 reset.
 
 I didn't show another 2 combinations here as they aren't related to 
 'deployment' state of cluster (as well as the first one in the table).
 
 Also, we should be careful with the order of nodes deployment/reset. I'm not 
 sure whether it is written in our docs that cluster may be non-functional if 
 user tries to deploy nodes in the wrong order (e.g. computes first). We could 
 show some warnings about that. Same applies to selective reset if we will 
 implement it.
 
 
 
 Aleksey Kasatkin
 
 
 On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Recently I encountered an issue [1] that the Deploy Changes button in the web 
 ui is still active when a provisioning of single node is started using the 
 command line client.
 The background for that issue is that the provisioning task does not seem to 
 update the cluster status correctly and Nailgun’s API returns it as NEW even 
 while some of the node are been provisioned.
 
 The reason for raising this thread in the mailing list is that provisioning a 
 node is a feature for developers and basically end-users should not do that. 
 What is the best solution for that: fix Nailgun to set the correct status, or 
 make

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Oleg,

Aleksander also proposed a nice proposed a nice solution [1] which is to have a 
complex status for cluster. That, however, looks like a BP so I’ve created an 
excerpt [2] for it and we will try to discuss it scope it for 7.0, if there is 
a consensus.


References:

1. http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html 
http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html
2. https://etherpad.openstack.org/p/fuel-cluster-complex-status 
https://etherpad.openstack.org/p/fuel-cluster-complex-status


- romcheg

 22 трав. 2015 о 22:32 Oleg Gelbukh ogelb...@mirantis.com написав(ла):
 
 Roman,
 
 I'm totally for fixing Nailgun. However, the status of environment is not 
 simply function of statuses of nodes in it. Ideally, it should depend on 
 whether appropriate number of nodes of certain roles are in 'ready' status. 
 For the meantime, it would be enough if environment was set to 'operational' 
 when all nodes in it become 'ready', no matter how they were deployed (i.e. 
 via Web UI or CLI).
 
 --
 Best regards,
 Oleg Gelbukh
 
 On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 Recently I encountered an issue [1] that the Deploy Changes button in the web 
 ui is still active when a provisioning of single node is started using the 
 command line client.
 The background for that issue is that the provisioning task does not seem to 
 update the cluster status correctly and Nailgun’s API returns it as NEW even 
 while some of the node are been provisioned.
 
 The reason for raising this thread in the mailing list is that provisioning a 
 node is a feature for developers and basically end-users should not do that. 
 What is the best solution for that: fix Nailgun to set the correct status, or 
 make this provisioning feature available only for developers?
 
 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086 
 https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
 
 
 - romcheg
 
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] python-fuelclient 6.1.0 is released

[Roman Prykhodchenko]

Oleg,

The backend part of the client was not changed dramatically due to requirements 
for backwards compatibility issues.
ATM we do have plans to support multiple versions of the Fuel API but the work 
is only being scoped now. The major technical issue is that Nailgun does not 
provide any versioning for it’s API so on the client side it’s only possible to 
support multiple versions of Fuel API on the very basic level when a version of 
the API is directly mapped to the version of Fuel.

I am not sure we will be able to support older versions of the API in the new 
Fuel Client due to lack of time. However, the structure of the client will 
allow to add that support in a pretty easy way.


- romcheg



 19 трав. 2015 о 16:01 Oleg Gelbukh ogelb...@mirantis.com написав(ла):
 
 Roman,
 
 This is awesome news! Thank you for this huge improvement for developers who 
 consume Fuel API.
 
 Could you please elaborate on backwards compatibility between the new client 
 and older versions of Fuel API? For example, is it possible to use the new 
 client to work with Fuel 4.x? 5.x?
 
 --
 Best regards,
 Oleg Gelbukh
 
 On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me wrote:
 Hi folks!
 
 I’m glad to announce that the first independent release of Fuel Client was 
 published to PyPi: https://pypi.python.org/pypi/python-fuelclient 
 https://pypi.python.org/pypi/python-fuelclient
 You can either download it from the web page or install with pip install 
 python-fuelclient.
 
 What’s new:
 
  - Fuel client is now able to run most of it’s features remotely from Fuel’s 
 master node.
  - Old CLI was deprecated, new fuel2 utility is a preview of the new Fuel 
 client which will be available in the next major release
  - Versioning scheme of the Fuel Client is not tightly bound to Fuel’s 
 version scheme anymore.
  - Other improvements and bug-fixes
 
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Hi folks!

Recently I encountered an issue [1] that the Deploy Changes button in the web 
ui is still active when a provisioning of single node is started using the 
command line client.
The background for that issue is that the provisioning task does not seem to 
update the cluster status correctly and Nailgun’s API returns it as NEW even 
while some of the node are been provisioned.

The reason for raising this thread in the mailing list is that provisioning a 
node is a feature for developers and basically end-users should not do that. 
What is the best solution for that: fix Nailgun to set the correct status, or 
make this provisioning feature available only for developers?

1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Hi folks!

Recently I encountered an issue [1] that the Deploy Changes button in the web 
ui is still active when a provisioning of single node is started using the 
command line client.
The background for that issue is that the provisioning task does not seem to 
update the cluster status correctly and Nailgun’s API returns it as NEW even 
while some of the node are been provisioned.

The reason for raising this thread in the mailing list is that provisioning a 
node is a feature for developers and basically end-users should not do that. 
What is the best solution for that: fix Nailgun to set the correct status, or 
make this provisioning feature available only for developers?

1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] python-fuelclient 6.1.0 is released

[Roman Prykhodchenko]

Hi folks!

I’m glad to announce that the first independent release of Fuel Client was 
published to PyPi: https://pypi.python.org/pypi/python-fuelclient 
https://pypi.python.org/pypi/python-fuelclient
You can either download it from the web page or install with pip install 
python-fuelclient.

What’s new:

 - Fuel client is now able to run most of it’s features remotely from Fuel’s 
master node.
 - Old CLI was deprecated, new fuel2 utility is a preview of the new Fuel 
client which will be available in the next major release
 - Versioning scheme of the Fuel Client is not tightly bound to Fuel’s version 
scheme anymore.
 - Other improvements and bug-fixes



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Transaction scheme

[Roman Prykhodchenko]

Hi folks!

Recently I faced a pretty sad fact that in Nailgun there’s no common approach 
to manage transactions. There are commits and flushes in random places of the 
code and it used to work somehow just because it was all synchronous.

However, after just a few of the subcomponents have been moved to different 
processes, it all started producing races and deadlocks which are really hard 
to resolve because there is absolutely no way to predict how a specific 
transaction is managed but by analyzing the source code. That is rather an 
ineffective and error-prone approach that has to be fixed before it became 
uncontrollable.

Let’s arrange a discussions to design a document which will describe where and 
how transactions are managed and refactor Nailgun according to it in 7.0. 
Otherwise results may be sad.


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] PEP8 issues in Fuel-Web repo

[Roman Prykhodchenko]

This is also relevant for python-fuelclient.

 6 квіт. 2015 о 12:27 Nikolay Markov nmar...@mirantis.com написав(ла):
 
 Hello everyone,
 
 I know this is really low priority and so on, but here is this bug about 
 moving to the newest version of hacking package: 
 https://bugs.launchpad.net/fuel/+bug/1410810 
 https://bugs.launchpad.net/fuel/+bug/1410810 . And here is the log after 
 all pep8 linters and checks: 
 https://fuel-jenkins.mirantis.com/job/verify-fuel-web/7063/consoleFull 
 https://fuel-jenkins.mirantis.com/job/verify-fuel-web/7063/consoleFull
 
 Let's keep up with the modern guidelines and fix styling in our code 
 according to new requirements.
 
 --
 Best regards,
 Nick Markov
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Let's stick to OpenStack global requirements

[Roman Prykhodchenko]

Today I encountered an issue which is caused by the lack of automatic version 
checks.

One of the users of Fuel Client asked me why it doesn’t work on their 
environment. I realized, that the issue was caused by wrong version 
specification in the Fuel Client requirements list.

I analyzed python-fuelclient’s requirements, RPM’s package requirements and 
Global Requirements and found that none of them was compatible to another one. 
And the issue was not that there is only one package, that is not compatible, 
but that there is only one package, that IS compatible.

Fuel Client is a set of very simple single threaded scripts so detecting 
problems in it is relatively simple. However, we also have complex components 
like Nailgun and different kinds of agents, where a version mismatch may 
produce errors which will take months to discover.

My proposal of sticking to requirements partially fixes this issue. The only 
thing I’d like to add to that scheme is this:

 - Add a CI jod that on daily basis checks whether python-requirements are in 
line with the requirements in RPM specs.


- romcheg


 26 бер. 2015 о 12:07 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 So guys, I think it’s reasonable to find a consensus on this thread.
 
 I think this rule fits fine within the general frame of Roman's proposal:
 
 - if the base distro already has a package that satisfies OpenStack
 global requirements (or Fuel requirements), the distro package is
 used;
 - else, OSCI mirror should contain the maximum version of a
 requirement that matches its version specification.
 
 Yup, that also fits well. The only note I’d like to make here is that OS 
 services are tested against the latest version of requirements. So perhaps we 
 want to test them against the versions, supplied in distos, if those 
 requirements are used.
 
 
 - romcheg
 
 19 бер. 2015 о 19:14 Dmitry Borodaenko dborodae...@mirantis.com 
 написав(ла):
 
 Maciej,
 
 Maintaining multiple versions of the same package concurrently and
 tracking their compatibility with the many different components of
 OpenStack and Fuel creates additional work on many different levels,
 from spec branch management to repo management to validation to
 container building and so on. Unified global requirements help avoid
 such work where it isn't necessary (and when you look close enough
 into each specific case you're likely to find that it's never really
 necessary).
 
 -DmitryB
 
 On Thu, Mar 19, 2015 at 4:04 AM, Maciej Kwiek mkw...@mirantis.com wrote:
 I guess it would depend on how many docker containers are running on master
 node and if we are able to pull off such stunt :).
 
 I am not familiar with the amount of work needed to do sth like that, so the
 proposition may be silly. Just let me know if it is.
 
 On Thu, Mar 19, 2015 at 11:51 AM, Dmitry Burmistrov
 dburmist...@mirantis.com wrote:
 
 Folks,
 
 Correct me if I am wrong, but isn't it what we have containers on
 master node for?
 On the master node itself conflicts won’t happen because the
 components are run in their containers.
 
 Do you propose to use _separate_ package repository for each docker
 container? (It means separate gerrit project for each package of each
 container, including openstack projects)
 
 On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:
 Folks,
 
 I assume you meant: If a requirement that previously was only in Fuel
 Requirements is merged to Global Requirements, it should be removed
 from *Fuel* Requirements».
 
 Exactly.
 
 I'm not sure it's good idea.
 We should stay so close to upstream distro as we can. It should be
 very important reason to update package against it's upstream distro
 
 
 The issue is the following: OpenStack’s components are tested against
 those versions of dependencies, that are specified in their requirements.
 IIRC those requirements are set up by pip so CI nodes contain latest
 versions of python packages that match their specs.
 
 The question is whether it’s required to ship OpenStack services with
 packages from a distro or with packages, that are used for testing.
 
 Splitting of repositories doesn't help to solve python packages
 conflicts because master node uses a number of openstack components.
 
 On the master node itself conflicts won’t happen because the components
 are run in their containers.
 
 
 - romcheg
 
 
 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com
 написав(ла):
 
 Roman, all
 
  - OSCI mirror should contain the maximum version of a
 requirement that matches its version specification.
 I'm not sure it's good idea.
 We should stay so close to upstream distro as we can. It should be
 very important reason to update package against it's upstream distro
 version.
 If we update some package, we should maintain it too. Tracking bugs,
 CVEs and so on. The more packages, the more efforts to support it.
 
 - Set up CI jobs to notify OSCI team if either Global Requirements
 or
 Fuel

Re: [openstack-dev] [Fuel] fuel-dev-tools repo

[Roman Prykhodchenko]

IIRC in this thread we agreed to use separate core groups for different 
repositories 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055111.html 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055111.html
Why not follow that approach in this case?

 27 бер. 2015 о 09:01 Przemyslaw Kaminski pkamin...@mirantis.com написав(ла):
 
 Sorry, I meant
 
 [2] https://github.com/CGenie/fuel-utils/
 
 P.
 
 On 03/27/2015 08:34 AM, Przemyslaw Kaminski wrote:
 Hello,
 
 In accordance with the consensus that was reached on the ML I've set up
 the fuel-dev-tools repository [1]. It will be the target repo to merge
 my 2 private repos [2] and [3] (I don't think it's necessary to set up 2
 different repos for this now). The core reviewers are the fuel-core
 group. I needed core permissions to set things up and merged a
 Cookiecutter patchset [4] to test things. After that I revoked my core
 permissions leaving only the fuel-core team.
 
 P.
 
 [1] https://github.com/stackforge/fuel-dev-tools
 [2] https://github.com/stackforge/fuel-dev-tools
 [3] https://github.com/CGenie/vagrant-fuel-dev
 [4] https://review.openstack.org/#/c/167968/
 
 
 __
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Version bump in the beginning of a release cycle

[Roman Prykhodchenko]

Hi folks,

This end of the release cycle I realized that due to different reasons bumping 
a version of Fuel’s components takes much more than just updating a set of text 
files. In fact it causes different kinds of cross-component problems which of 
course must be fixed.

This email is not about fixing them but about the way of detecting them earlier 
and not delaying any component in the end of release cycles. The idea is not 
mine, I borrowed it from one of our folks asked that in a private channel. I 
decided to tell that in a public place like this mailing list is.

The idea is to bump version in Fuel’s components not in the end of a release 
cycle, but in it’s early beginning, i.e., when a stable branch has been made. 
What are your thoughts on that?


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Let's stick to OpenStack global requirements

[Roman Prykhodchenko]

So guys, I think it’s reasonable to find a consensus on this thread.

 I think this rule fits fine within the general frame of Roman's proposal:
 
 - if the base distro already has a package that satisfies OpenStack
 global requirements (or Fuel requirements), the distro package is
 used;
 - else, OSCI mirror should contain the maximum version of a
 requirement that matches its version specification.

Yup, that also fits well. The only note I’d like to make here is that OS 
services are tested against the latest version of requirements. So perhaps we 
want to test them against the versions, supplied in distos, if those 
requirements are used.


- romcheg

 19 бер. 2015 о 19:14 Dmitry Borodaenko dborodae...@mirantis.com написав(ла):
 
 Maciej,
 
 Maintaining multiple versions of the same package concurrently and
 tracking their compatibility with the many different components of
 OpenStack and Fuel creates additional work on many different levels,
 from spec branch management to repo management to validation to
 container building and so on. Unified global requirements help avoid
 such work where it isn't necessary (and when you look close enough
 into each specific case you're likely to find that it's never really
 necessary).
 
 -DmitryB
 
 On Thu, Mar 19, 2015 at 4:04 AM, Maciej Kwiek mkw...@mirantis.com wrote:
 I guess it would depend on how many docker containers are running on master
 node and if we are able to pull off such stunt :).
 
 I am not familiar with the amount of work needed to do sth like that, so the
 proposition may be silly. Just let me know if it is.
 
 On Thu, Mar 19, 2015 at 11:51 AM, Dmitry Burmistrov
 dburmist...@mirantis.com wrote:
 
 Folks,
 
 Correct me if I am wrong, but isn't it what we have containers on
 master node for?
 On the master node itself conflicts won’t happen because the
 components are run in their containers.
 
 Do you propose to use _separate_ package repository for each docker
 container? (It means separate gerrit project for each package of each
 container, including openstack projects)
 
 On Thu, Mar 19, 2015 at 1:16 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:
 Folks,
 
 I assume you meant: If a requirement that previously was only in Fuel
 Requirements is merged to Global Requirements, it should be removed
 from *Fuel* Requirements».
 
 Exactly.
 
 I'm not sure it's good idea.
 We should stay so close to upstream distro as we can. It should be
 very important reason to update package against it's upstream distro
 
 
 The issue is the following: OpenStack’s components are tested against
 those versions of dependencies, that are specified in their requirements.
 IIRC those requirements are set up by pip so CI nodes contain latest
 versions of python packages that match their specs.
 
 The question is whether it’s required to ship OpenStack services with
 packages from a distro or with packages, that are used for testing.
 
 Splitting of repositories doesn't help to solve python packages
 conflicts because master node uses a number of openstack components.
 
 On the master node itself conflicts won’t happen because the components
 are run in their containers.
 
 
 - romcheg
 
 
 19 бер. 2015 о 10:47 Dmitry Burmistrov dburmist...@mirantis.com
 написав(ла):
 
 Roman, all
 
   - OSCI mirror should contain the maximum version of a
 requirement that matches its version specification.
 I'm not sure it's good idea.
 We should stay so close to upstream distro as we can. It should be
 very important reason to update package against it's upstream distro
 version.
 If we update some package, we should maintain it too. Tracking bugs,
 CVEs and so on. The more packages, the more efforts to support it.
 
 - Set up CI jobs to notify OSCI team if either Global Requirements
 or
 Fuel Requirements are changed.
 - Set up requirements proposal jobs that will automatically propose
 changes to all fuel projects once either of requirements lists was
 changed
 Need to be discussed and investigated.
 
 Sebastian, Dmitry,
 
 
 There are some plans (unfortunately I do not know details, so maybe
 someone from OSCI could tell more) to split those repositories
 Splitting of repositories doesn't help to solve python packages
 conflicts because master node uses a number of openstack components.
 Anyway it should be done for 7.0 milestone in order to separatre
 master-node distro from environment one. (e.g. if we going to move
 master-node to debian)
 
 
 
 On Thu, Mar 19, 2015 at 12:01 AM, Dmitry Borodaenko
 dborodae...@mirantis.com wrote:
 Roman,
 
 I like this proposal very much, thanks for the idea and for putting
 together a straightforward process.
 
 I assume you meant: If a requirement that previously was only in Fuel
 Requirements is merged to Global Requirements, it should be removed
 from *Fuel* Requirements.
 
 Sebastian,
 
 We have found ways to resolve the conflicts between clvm and docker,
 and between ruby versions 1.8 and 2.1, without introducing a separate
 package