[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

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

[Sebastian Kalinowski]

On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin 
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

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

[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][Nailgun] Web framework

[Sebastian Kalinowski]

2014-12-03 13:47 GMT+01:00 Igor Kalnitsky :

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

> 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

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

[Sebastian Kalinowski]

2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :

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

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 :

> 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
> >  wrote:
> > > 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :
> > >>
> > >> 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] Proposal for nominating people to python-fuelclient-core

[Sebastian Kalinowski]

+1

2015-01-26 11:33 GMT+01:00 Roman Prykhodchenko :

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

> 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
>  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][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] 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.
> >>  - In order to guarantee that a stable API is not changed, Jenkins jobs

[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] 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 :

> 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  wrote:
>>
>>>
>>>
>>>  On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn <
>>> mmoses...@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 :

> +1
>
> On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin 
> wrote:
>
>> +1
>>
>> On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov 
>> wrote:
>>
>>> +1
>>>
>>> On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov 
>>> 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 :

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

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

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 :

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

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 :

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

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

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

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 :

> 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 
> 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 
>> 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 :
>>>
>>>> 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  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
>>>> >  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 
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> The best option is to add new functionality to fuel2 only, but I
>>>> >>&g

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sebastian Kalinowski]

2015-07-30 14:50 GMT+02:00 Evgeniy L :

> 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 
> 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%2FPlugins&diff=78677&oldid=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'

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 :

> FYI: There is 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 :
>
>> Hi,
>>
>> +1 to 2nd solution too.
>>
>> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  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] 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 :

> Roman,
>
> well done! ;)
>
> Best regards,
> Boris Pavlovic
>
> On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko 
> 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] 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 :

> 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 
> написав(ла):
>
> 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 :
>
>> Roman,
>>
>> well done! ;)
>>
>> Best regards,
>> Boris Pavlovic
>>
>> On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko 
>> 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][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] 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&release=all&project_type=all&module=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] 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] 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][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Sebastian Kalinowski]

+1

2015-06-30 10:38 GMT+02:00 Evgeniy L :

> +1
>
> On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky 
> wrote:
>
>> +1. Alex's doing a great job!
>>
>> On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
>>  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] fuel-client and Nailgun API

[Sebastian Kalinowski]

Hi,

2015-02-09 13:57 GMT+01:00 Nikolay Markov :

> 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][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 :

> 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

[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] 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 :

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

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 :

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

> 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

[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] Nominate Julia Aranovich for fuel-web core

[Sebastian Kalinowski]

+1

2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski :

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