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

[Sebastian Kalinowski]

2015-10-23 11:36 GMT+02:00 Igor Kalnitsky :

> 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
>  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 :
> >>
> >> 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.
> >>  - 

Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Sebastian Kalinowski]

2015-10-21 8:11 GMT+02:00 Mike Scherbakov :

>
> Simon is asking a valid request: if you add his folder in the file, he
> will be always added to the review request by script, once it's
> implemented. Only in the case when contribution is made to his particular
> area of responsibility.
>

Mike, when this sript will be implemented? It was promised long time ago
[1]. It is a important part of whole review process change and I doubt that
people would like to manually go
through MAINTAINERS with every review they post.

Also there was a request to add a job for validating MAINTAINERS file, how
is the progress with that?

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

Re: [openstack-dev] [Fuel] Proposal to freeze old Fuel CLI

[Sebastian Kalinowski]

Roman, this was already discussed in [1].
The conclusion was that we will implement new features in both places so
user will not have to
use "old" fuelclient to do some things and the "new" to others.
There were no progress with moving old commands to new CLI and I didn't
seen plans to do so.
IMHO without a detailed plan on migrating old commands to new client and
without a person (or people)
that will drive this task we *cannot* freeze old fuelclient as new one is
still not fully usable.

Best,
Sebastian

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html


2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko :

> Fuelers,
>
> as you know a big effort has been put into making Fuel Client’s CLI better
> and as a result we got a new fuel2 utility with a new set of commands and
> options. Some folks still put great effort to move everything that’s left
> in the old CLI to the new CLI.
>
> Every new thing added to the old CLI moves the point where we can finally
> remove it to the future. My proposal is to do a hard code freeze for the
> old CLI and only add new stuff to the new one.
>
>
> - 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

Re: [openstack-dev] [Fuel] py.test vs testrepository

[Sebastian Kalinowski]

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.

Additionally other folks showed that this is not a blocker for moving under
big tent.

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

Re: [openstack-dev] [Fuel] Nominate Denis Dmitriev for fuel-qa(devops) core

[Sebastian Kalinowski]

+1

2015-09-14 22:37 GMT+02:00 Ivan Kliuk :

> +1
>
> On Mon, Sep 14, 2015 at 10:19 PM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> Folks,
>> I would like to nominate Denis Dmitriev[1] for fuel-qa/fuel-devops core.
>>
>> Dennis spent three months in Fuel BugFix team, his velocity was between
>> 150-200% per week. Thanks to his efforts we have won these old issues with
>> time sync and ceph's clock skew. Dennis's ideas constantly help us to
>> improve our functional system suite.
>>
>> Fuelers, please vote for Denis!
>>
>> Nastya.
>>
>> [1]
>> http://stackalytics.com/?user_id=ddmitriev=all_type=all=fuel-qa
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "fuel-core-team" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to fuel-core-team+unsubscr...@mirantis.com.
>> For more options, visit https://groups.google.com/a/mirantis.com/d/optout
>> .
>>
>
>
>
> --
> Best regards,
> Ivan Kliuk
>
> --
> You received this message because you are subscribed to the Google Groups
> "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fuel-core-team+unsubscr...@mirantis.com.
> For more options, visit https://groups.google.com/a/mirantis.com/d/optout.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Sebastian Kalinowski]

+1

2015-09-03 21:34 GMT+02:00 Bartlomiej Piotrowski :

> I have no idea if I'm eligible to vote, but I'll do it anyway:
>
> +1
>
> Bartłomiej
>
> On Thu, Sep 3, 2015 at 9:16 PM, Sergey Vasilenko 
> wrote:
>
>> +1
>>
>> /sv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sebastian Kalinowski]

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:

 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:

 Roman,

 well done! ;)

 Best regards,
 Boris Pavlovic

 On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko 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



 __
 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


 __
 OpenStack Development Mailing 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] Great updates to tests and CI jobs

[Sebastian Kalinowski]

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:

 Roman,

 well done! ;)

 Best regards,
 Boris Pavlovic

 On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko 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://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] SSL for master node API

[Sebastian Kalinowski]

+1 for option 2)

But I have a question: how do we fit with this into the scope of Feature
Freeze and Soft Code Freeze this week?
Any ETAs?

2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com:

 FYI: There is Strict-Transport-Security
 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security header
 which can also be useful here (unless we want to make SSL for master node
 optional)

 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov vshars...@mirantis.com:

 Hi,

 +1 to 2nd solution too.

 On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 +1 to 2nd solution, in this case old environments will work without
 additional
 actions. Agents for new environments, CLI and UI will use SSL.
 But probably for UI we will have to perform redirect on JS level.

 Thanks,

 On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin 
 sbogat...@mirantis.com wrote:

 Hi guys,
 in overall movement of Fuel to use secure sockets we think about
 wrapping master node UI and API calls to SSL. But there are next caveat:

 a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten
 a little. But if it will be rewritten in 7.0 and HTTPS on master node will
 be forced by default, it will break upgrade from previous releases to 7.0
 due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS
 by default and fuel-nailgun-agent on all environments won't upgraded, so it
 won't be able to connect to master node after upgrade. It breaks seamless
 upgrade procedure.

 What options I see there:
 1. We can forcedly enable SSL for master node and rewrite clients in
 7.0 to be able to work over it. In release notes for 7.0 we will write
 forewarning that clients which want to upgrade master node from previous
 releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
 all deployed environments.

 2. We can have both SSL and non-SSL versions enabled by default and
 rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
 availability and be able to work in plain HTTP for legacy mode. So, for all
 new environments SSL will be used by default and for old ones plain HTTP
 will continue to work too. Master node upgrade will not be broken in this
 case.

 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
 save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
 releases. It is just postponed version of first clause, so it doesn't seems
 valid for me, actually.

 I would be really glad to hear what you think about this. Thank you in
 advance.


 __
 OpenStack Development Mailing 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




 --
 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


__
OpenStack Development Mailing 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] Feedback

[Sebastian Kalinowski]

2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com:

 Hi Sheena,

 Created ticket to change the structure of the directories [1].
 And as far as I know any core can push tags into the repository,
 Sebastian, Igor and I.


One correction: I'm not a core in fuel-plugins ;)



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

 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com
 wrote:

 Evgeniy –



 For the items which you have listed actions, who should be responsible
 for next steps?



 Sheena



 *From:* Evgeniy L [mailto:e...@mirantis.com]
 *Sent:* Tuesday, July 28, 2015 11:54 AM
 *To:* OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



 Hi Sergii, thank you for feedback,



  c. There is no documentation how to install fpb from github master
 branch. It's very useful for developers who want to use latest version. We
 should add something



 We had a documentation, but removed it because the newer fpb was released,

 probably we should add this information permanently [1].



  a. We are doing the same mistake putting all things into one basket.
 There should be 2 repositories. One for examples and one for fpb. What's
 the goal of keeping fpb in directory and examples on top?



 These plugins are the data which are required for integration testing,

 we test that plugin build is not broken, which we run when patch gets

 published. I see nothing wrong with having the data for integration
 testing

 in the same repository with product which should be tested.

 Also in previous release we *removed* all the plugins which are not

 related to the builder itself, lbaas and glusterfs.



  This breaks a couple of things



 Having data for testing in the repository doesn't break anything.



  b. I cannot build fpm with simple



 That is a good point, we should move code from fuel_plugin_builder
 directory

 on top level, and move data for testing into examples directory.



  c. There is no tags as I can see only stable/6.0



 Correct, tags should be added.



  d. There are no tests to improve code quality pep8 flask8, code
 coverage



 That is not true, there are more then one hundreds unit tests which we run

 for each patch with python 2.6 and python 2.7, also there are integration
 tests

 which check that for each patch we don't break validation and that we can

 build plugins for previous versions. Plus there are functional tests
 which are

 written by fuel-qa team, those tests check that we perform deployment

 with plugins and required functionality works correctly. Also there *is*
 pep8

 check [2].



  e. Repository doesn't follow community standards.



 I think this issue should be resolved with moving fuel_plugin_builder
 directory

 on level higher, if not, please provide more specific description what is
 wrong.



  3. Setting tab ...



 Agree.



 [1]
 https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204

 [2]
 https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:

 Hi,

 I have started digging into plugins recently. There are many positive
 things though I would like to point to some problem areas

 1. Documentation

 a. It doesn't include the features of 7.0. There are many outstanding
 features, though I needed to ping the developers to ask how these features
 work. It means that it's almost impossible to develop plugins for upcoming
 releases. The external developer needs to wait for documentation so it
 creates a lag between release and plugin release.

 b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
 to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
 to 12.04

 c. There is no documentation how to install fpb from github master
 branch. It's very useful for developers who want to use latest version. We
 should add something

 2. Github repository [2] is messed up

 a. We are doing the same mistake putting all things into one basket.
 There should be 2 repositories. One for examples and one for fpb. What's
 the goal of keeping fpb in directory and examples on top? This breaks a
 couple of things

 b. I cannot build fpm with simple

 pip install git+https://

 Instead I am forced to do

 git clone https://

 cd fuel-plugins

 pip install .



 c. There is no tags as I can see only stable/6.0

 d. There are no tests to improve code quality pep8 flask8, code coverage

 e. Repository doesn't follow community standards.



 3. Setting tab

 When plugin is installed, it's very hard to find in. In setting tab it's
 somewhere between A and Z

 How is user supposed to find it? There should be a separator between Core
 features and plugins. User must easily find, configure, enable/disable them.

 P.S. I am asking everyone to add own concerns so we'll be able 

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

[Sebastian Kalinowski]

It looks like most people agree on option C (implement features in fuel and
fuel2) and in the meantime
we should slowly progress with moving fuel to fuel2.

2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk sgolovat...@mirantis.com:

 Hi,

 Every functionality should be applied to both clients. Core developers
 should set -1 if it's not applied to second version of plugin. Though I
 believe we should completely get rid of first version of CLI in Fuel 8.0

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh ogelb...@mirantis.com
 wrote:

 FWIW, I'm for option B, combined with clear timeline for porting features
 of fuel-variant to fuel2. For example, we are developing client-side
 functions for fuel-octane (cluster upgrade) extensions only for fuel2, and
 don't plan to implement it for 'fuel'.

 The main reason why we can't just drop 'fuel', or rather switch it to
 fuel2 syntax, IMO, is the possibility that someone somewhere uses its
 current syntax for automation. However, if the function is completely new,
 the automation of this function should be implemented with the new version
 of syntax.

 --
 Best regards,
 Oleg Gelbukh

 On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev fzhad...@mirantis.com
 wrote:

 Hi all,

 I think that in current situation the best solution will be to add new
 features for the both versions of client. It may cause a little slowing
 down of developing each feature, but we won't have to return to them in
 future.

 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Hello,

 My 2 cents on it.

 Following plan C requires a huge effort from developer, and it may be
 unacceptable when FF is close and there're a lot of work to do. So it
 looks like the plan B is most convenient for us and eventually we will
 have all features in fuel2.

 Alternatively we can go with C.. but only if implementing support in
 either fuel or fuel2 may be postponed to SCF.

 Thanks,
 Igor

 On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote:
  Hi Sebastian, thanks for clarification, in this case I think we
  should follow plan C, new features should not slow us down
  in migration from old to new version of the client.
 
  On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski
  skalinow...@mirantis.com wrote:
 
  2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin 
 sbogat...@mirantis.com:
 
  Hi,
 
  can we just add all needed functionality from old fuel client that
 fuel2
  needs, then say that old fuel-client is deprecated now and will not
 support
  some new features, then add new features to fuel2 only? It seems
 like best
  way for me, cause with this approach:
  1. Clients will can use only one version of client (new one) w/o
  switching between 2 clients with different syntax
  2. We won't have to add new features to two clients.
 
 
  Stas, of course moving it all to new fuel2 would be the best way to
 do it,
  but this refactoring took place in previous release. There is no one
 that
  ported a single command (except new ones) since then and there is no
 plan
  for doing so since other activities have higher priority. And
 features are
  still coming so it would be nice to have a policy for the time all
 commands
  will move to new fuel2.
 
 
 
  On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com
 wrote:
 
  Hi,
 
  The best option is to add new functionality to fuel2 only, but I
  don't think that we can do that if there is not enough
 functionality
  in fuel2, we should not ask user to switch between fuel and fuel2
  to get some specific functionality.
  Do we have some list of commands which is not covered in fuel2?
  I'm just wondering how much time will it take to implement all
  required commands in fuel2.
 
 
  So to compare: this is a help message for old fuel [1] and new
 fuel2
  [2]. There are only node, env and task actions covered and
 even they
  are not covered in 100%.
 
  [1] http://paste.openstack.org/show/404439/
  [2] http://paste.openstack.org/show/404440/
 
 
 
 
  Thanks,
 
  On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski
  skalinow...@mirantis.com wrote:
 
  Hi folks,
 
  For a some time in python-fuelclient we have two CLI apps: `fuel`
 and
  `fuel2`. It was done as an implementation of blueprint [1].
  Right now there is a situation where some new features are added
 just
  to old `fuel`, some to just `fuel2`, some to both. We cannot
 simply switch
  completely to new `fuel2` as it doesn't cover all old commands.
  As far as I remember there was no agreement how we should proceed
 with
  adding new things to python-fuelclient, so to keep all
 development for new
  commands I would like us to choose what will be our approach.
 There are 3
  ways to do it (with some pros and cons):
 
  A) Add new features only to old `fuel`.
  Pros:
   - Implement feature in one place
   - Almost all features are covered there
  Cons:
   - Someone will need to port this features to new

Re: [openstack-dev] [fuel] FFE for bug/1475759 ceph generators

[Sebastian Kalinowski]

Andrew, thanks for this request and for the explanations.

+1 for this exception. The new generators are not conflicting with existing
ones, code is ready and tested so let's merge it.

2015-07-25 1:24 GMT+02:00 Andrew Woodward xar...@gmail.com:

 I'm writing to ask for a FFE for landing the ceph generators. It finally
 received core-reviewers attention late on Wednesday and Thursday and is
 ready to merge now. I'm only asking for FFE because reviewers are calling
 this a feature.

 Possible impact, none. This is not used by anything yet and should be
 merged.

 [1] https://bugs.launchpad.net/fuel/+bug/1475759
 [2] https://review.openstack.org/#/c/203270/
 --

 --

 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


__
OpenStack Development Mailing 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] FF Exception request for Templates for Networking feature

[Sebastian Kalinowski]

Yes, exactly like that.

+1

2015-07-27 10:53 GMT+02:00 Evgeniy L e...@mirantis.com:

 So, to summarise, +1 from me, we accept the changes which are required
 for the feature as feature freeze exceptions:

 1. Fuel client changes [1]
 2. Validation [2]
 3. Change tokens in template language

 Sebastian, Igor, correct?

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

 On Sat, Jul 25, 2015 at 1:25 AM, Andrew Woodward xar...@gmail.com wrote:

 Igor,

 https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the FFE
 if you think it's a feature. Networking is the most complicated and
 frustrating thing the user can work with. If we cant provide usable
 feedback from bad data in the template then the feature is useless. I could
 argue that its a critical UX defect.


 On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote:

 Aleksey,

 Yes, my point is those parts should be also included in the scope of FFE.
 Regarding to template format, it's easy to fix and after release you
 will not
 be able to change it, or you can change it, but you will have to support
 both
 format, not to brake backward compatibility. So I would prefer to see it
 fixed
 in 7.0.

 Thanks,

 On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin 
 akasat...@mirantis.com wrote:

 I agree, guys, we need at least some basic validation for template when
 it is being loaded.
 Ivan Kliuk started to work on this task.
 And we agreed to test other types of delimiters (it is regarding ERB
 style template) but we have some more important issues.
 Evgeniy, is your meaning to include those to FFE ?


 Aleksey Kasatkin


 On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski 
 skalinow...@mirantis.com wrote:

 I agree here with Evgeniy. Even if it's not a trivial change, we
 cannot leave a new API in such shape.

 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:

 Hi Igor,

 I don't agree with you, some basic validation is essential part of
 any handler and our API, currently it's easy to get meaningless 500
 error
 (which is unhandled exception) from the backend or get the error that
 there
 is something wrong with the template only after you press deploy
 button.
 It's a bad UX and contradicts to our attempts to develop good api.

 Thanks,

 On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky 
 ikalnit...@mirantis.com wrote:

 Greetings,

 The issue [1] looks like a feature to me. I'd move it to next
 release.
 Let's focus on what's important right now - stability.

 Thanks,
 Igor

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

 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com
 wrote:
  Hi,
 
  Since the feature is essential, and changes are small, we can
 accept it as
  a,
  feature freeze exceptions.
 
  But as far as I know there is a very important ticket [1] which
 was created
  in
  order to get patches merged faster, also I still have concerns
 regarding to
  ERB style template % if3 % which is in fact Jinja. So it's not
 only
  about
  fixes in the client.
 
  [1] https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov 
 mscherba...@mirantis.com
  wrote:
 
  Looks like the only CLI part left:
  https://review.openstack.org/#/c/204321/, and you guys did a
 great job
  finishing the other two.
 
  Looks like we'd need to give FF exception, as this is essential
 feature.
  It's glad that we merged all other thousands lines of code. This
 is the most
  complex feature, and seems like the only small thing is left.
 
  I'd like to hear feedback from Nailgun cores  fuel client SMEs.
 For me,
  it seems it is lower risk, and patch is relatively small. How
 long would it
  take to complete it? If it takes a couple of days, then it is
 fine. If it is
  going to take week or two, then we will have to have it as a risk
 for HCF
  deadline. Spending resources on features now, not on bugs, means
 less
  quality or slip of the release.
 
  On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin 
 akasat...@mirantis.com
  wrote:
 
  Team,
 
  I would like to request an exception from the Feature Freeze for
  Templates for Networking feature [1].
 
  Exception is required for two CRs to python-fuelclient: [2],[3]
 and one
  CR to fuel-web (Nailgun): [4].
  These CRs are for adding ability to create/remove networks via
 API [4]
  and for supporting new API functionality via CLI.
  These patchsets are for adding new templates-related
 functionality and
  they do not change existing functionality.
  Patchsets [3],[4] are in deep review and they will hopefully be
 merged on
  Thursday.
 
  Please, respond if you have any questions or concerns related to
 this
  request.
 
  Thanks in advance.
 
  [1]
 https://blueprints.launchpad.net/fuel/+spec/templates-for-networking
  [2] https://review.openstack.org/#/c/204321/
  [3] https://review.openstack.org/#/c/203602/
  [4] https://review.openstack.org/#/c/201217/
 
  --
  Best regards,
  Aleksey

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Sebastian Kalinowski]

I agree here with Evgeniy. Even if it's not a trivial change, we cannot
leave a new API in such shape.

2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:

 Hi Igor,

 I don't agree with you, some basic validation is essential part of
 any handler and our API, currently it's easy to get meaningless 500 error
 (which is unhandled exception) from the backend or get the error that there
 is something wrong with the template only after you press deploy button.
 It's a bad UX and contradicts to our attempts to develop good api.

 Thanks,

 On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 Greetings,

 The issue [1] looks like a feature to me. I'd move it to next release.
 Let's focus on what's important right now - stability.

 Thanks,
 Igor

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

 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote:
  Hi,
 
  Since the feature is essential, and changes are small, we can accept it
 as
  a,
  feature freeze exceptions.
 
  But as far as I know there is a very important ticket [1] which was
 created
  in
  order to get patches merged faster, also I still have concerns
 regarding to
  ERB style template % if3 % which is in fact Jinja. So it's not only
  about
  fixes in the client.
 
  [1] https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov 
 mscherba...@mirantis.com
  wrote:
 
  Looks like the only CLI part left:
  https://review.openstack.org/#/c/204321/, and you guys did a great job
  finishing the other two.
 
  Looks like we'd need to give FF exception, as this is essential
 feature.
  It's glad that we merged all other thousands lines of code. This is
 the most
  complex feature, and seems like the only small thing is left.
 
  I'd like to hear feedback from Nailgun cores  fuel client SMEs. For
 me,
  it seems it is lower risk, and patch is relatively small. How long
 would it
  take to complete it? If it takes a couple of days, then it is fine. If
 it is
  going to take week or two, then we will have to have it as a risk for
 HCF
  deadline. Spending resources on features now, not on bugs, means less
  quality or slip of the release.
 
  On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin 
 akasat...@mirantis.com
  wrote:
 
  Team,
 
  I would like to request an exception from the Feature Freeze for
  Templates for Networking feature [1].
 
  Exception is required for two CRs to python-fuelclient: [2],[3] and
 one
  CR to fuel-web (Nailgun): [4].
  These CRs are for adding ability to create/remove networks via API [4]
  and for supporting new API functionality via CLI.
  These patchsets are for adding new templates-related functionality and
  they do not change existing functionality.
  Patchsets [3],[4] are in deep review and they will hopefully be
 merged on
  Thursday.
 
  Please, respond if you have any questions or concerns related to this
  request.
 
  Thanks in advance.
 
  [1]
 https://blueprints.launchpad.net/fuel/+spec/templates-for-networking
  [2] https://review.openstack.org/#/c/204321/
  [3] https://review.openstack.org/#/c/203602/
  [4] https://review.openstack.org/#/c/201217/
 
  --
  Best regards,
  Aleksey Kasatkin
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  --
  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
 
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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



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


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

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Env Upgrade feature

[Sebastian Kalinowski]

+1 for this exception - as Evgeniy said it is developed not in the core but
in extension and risk is low.

2015-07-24 10:17 GMT+02:00 Evgeniy L e...@mirantis.com:

 Hi,

 If we have a rule that feature freeze exceptions should have essential
 priority,
 I'm not sure if it matters how risky it's, the risk is low, but it's not
 zero.

 Thanks,

 On Thu, Jul 23, 2015 at 9:09 PM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 Oleg,
 considering that your feature is essential for the release, sounds like
 there is no way we can't give an exception.

 I'm glad that it's perceived by low risk by core reviewer from Nailgun
 team (Evgeny). If there are no concerns from other, then we are giving FF
 exception. However, I'd like to understand how much it will take to finish
 this work and additional resources required.

 We need to switch to bugfix work, and the more we continue working on
 features / enhancements, the less confidence I have that we can meet HCF
 deadline.

 Thanks,

 On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote:

 Hi,

 The patch into Nailgun requires additional work to do, but as far as I
 can see
 it doesn't affect any other parts of the system, also it's implemented
 as an
 extension, which means if the feature will introduce bugs which we won't
 be able to fix in a required time, it can be easily disabled without
 removing from
 master with just removing one line from a file [1] (removing it from
 extensions list).

 So I think it's ok to accept environment upgrade feature as an exception
 for feature
 freeze.

 Thanks,

 [1]
 https://review.openstack.org/#/c/202969/7/nailgun/nailgun/extensions/base.py

 On Wed, Jul 22, 2015 at 10:18 PM, Oleg Gelbukh ogelb...@mirantis.com
 wrote:

 Team,

 I would like to request an exception from the Feature Freeze for
 Environment Upgrade extensions added to the Nailgun API [1]. The Nailgun
 side of the feature is implemented in the following CRs:


 https://review.openstack.org/#/q/status:open+topic:bp/nailgun-api-env-upgrade-extensions,n,z

 These changes are implemented as an extension [2] to the Nailgun. It
 barely touches the core code and doesn't change the existing functionality.

 Please, respond if you have any questions or concerns related to this
 request.

 Thanks in advance.

 [1] https://review.openstack.org/#/c/192551/
 [2]
 https://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z

 --
 Best regards,
 Oleg Gelbukh


 __
 OpenStack Development Mailing 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

 --
 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



 __
 OpenStack Development Mailing 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] Get rid of fuelmenu

[Sebastian Kalinowski]

I'm against getting rid of fuelmenu. As Alex wrote - we need to remember
who are the people that we are targeting.
We are adding multiple dialog windows with confirmations, warnings and
special way to do dangerous actions
(like environment deletion or reset), but in the same time we want to force
users to change config file.
If the UX of fuelmenu is bad - then we can change it. If the code is hard
to maintain and extend - well, I hope that no
one need explanations what to do with and how to avoid such issues in
future.
So I would rather spend time on improving fuelmenu than write a new thing
that will not be better.

Sebastian

2015-07-23 19:04 GMT+02:00 Alex Schultz aschu...@mirantis.com:

 For this to be consumable by end-users, a config file and editor (vim
 seriously?) is terrible UX.  We need to remember who we are targeting to
 consume this functionality as it may not be an expert or even someone
 absolutely familiar with the linux tool set.  While the existing thing may
 be awkward, it is going to be less error prone to someone accidentally
 deleteing half of a config file and not being able to recover.  If you want
 to ditch ncurses, then sure why don't we switch to an answer file and
 question/answer wizard for configuration?  This would allow both validation
 and the ability to override it with a config file.

 -Alex

 On Thu, Jul 23, 2015 at 11:49 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 The topic is NOT 'get rid of validation' but rather 'get rid of
 semi-graphical ncurses based interface'. It is not so hard to adopt every
 piece of validation we currently have in fuelmenu and implement even more
 including syntax validation using, for example, PLY and logic validation.
 My idea is to switch from ncurses to plain text file (thoroughly
 commented), because it so easy to add new parameters or remove those we
 don't need any more.




 Vladimir Kozhukalov

 On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase nch...@mirantis.com wrote:



  On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn 
 mmoses...@mirantis.commmoses...@mirantis.com wrote:

 Here's a relic of what users used to have to configure by
 hand:

 https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

 Am I alone in thinking it's not the best use of our development
 resources to throw it away and replace it with a text file that is
 edited by hand?


 Please, please, please, I'm having PTSD just remembering that @#$%@#%$
 file.  I think I was able to successfully deploy without major engineering
 help about 2% of the time.  We absolutely, positively, MUST maintain the
 validation.

 Just because the people installing OpenStack are generally not afraid to
 edit config files doesn't mean that we should be making them do it.

  Nick


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



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



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


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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

[Sebastian Kalinowski]

+1

2015-07-23 19:23 GMT+02:00 Dmitry Borodaenko dborodae...@mirantis.com:

 +1

 On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin sbogat...@mirantis.com
 wrote:

 +1

 On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com
 wrote:

 +1

 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
 wrote:

 At the moment we have several core reviewers for the fuel-main project.

 Roman Vyalov is responsible for merging of infrastructure-related
 variables and for the lists of packages.
 I am responsible for merges in make system. And I have not so much time
 for digging into makefiles.

 Vladimir Kozhukalov is responsible for the makesystem for a long time.
 And now he works on reducing complexity of the system. I do not merge any
 single patch without his approval. It's time to give formal transfer of
 responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
 core.

 Please reply with +1/-1.


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




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


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


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


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

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

[Sebastian Kalinowski]

+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:

 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 wrote:
  Team,
 
  I would like to request an exception from the Feature Freeze for CLI
 changes
  of working with custom node labels added to fuelclient (fuel2) [1]. UI
 and
  Nailgun parts of the story are already merged [2].
 
  There CLI request is being actively reviewed, the base flow is accepted.
  There are minimal risks here since the changes added to fuel2 version.
 
  Please, respond if you have any questions or concerns related to this
  request.
 
  Thanks in advance,
  Julia
 
  [1] https://review.openstack.org/#/c/204524/
  [2] https://review.openstack.org/#/c/201472/
 
 
 __
  OpenStack Development Mailing 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][python-fuelclient] Implementing new commands

[Sebastian Kalinowski]

2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com:

 Hi,

 can we just add all needed functionality from old fuel client that fuel2
 needs, then say that old fuel-client is deprecated now and will not support
 some new features, then add new features to fuel2 only? It seems like best
 way for me, cause with this approach:
 1. Clients will can use only one version of client (new one) w/o switching
 between 2 clients with different syntax
 2. We won't have to add new features to two clients.


Stas, of course moving it all to new fuel2 would be the best way to do it,
but this refactoring took place in previous release. There is no one that
ported a single command (except new ones) since then and there is no plan
for doing so since other activities have higher priority. And features are
still coming so it would be nice to have a policy for the time all commands
will move to new fuel2.



 On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 The best option is to add new functionality to fuel2 only, but I
 don't think that we can do that if there is not enough functionality
 in fuel2, we should not ask user to switch between fuel and fuel2
 to get some specific functionality.
 Do we have some list of commands which is not covered in fuel2?
 I'm just wondering how much time will it take to implement all
 required commands in fuel2.


So to compare: this is a help message for old fuel [1] and new fuel2
[2]. There are only node, env and task actions covered and even they
are not covered in 100%.

[1] http://paste.openstack.org/show/404439/
[2] http://paste.openstack.org/show/404440/




 Thanks,

 On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski 
 skalinow...@mirantis.com wrote:

 Hi folks,

 For a some time in python-fuelclient we have two CLI apps: `fuel` and
 `fuel2`. It was done as an implementation of blueprint [1].
 Right now there is a situation where some new features are added just to
 old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
 completely to new `fuel2` as it doesn't cover all old commands.
 As far as I remember there was no agreement how we should proceed with
 adding new things to python-fuelclient, so to keep all development for new
 commands I would like us to choose what will be our approach. There are 3
 ways to do it (with some pros and cons):

 A) Add new features only to old `fuel`.
 Pros:
  - Implement feature in one place
  - Almost all features are covered there
 Cons:
  - Someone will need to port this features to new `fuel2`
  - Issues that forced us to reimplement whole `fuel` as `fuel2`

 B) Add new features only to new `fuel2`
 Pros:
  - Implement feature in one place
  - No need to cope with issues in old `fuel` (like worse UX, etc.)
 Cons:
  - Not all features are covered by `fuel2` so user will need to switch
 between `fuel` and `fuel2`

 C) Add new features to both CLIs
 Pros:
  - User can choose which tool to use
  - No need to port feature later...
 Cons:
  - ...but it still doubles the work
  - We keep alive a tool that should be replaced (old `fuel`)


 Best,
 Sebastian

 [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client


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



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



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


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

[openstack-dev] [Fuel][python-fuelclient] Implementing new commands

[Sebastian Kalinowski]

Hi folks,

For a some time in python-fuelclient we have two CLI apps: `fuel` and
`fuel2`. It was done as an implementation of blueprint [1].
Right now there is a situation where some new features are added just to
old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
completely to new `fuel2` as it doesn't cover all old commands.
As far as I remember there was no agreement how we should proceed with
adding new things to python-fuelclient, so to keep all development for new
commands I would like us to choose what will be our approach. There are 3
ways to do it (with some pros and cons):

A) Add new features only to old `fuel`.
Pros:
 - Implement feature in one place
 - Almost all features are covered there
Cons:
 - Someone will need to port this features to new `fuel2`
 - Issues that forced us to reimplement whole `fuel` as `fuel2`

B) Add new features only to new `fuel2`
Pros:
 - Implement feature in one place
 - No need to cope with issues in old `fuel` (like worse UX, etc.)
Cons:
 - Not all features are covered by `fuel2` so user will need to switch
between `fuel` and `fuel2`

C) Add new features to both CLIs
Pros:
 - User can choose which tool to use
 - No need to port feature later...
Cons:
 - ...but it still doubles the work
 - We keep alive a tool that should be replaced (old `fuel`)


Best,
Sebastian

[1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Sebastian Kalinowski]

+1

2015-06-30 10:38 GMT+02:00 Evgeniy L e...@mirantis.com:

 +1

 On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 +1. Alex's doing a great job!

 On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
 svasile...@mirantis.com wrote:
  +1
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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



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


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

Re: [openstack-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

[Sebastian Kalinowski]

+1

2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com:

 +1, indeed Julia's reviews are very thorough.

 P.

 On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
  Hi,
 
  I'd like to nominate Julia Aranovich
  http://stackalytics.com/report/users/jkirnosova for fuel-web
  https://github.com/stackforge/fuel-web core team. Julia's reviews are
  always thorough and have decent quality. She is one of the top
  contributors and reviewers in fuel-web repo (mostly for JS/UI stuff).
 
  Please vote by replying with +1/-1.
 
  --
  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
 

 __
 OpenStack Development Mailing 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][NetApp plugin] Samuel Bartel added as a maintainer

[Sebastian Kalinowski]

Hello,

Today we added Samuel Bartel as a Core Review for NetApp plugin [1]. He
will be now main
person leading the plugin development.

Congrats!

Best,
Sebastian

[1] https://github.com/stackforge/fuel-plugin-cinder-netapp
__
OpenStack Development Mailing 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] Moving old plugins to stackforge-attic

[Sebastian Kalinowski]

Hello,

I propose to move two old, unmaintained plugins to stackforge-attic as
there is no interest or plans in continuing development of them:

* https://github.com/stackforge/fuel-plugin-group-based-policy -
development is now done in another repository as different plugin
* https://github.com/stackforge/fuel-plugin-external-nfs - was created just
to check how to article

Let's use lazy consensus and see if no one have any objections for next
week (April 24th).

Best,
Sebastian
__
OpenStack Development Mailing 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] development tools

[Sebastian Kalinowski]

As I wrote in the review already: I like the idea of merging
those two tools and making a separate repository. After that
we could make they more visible in our documentation and wiki
so they could benefit from being used by broader audience.

Same for vagrant configuration - if it's useful (and it is
since newcomers are using them) we could at least move under
Mirantis organization on Github.

Best,
Seabastian


2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com:

 Hello,

 Some time ago I wrote some small tools that make Fuel development easier
 and it was suggested to add info about them to the documentation --
 here's the review link [1].

 Evgenyi Li correctly pointed out that we already have something like
 fuel_development already in fuel-web. I think though that we shouldn't
 mix such stuff directly into fuel-web, I mean we recently migrated CLI
 to a separate repo to make fuel-web thinner.

 So a suggestion -- maybe make these tools more official and create
 stackforge repos for them? I think dev ecosystem could benefit by having
 some standard way of dealing with the ISO (for example we get questions
 from people how to apply new openstack.yaml config to the DB).

 At the same time we could get rid of fuel_development and merge that
 into the new repos (it has the useful 'revert' functionality that I
 didn't think of :))

 P.

 [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst

 __
 OpenStack Development Mailing 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] Let's stick to OpenStack global requirements

[Sebastian Kalinowski]

I assume that you considered a situation when we have a common repository
with RPMs for Fuel master and for nodes.
There are some plans (unfortunately I do not know details, so maybe someone
from OSCI could tell more) to split those repositories. How this workflow
will work with those separated repos? Will we still need it?

Thanks!
Sebastian

2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me:

 Hi folks,

 before you say «romcheg, go away and never come back again!», please read
 the story that caused me to propose this and the proposed solution. Perhaps
 it makes you reconsider :)

 As you know for different reasons, among which are being able to set up
 everything online and bringing up-to-date packages, we maintain an OSCI
 repository which is used for building ISOs and deploying OpenStack
 services. Managing that repo is a pretty hard job. Thus a dedicated group
 of people is devoted to perform that duty, they are always busy because of
 a lot of responsibilities they have.

 At the same time Fuel’s developers are pretty energetic and always want to
 add new features to Fuel. For that they love to use different libraries,
 many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add
 more and more of those and I guess that’s pretty fine except one little
 thing — sometimes those libraries conflict with ones, required by OpenStack
 services.

 To prevent that from happening someone has to check every patch against
 the OSCI repo and OpenStack’s global requirements, to detect whether a
 version bump or adding a new library is required an whether it can be
 performed. As you can guess, there’s too much of a human factor so
 statistically no one does that until problems appear. Moreover, theres’
 nothing but a «it’s not compatible with OpenStack» yelling from OSCI team
 that stops developers to change dependencies in Fuel.

 All the stuff described above causes sometimes tremendous time losses and
 is very problem-prone.

 I’d like to propose to make everyone’s life easier by following these
 steps:

  - Create a new project called Fuel Requirements, all changes to it should
 go through a standard review procedure
  - We strict ourselves to use only packages from both Fuel Requirements
 and Global Requirements for the version of OpenStack, Fuel is installing in
 the following manner:
 - If a requirement is in Global Requirements, the version spec in all
 Fuel’s components should be exactly like that.
 - OSCI mirror should contain the maximum version of a requirement
 that matches its version specification.
 - If a requirement is not in the global requirements list, then Fuel
 Requirements list should be used to check whether all Fuel’s components
 require the same version of a library/package.
 - OSCI mirror should contain the maximum version of a requirement
 that matches its version specification.
 - If a requirement that previously was only in Fuel Requirements is
 merged to Global Requirements, it should be removed from Global Requirements
   - Set up CI jobs in both OpenStack CI and FuelCI to check all patches
 against both Global Requirements and Fuel Requirements and block, if either
 of checks doesn’t pass
   - 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,
 just like it’s done for OpenStack projects.


 These steps may look terribly hard, but most of the job is already done in
 OpenStack projects and therefore it can be reused for Fuel.
 Looking forward for your feedback folks!


 - 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

Re: [openstack-dev] [Fuel] Python code in fuel-library

[Sebastian Kalinowski]

Hi,

I've created a patchset that introduces a script to run Python tests in
fuel-library [1] and a
Jenkins job [2]

I also would like to backport those tests to stable branches to assure that
any fix backported to stable branches will be also
checked.

Best,
Sebastian

[1] https://review.openstack.org/#/c/157319/
[2] https://review.fuel-infra.org/#/c/3810/

2015-02-18 16:01 GMT+01:00 Aleksandr Didenko adide...@mirantis.com:

 Hi,

 I agree that we need a better testing for python tasks/code. There should
 be no problems adding py.test tests into fuel-library CI, we already have
 one [1] up and running. So I'm all in and ready to help with such testing
 implementation.

 [1] https://fuel-jenkins.mirantis.com/job/fuellib_tasks_graph_check/

 Regards,
 Aleksandr

 On Wed, Feb 18, 2015 at 4:02 PM, Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 Hi, Seb

 Very fair point, thank you. We need to add this to our jobs for unittests
 run and syntax check. I am adding Aleksandr Didenko into the loop as he is
 currently working on the similar task.

 On Wed, Feb 18, 2015 at 4:53 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 02/18/2015 04:57 AM, Sebastian Kalinowski wrote:

 Hello Fuelers,

 There is more and more Python code appearing in fuel-library [1] that is
 used in our Puppet manifests. Now, with introduction of Granular
 Deployment feature it could appear more often as
 writing some tasks as a Python script is a nice option.

 First problem that I see is that in some cases this code is getting
 merged without a positive review from a Python developer from Fuel team.
 My proposition of the solution is simple:
 fuel-library core reviewers shouldn't merge such code if there is no a
 +1 from a Python developer from fuel-core group [2].

 Second problem is that there are no automatic tests for this code.
 Testing it manually and by running deployment when that code is used is
 not enough since those scripts could be quite large and complicated and
 some of them are executed in specific situations so it is hard for
 reviewers to check how they will work.
 In fuel-library we already have tests for Puppet modules: [3].
 I suggest that we should introduce similar checks for Python code:
   - there will be one global 'test-requirements.txt' file (if there will
 be a need to, we could introduce more granular split, like per module)
   - py.test [4] will be used as a test runner
   - (optional, but advised) flake8+hacking checks [5] (could be limited
 to just run flake8/pyflakes checks)

 Looking forward to your opinions on those two issues.


 Hi Seba,

 All those suggestions look fine to me. I'd also add to improve the
 documentation on how to write and run Python tests to help out those
 developers who are not as familiar with Python as Ruby or other languages.

 Best,
 -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




 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 45bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com http://www.mirantis.ru/
 www.mirantis.ru
 vkuk...@mirantis.com



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


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

[openstack-dev] [Fuel] Python code in fuel-library

[Sebastian Kalinowski]

Hello Fuelers,

There is more and more Python code appearing in fuel-library [1] that is
used in our Puppet manifests. Now, with introduction of Granular Deployment
feature it could appear more often as
writing some tasks as a Python script is a nice option.

First problem that I see is that in some cases this code is getting merged
without a positive review from a Python developer from Fuel team.
My proposition of the solution is simple:
fuel-library core reviewers shouldn't merge such code if there is no a +1
from a Python developer from fuel-core group [2].

Second problem is that there are no automatic tests for this code. Testing
it manually and by running deployment when that code is used is not enough
since those scripts could be quite large and complicated and some of them
are executed in specific situations so it is hard for reviewers to check
how they will work.
In fuel-library we already have tests for Puppet modules: [3].
I suggest that we should introduce similar checks for Python code:
 - there will be one global 'test-requirements.txt' file (if there will be
a need to, we could introduce more granular split, like per module)
 - py.test [4] will be used as a test runner
 - (optional, but advised) flake8+hacking checks [5] (could be limited to
just run flake8/pyflakes checks)

Looking forward to your opinions on those two issues.

Best,
Sebastian

[1] https://github.com/stackforge/fuel-library/search?l=python
[2] https://review.openstack.org/#/admin/groups/209,members
[3] https://fuel-jenkins.mirantis.com/job/fuellib_unit_tests/
[4] http://pytest.org/latest/
[5] https://github.com/openstack-dev/hacking
__
OpenStack Development Mailing 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] Fuel plugin builder tagging and pypi publishing

[Sebastian Kalinowski]

+1 for the whole idea, I really waited for it until first release of
fuel-plugin-builder.

Without tags it's hard to say which commit is included in PyPI release.
Also automation of release process is a really nice thing and make it more
transparent.

2015-02-13 9:59 GMT+01:00 Evgeniy L e...@mirantis.com:

 Hi,

 Since fuel plugins are going to be moved [1] from fuel-plugins repository
 [2],
 the only project which will be there is fuel plugin builder and plugins
 examples
 which are related to fuel plugin builder testing.

 Currently fuel plugin builder has its own release cycle, but we don't have
 tags
 for these versions, the suggestion is after plugins are removed from the
 repository,
 we should push tags for previous fpb releases.

 Tags can help with another problem, currently I manually publish new
 version
 on pypi, we can automatically build and publish new version after tag is
 pushed.

 What do you think about that?

 Thanks,

 [1] https://review.openstack.org/#/c/151143/
 [2] https://github.com/stackforge/fuel-plugins
 [3]
 https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md

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


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

Re: [openstack-dev] [Fuel] fuel-client and Nailgun API

[Sebastian Kalinowski]

Hi,

2015-02-09 13:57 GMT+01:00 Nikolay Markov nmar...@mirantis.com:

 They say, there is some kind of holywar around the topic on if
 fuel-client tests should rely on working Nailgun API without mocking
 it.


Could you point us where was such hollywar was, so we could get some
background on the topic?

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

Re: [openstack-dev] [Fuel] Proposal for nominating people to python-fuelclient-core

[Sebastian Kalinowski]

+1

2015-01-26 11:33 GMT+01:00 Roman Prykhodchenko m...@romcheg.me:

 Hi Guys,

 According to our previous thread [1] and the decision made there I’d like
 to initiate separation of the original fuel-core group.

 At the first step propose the following python guys from the original
 fuel-core group to be nominated to python-fuelclient-core group.

 Aleksey Kasatkin — akasatkin
 Dmitry Pyzhov — dpyzhov
 Evgeniy L — evgeniyl___
 Igor Kalnitsky — ikalnitsky

 The decision will be made basing on lazy consensus. Since I was in
 python-fuelclient-core group only for technical reasons, I will remove
 myself from there as soon as it’s populated.
 All following nominations and de-nominations will be done according to the
 approved core-dev process [2].


 References:

 1.
 http://lists.openstack.org/pipermail/openstack-dev/2015-January/055038.html
 2. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess


 - 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

Re: [openstack-dev] [Fuel][Agent] Moving Fuel Agent to a separate repo

[Sebastian Kalinowski]

+1 I'm all for separating it.

2015-01-26 17:52 GMT+01:00 Alexander Gordeev agord...@mirantis.com:

 Hello Vladimir,

 totally +1 for separating Fuel Agent out of fuel-web.

 what will happen with fuel_agent_ci ?

 On Mon, Jan 26, 2015 at 7:42 PM, Vladimir Kozhukalov
 vkozhuka...@mirantis.com wrote:
  Fuelers,
 
  As most of you might know we have a bunch of projects inside fuel-web
 repo
  which are not directly related to Fuel Web application. Some of them are
  tested together and it seemed we could end up with a set of
 incompatibility
  issues if we separated them and stopped tracking their versions on the
 git
  level (instead of release level).
 
  Recent activities about separating Fuel Client from Nailgun (api) make me
  think we are mature enough to move all other not related project out of
  fuel-web repo and bring them together not earlier than on the stage of
  system/functional testing.
 
  Next step would be moving out Fuel Agent project. The reason is that it
 is
  independent and potentially could be used even out of Fuel because its
 data
  parsing mechanism is implemented so as to be agnostic to the data format.
  Some people could be potentially interested in using it independently
 with
  their own data format. It is tested together with other Fuel components
  during system testing only.
 
 
 
  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

__
OpenStack Development Mailing 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][Nailgun] Web framework

[Sebastian Kalinowski]

Hello all,

What is the current situation with choosing web framework? Was there any
progress in the topic? I would like to avoid forgetting about it.

2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com:

 Feel free to ask any questions you have in #pecanpy on IRC;  I can answer
 a lot
 more quickly than researching docs, and if you have a special need, I can
 usually accommodate with changes to Pecan (I've done so with several
 OpenStack
 projects in the past).
 On 12/08/14 02:10 PM, Nikolay Markov wrote:
   Yes, and it's been 4 days since last message in this thread and no
   objections, so it seems
   that Pecan in now our framework-of-choice for Nailgun and future
   apps/projects.
 
  We still need some research to do about technical issues and how easy
  we can move to Pecan. Thanks to Ryan, we now have multiple links to
  solutions and docs on discussed issues. I guess we'll dedicate some
  engineer(s) responsible for doing such a research and then make all
  our decisions on subject.
 
  On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski
  skalinow...@mirantis.com wrote:
   2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:
  
   Ok, guys,
  
   It became obvious that most of us either vote for Pecan or abstain
 from
   voting.
  
  
   Yes, and it's been 4 days since last message in this thread and no
   objections, so it seems
   that Pecan in now our framework-of-choice for Nailgun and future
   apps/projects.
  
  
  
   So I propose to stop fighting this battle (Flask vs Pecan) and start
   thinking about moving to Pecan. You know, there are many questions
   that need to be discussed (such as 'should we change API version' or
   'should be it done iteratively or as one patchset').
  
  
   IMHO small, iterative changes are rather obvious.
   For other questions maybe we need (draft of ) a blueprint and a
 separate
   mail thread?
  
  
  
   - Igor
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 
 
  --
  Best regards,
  Nick Markov
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Ryan Petrello
 Senior Developer, DreamHost
 ryan.petre...@dreamhost.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Sebastian Kalinowski]

2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Ok, guys,

 It became obvious that most of us either vote for Pecan or abstain from
 voting.


Yes, and it's been 4 days since last message in this thread and no
objections, so it seems
that Pecan in now our framework-of-choice for Nailgun and future
apps/projects.



 So I propose to stop fighting this battle (Flask vs Pecan) and start
 thinking about moving to Pecan. You know, there are many questions
 that need to be discussed (such as 'should we change API version' or
 'should be it done iteratively or as one patchset').


IMHO small, iterative changes are rather obvious.
For other questions maybe we need (draft of ) a blueprint and a separate
mail thread?



 - Igor

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Sebastian Kalinowski]

2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:

  I don't like that Flask uses a global request object [3].

 Przemyslaw, actually Pecan does use global objects too. BTW, what's
 wrong with global objects? They are thread-safe in both Pecan and
 Flask.


To be fair, Pecan could also pass request and response explicit to method
[1]

[1] http://pecan.readthedocs.org/en/latest/contextlocals.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Sebastian Kalinowski]

I never used Flask and Pecan personally so I can only rely from what I saw
in this thread and in both projects docs.
I don't have strong opinion, just want to share some thoughts.

I think that as a part of OpenStack community we should stick with Pecan
and because of the same reason
we can have a bigger impact how future versions of Pecan will look.

If we will choose Flask I see is that we not only need to choose a
framework, but also decide which
extension will be used to provide REST support (I do not like that we just
assume flask-restful will be used).

To be honest right now I'm more convinced that we should choose Pecan.


2014-12-03 14:22 GMT+01:00 Nikolay Markov nmar...@mirantis.com:

 Dear colleagues,

 We surely may take into account the beauty of the code in both cases
 (as for me, Pecan loses here, too) and argue about global objects and
 stuff, but I'm trying to look at amount of men and time we need to
 move to one of these frameworks.


Agree that we should look on the man-hours for implementation, but I think
that it is as
important as all the small things like global object etc. since they could
make future development
painful or pleasant.


 I wouldn't say our API is badly designed, nevertheless Pecan still has
 a lot of issues needed to be fixed by hand. We don't want to spend
 much time to this task, because it is mostly the matter of convenience
 and simplicity for developers, it changes nothing in features or
 customer-facing behavior.

 And if we take in account the amount of hours we need to move, based
 on my experience Flask definitely wins here.


Cannot we reuse the PoC ([1]) with Pecan that was created? There was a lot
of work put into that piece of code.

[1] https://review.openstack.org/#/c/99069/6
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Nailgun] Web framework

[Sebastian Kalinowski]

Hi all,

Some time ago we had a discussion about moving Nailgun to new web framework
[1].

There was comparison [2] of two possible options: Pecan [3] and Flask [4].
We came to conclusion that we need to move Nailgun on some alive web
framework
instead of web.py [5] (some of the reasons: [6]) but there was no clear
agreement
on what framework (there were strong voices for Flask).

I would like to bring this topic up again so we could discuss with broader
audience and
make final decision what will be our next web framework.

I think that we should also consider to make that framework our weapon of
choice (or so
called standard) when creating new web services in Fuel.

Best,
Sebastian


[1] https://lists.launchpad.net/fuel-dev/msg01397.html
[2]
https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
[3] http://www.pecanpy.org/
[4] http://flask.pocoo.org/
[5] http://webpy.org/
[6] https://lists.launchpad.net/fuel-dev/msg01501.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Re: SSL in Fuel.

[Sebastian Kalinowski]

I have some topics for [1] that I want to discuss:

1) Should we allow users to turn SSL on/off for Fuel master?
I think we should since some users may don't care about SSL and
enabling it will just make them unhappy (like warnings in browsers,
expiring certs).

2) Will we allow users (in first iteration) to use their own certs?
If we will (which I think we should and other people aslo seems to
share this point of view), we have some options for that:
 A) Add informations to docs where to upload your own certificate on
master node (no UI) - less work, but requires a little more action from
users
 B) Simple form in UI where user will be able to paste his certs -
little bit more work, user friendly
Are there any reasons we shouldn't do that?

3) How we will manage cert expiration?
Stanislaw proposed that we should show user a notification that will
tell user about cert expiration. We could check that in cron job.
I think that we should also allow user to generate a new cert in Fuel
if the old one will expire.

I'll also remove part about adding cert validation in fuel agent since it
would require a significant amount of work and it's not essential for first
iteration.

Best,
Sebastian


[1] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Re: SSL in Fuel.

[Sebastian Kalinowski]

On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:

 So I think that we need to start on [3]. As this is required for OSt
 public
 endpoint SSL and also for Fuel SSL it can be quicker to make a first stage
 where a self-signed certificate is managed from nailgun and a second stage
 with the docker CA...
 So, yes, I think that it is good idea, cause it will be good base for [2]
 and [3]

 [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
 [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints
 [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints


+1

I totally agree that we should start with [1] first and later focus on [2]
and [3].

I'll also update [2] to adjust it to the plan you proposed.


Best,
Sebastian
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] SSL in Fuel

[Sebastian Kalinowski]

Hi all,

As next step for improving Fuel security we are introducing SSL for both
Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed
certificates generated by Fuel.
It also required to allow users to use their own certs to secure their
deployments
(two blueprints that touch that part are [3] and [4])

We would like to start a discussion to see what opinions (and maybe ideas)
you
have for that feature.

Best,
Sebastian

[1] https://review.openstack.org/#/c/119330
[2] https://review.openstack.org/#/c/102273
[3] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
[4] https://blueprints.launchpad.net/fuel/+spec/manage-ssl-certificate
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev