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

[Igor Kalnitsky]

Sorry for being late on this. I've added Ilya to fuel-plugins-core
group. Congrats, Ilya!

On Sun, Sep 11, 2016 at 9:35 PM, Alexey Shtokolov
 wrote:
> My strong +1
>
> Ilya made and keeps making a great contribution to the development of Fuel
> Plugins Framework
> on both sides (nailgun and plugins) especially during the Newton release
> cycle!
>
> ---
> WBR, Alexey Shtokolov
> Fuel Development Lead
>
> On Sun, Sep 11, 2016 at 5:41 PM, Aleksey Kasatkin 
> wrote:
>>
>> +1
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Sat, Sep 10, 2016 at 4:49 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

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

[Igor Kalnitsky]

Hey Fuelers,

I'd like to nominate Ilya for joining fuel-plugins-core group. He's a
top contributor by both reviews [1] and commits [2] over the past
release cycle. Fuel cores, please share your votes.

- Igor

[1] http://stackalytics.com/?module=fuel-plugins=newton=marks
[2] http://stackalytics.com/?module=fuel-plugins=newton=commits

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

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Igor Kalnitsky]

-1 for the proposal. I see no problems to add guys who're familiar
with various sub-projects to multiple core groups.

On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
> +1 to Lukasz.
> -1 to the proposal, we had it this way for a quite some time, and it was not
> good for the project (as Lukasz pointed out), why should a person who merges
> the code to the library have an access to merge the code to Nailgun/Astute
> without proper expertise. Those are different areas which require different
> skills.
>
> Thanks,
>
> On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles  wrote:
>>
>> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov 
>> wrote:
>> > +1
>> > This is a good proposal, I also think we should have single fuel-core
>> > group
>> > for all repos. In real life core reviewers won't set +2 or merge to
>> > repos
>> > with which they are not familiar with.
>> Actually one of the reasons why core groups were split was that it
>> happened a few times :)
>>
>> >
>> > Regards,
>> > Andrey Maximov
>> >
>> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
>> >  wrote:
>> >>
>> >> Dear colleagues,
>> >>
>> >> I'd like to suggest to use common fuel-core group for all Fuel projects
>> >> instead of having separate independent 'by-project' core groups like
>> >> 'fuel-astute-core' or 'fuel-agent-core'.
>> >>
>> >> Pros:
>> >> 1) It will be easier to access core members (timezone and holiday
>> >> tolerance)
>> >> 2) It will be easier to manage single core group (promote new members,
>> >> remove not active members)
>> >>
>> >> Cons:
>> >> 1) Less of flexibility. Permissions will be the same for all core
>> >> reviewers in all Fuel projects.
>> >>
>> >> What do you think?
>> >>
>> >> Vladimir Kozhukalov
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://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
>> >
>>
>>
>>
>> --
>> Łukasz Oleś
>>
>> __
>> OpenStack Development Mailing 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] pydotplus (taskflow) vs pydot-ng (fuel)

[Igor Kalnitsky]

Hi Thomas,

If I'm not mistaken, pydot-ng [1] has been made by ex-fueler in order
to overcome some limitations of pydot ( and do not change much. If
pydotplus is alive project and do the same thing, I vote for using it
in Fuel.

Thanks,
Igor


[1]: https://pypi.io/project/pydot-ng/

On Tue, Aug 2, 2016 at 4:44 PM, Thomas Goirand  wrote:
> Hi,
>
> Fuel uses pydot-ng, and (at least) taskflow uses pydotplus. I believe
> both aren't using pydot because that's dead upstream.
>
> Could we have a bit of consistency here, and have one or the other
> component to switch, so we could get rid of one more package that does
> the same thing in downstream distros?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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 Vitalii Kulanov for python-fuelclient-core

[Igor Kalnitsky]

Vitaly's doing a great job. +2, no doubts!

On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich
 wrote:
> A huge +1
>
> On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko  wrote:
>>
>> +1
>>
>> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko 
>> wrote:
>>>
>>> Hi Fuelers,
>>>
>>> Vitalii has been providing great code reviews and patches for some time.
>>> His recent commitment to help consolidating both old and new fuel clients
>>> and his bug-squashing activities show his willingness to step up and take
>>> responsibilities within the community. He can often be found in #fuel as
>>> vkulanov.
>>>
>>>
>>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
>>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t
>>>
>>>
>>> P. S. Sorry for sending this email twice — I realized I didn’t put a
>>> topic to the subject.
>>>
>>>
>>> - romcheg
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://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] [all][Python 3.4-3.5] Async python clients

[Igor Kalnitsky]

Denis Makagon wrote:
> I'm using event loop with uvloop policy, so i must stay non-blocked
> within main thread and don't mess up with GIL by instantiating new thread.

You won't be blocked or "messed up" with GIL as long as new thread is
I/O bound. Background thread is a good solution in such cases, and
it's used by many libraries under the hood (for instance, pymongo).

- Igor

On Mon, Jul 4, 2016 at 5:09 PM, Denis Makogon  wrote:
>
>
> 2016-07-04 16:47 GMT+03:00 Roman Podoliaka :
>>
>> That's exactly what https://github.com/koder-ua/os_api is for: it
>> polls status changes in a separate thread and then updates the
>> futures, so that you can wait on multiple futures at once.
>>
>
> This is what i exactly want to avoid - new thread. I'm using event loop with
> uvloop policy, so i must stay non-blocked within main thread and don't mess
> up with GIL by instantiating new thread. With coroutines concept from
> asyncio i can do non-blocking operations relying on EPOLL under the hood.
>
> Kind regards,
> Denys Makogon
>
>>
>> On Mon, Jul 4, 2016 at 2:19 PM, Denis Makogon 
>> wrote:
>> >
>> >
>> > 2016-07-04 13:22 GMT+03:00 Roman Podoliaka :
>> >>
>> >> Denis,
>> >>
>> >> >  Major problem
>> >> > appears when you trying to provision resource that requires to have
>> >> > some
>> >> > time to reach ACTIVE/COMPLETED state (like, nova instance, stack,
>> >> > trove
>> >> > database, etc.) and you have to use polling for status changes and in
>> >> > general polling requires to send HTTP requests within specific time
>> >> > frame
>> >> > defined by number of polling retries and delays between them (almost
>> >> > all
>> >> > PaaS solutions in OpenStack are doing it that might be the case of
>> >> > distributed backend services, but not for async frameworks).
>> >>
>> >> How would an asynchronous client help you avoid polling here? You'd
>> >> need some sort of a streaming API producing events on the server side.
>> >>
>> >
>> > No, it would not help me to get rid of polling, but using async requests
>> > will allow to proceed with next independent async tasks while awaiting
>> > result on async HTTP request.
>> >
>> >>
>> >> If you are simply looking for a better API around polling in OS
>> >> clients, take a look at https://github.com/koder-ua/os_api , which is
>> >> based on futures (be aware that HTTP requests are still *synchronous*
>> >> under the hood).
>> >>
>> >> Thanks,
>> >> Roman
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [Fuel][Plugins] Fuel Plugin Builder 4.1.0 released!

[Igor Kalnitsky]

Hey Fuelers,

I'm glad to announce that FPB (fuel plugin builder) v4.1.0 has been
released on PyPI [1].

It's mostly a maintenance release without new features. Here's a
changelog highlights:

* `tasks.yaml` is now optional for package version "4.0.0" [2]
* Fuel Mitaka (9.0) is supported by default in package version "4.0.0" [3]
* Use more reliable way to check for `fpm` Ruby GEM [4]
* Add ability for role to conflict with all roles by using `*` sign [5]
* Do not execute `uninstall.sh` on plugin upgrade [6]
* Add possiblity to use generators in `environment_config.yaml` [7]
* Don't put any code to PREUN section if `uninstall.sh` doesn't exist
or empty [8]
* Allow a user to specify any arbitrary string as role name for cross-deps [9]
* Add deployment tasks v2.1 validation support [10]

- Igor


[1]: https://pypi.io/project/fuel-plugin-builder/4.1.0/
[2]: https://bugs.launchpad.net/fuel/+bug/1552248
[3]: https://bugs.launchpad.net/fuel/+bug/1549276
[4]: https://bugs.launchpad.net/fuel/+bug/1561069
[5]: https://bugs.launchpad.net/fuel/+bug/1547590
[6]: https://bugs.launchpad.net/fuel/+bug/1564123
[7]: https://bugs.launchpad.net/fuel/+bug/1557562
[8]: https://bugs.launchpad.net/fuel/+bug/1574478
[9]: https://bugs.launchpad.net/fuel/+bug/1557997
[10]: https://bugs.launchpad.net/fuel/+bug/1590389

__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Igor Kalnitsky]

> On Jun 27, 2016, at 16:57, Andrey Kurilin  wrote:
> 
> Rally consists of two main components: Rally Task and Rally Verification. 
> They are totally separated.
> Task component is fully pluggable and you can run there whatever you want in 
> whatever you want way.

Andrey, thanks for explanation!

I wonder what are the benefits of using Rally then? We can run whatever we want 
by means of MCollective or Ansible. Is there something that could help us? I 
don't know, maybe some dashboard integration with per test results or running 
by tests by tag?

Besides, we don't run some tests if deployed configuration doesn't assume it. 
For instance, no need to run ceilometer test (and even show one) if we deploy 
env without it. Is it possible to achieve it with Rally?

Thanks,
Igor
__
OpenStack Development Mailing 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] Replace OSTF with Rally

[Igor Kalnitsky]

> On Jun 27, 2016, at 16:23, Alex Schultz  wrote:
> 
> I thought Rally was more for benchmarking.  Wouldn't Tempest make more sense? 
>  

According to Rally wiki page [1], it seems they have a verification layer 
(Tempest so far). Hm, I wonder does it mean we will need to rewrite our 
scenarios for Tempest? 

- igor


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

Re: [openstack-dev] [Fuel] Merge IRC channels

[Igor Kalnitsky]

> On Jun 25, 2016, at 12:39, Roman Prykhodchenko  wrote:
> 
> Since Fuel is a part of OpenStack now, should we rename #fuel to 
> #openstack-fuel?
> 
> - romcheg

+1. Let's be consistent in naming convention with most Big Tent projects.

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

Re: [openstack-dev] [Fuel] Deprecation of fuel-mirror tool

[Igor Kalnitsky]

Vladimir,

Thanks for driving this! What about fuel-mirror itself? Does it mean it's 
deprecated? If so, what will happen to perestroika scripts inside it [1]? It 
seems strange that fuel-mirror contains them.

Thanks,
Igor

[1] https://github.com/openstack/fuel-mirror/tree/master/perestroika


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


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

Re: [openstack-dev] [fuel] discovery and deploy a compute node automatically

[Igor Kalnitsky]

> On May 25, 2016, at 13:53, jason  wrote:
> 
> Thanks, and yes you got my point, my "automatically ", means after a new node 
> has been discovered , the deployement process starts automatically. Cron may 
> help, but what if I need more info to check if that new discovered node 
> deserves to be a compute node or not? Can the cron script  get more 
> characteristics info about the node? For example , "if the new node has right 
> amount of nic interfaces, right setting of NUMA etc., then make it a compute 
> node with the same configuration as others with the same characteristics".

Yep. Cron is a way to run periodically some script. Alternatively, as Alex 
mentioned, you can write a daemon.

In order to make some checks, you can use either CLI or RESTful API. It's 
really easy to interact with API using Python with requests [1] library.


[1]: http://docs.python-requests.org/en/master/
__
OpenStack Development Mailing 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] discovery and deploy a compute node automatically

[Igor Kalnitsky]

Hey Jason,

What do you mean by "automatically"?

You need to assign "compute" role on that discovered node, and hit "Deploy 
Changes" button. If you really want to deploy any new discovered node 
automatically, I think you can create some automation script and put it under 
cron.

Hope it helps,
Igor

> On May 25, 2016, at 12:33, jason  wrote:
> 
> Hi All,
> 
> Is there any way for fuel to deploy a newly discovered node as a compute node 
> automatically? I followed the openstack doc for fuel but did not get any 
> answer.
> 
> __
> OpenStack Development Mailing 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] release version numbers: let's use semvers

[Igor Kalnitsky]

Hey Zigo,

In Python community there's a PEP-440 [1] that defines a versioning scheme. The 
thing you should know is, the PEP __is not__ compatible with semver, and it's 
totally fine to have two components version.

So I don't think we should force version changes from two-components to 
three-components scheme, since it won't be compatible with semver anyway.

Thanks,
Igor

[1]: https://www.python.org/dev/peps/pep-0440/


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

Re: [openstack-dev] [fuel] Unrelated changes in patches

[Igor Kalnitsky]

Dmitry Guryanov wrote:
> It's often not so easy to decide, if you should include some unrelated
> changes to your patch, like fixing spaces, renaming variables or
> something else, which don't change logic.

I'd say it depends. If, for example, variable name is used inside one
function - it's ok to rename it within a patch. On the other hand, if
this variable is used across the code and it requires to change it in
few places - I'd prefer to do not do it within the patch. Any
unrelated change complicates review (if we're taking about thorough
review).

The things go worse when patch authors tries to implement two business
changes in one patch. In that case, it's really hard to distinguish
those both changes one from another in order to understand what's
going on.

So generally I'd prefer to see all unrelated changes in separate
patches. It's not necessary to create a bug for them, it's ok to
submit them with detailed commit message why this should be done.

Dmitry Guryanov wrote:
> On the one hand you see something's wrong with the code and you'd like
> to fix it, on the other hand reviewers can vote of -1 and you'll have
> to fix you patch and upload it again and this is very annoying.

You can fix it in first patch, and make *business* changes in the second one.

Dmitry Guryanov wrote:
> You can also create separate review for such changes, but it will
> require additional effort from you and reviewers.

As reviewer I can say: I'm spending more time trying to figure out
what's going on in patch that changes two (or even more) unrelated
things, than I'd spend if I review those changes in independent
patches.

On Mon, Apr 4, 2016 at 3:46 PM, Dmitry Guryanov  wrote:
> Hello, colleagues!
>
> It's often not so easy to decide, if you should include some unrelated
> changes to your patch, like fixing spaces, renaming variables or something
> else, which don't change logic. On the one hand you see something's wrong
> with the code and you'd like to fix it, on the other hand reviewers can vote
> of -1 and you'll have to fix you patch and upload it again and this is very
> annoying. You can also create separate review for such changes, but it will
> require additional effort from you and reviewers.
>
> If you are a reviewer, and you've noted unrelated changes you may hesitate,
> if you should ask an author to remove them and upload new version of the
> patch or not. Also such extra changes may confuse you sometimes.
>
> So I suggest creating separate patches for unrelated changes if they add new
> chucks to patch. And I'd like to ask authors to clearly state in the subject
> of a commit message, that this patch just fixes formatting. And reviewers
> shouldn't check such patches too severely, so that they'll get into repo as
> soon as possible.
>
> What do you think?
>
>
> --
> Dmitry Guryanov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Igor Kalnitsky]

Neil Jerram wrote:
> But isn't Ansible also over-complicated for just running commands over SSH?

It may be not so "simple" to ignore that. Ansible has a lot of modules
which might be very helpful. For instance, Shotgun makes a database
dump and there're Ansible modules with the same functionality [1].

Don't think I advocate Ansible as a replacement. My point is, let's
think about reusing ready solutions. :)

- igor


[1]: http://docs.ansible.com/ansible/list_of_database_modules.html

On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram <neil.jer...@metaswitch.com> wrote:
>
> FWIW, as a naive bystander:
>
> On 30/03/16 11:06, Igor Kalnitsky wrote:
>> Hey Fuelers,
>>
>> I know that you probably wouldn't like to hear that, but in my opinion
>> Fuel has to stop using Shotgun. It's nothing more but a command runner
>> over SSH. Besides, it has well known issues such as retrieving remote
>> directories with broken symlinks inside.
>
> It makes sense to me that a command runner over SSH might not need to be
> a whole Fuel-specific component.
>
>> So I propose to find a modern alternative and reuse it. If we stop
>> supporting Shotgun, we can spend extra time to focus on more important
>> things.
>>
>> As an example, we can consider to use Ansible. It should not be tricky
>> to generate Ansible playbook instead of generating Shotgun one.
>> Ansible is a  well known tool for devops and cloud operators, and they
>> we will only benefit if we provide possibility to extend diagnostic
>> recipes in usual (for them) way. What do you think?
>
> But isn't Ansible also over-complicated for just running commands over SSH?
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Igor Kalnitsky]

Hey Fuelers,

I know that you probably wouldn't like to hear that, but in my opinion
Fuel has to stop using Shotgun. It's nothing more but a command runner
over SSH. Besides, it has well known issues such as retrieving remote
directories with broken symlinks inside.

So I propose to find a modern alternative and reuse it. If we stop
supporting Shotgun, we can spend extra time to focus on more important
things.

As an example, we can consider to use Ansible. It should not be tricky
to generate Ansible playbook instead of generating Shotgun one.
Ansible is a  well known tool for devops and cloud operators, and they
we will only benefit if we provide possibility to extend diagnostic
recipes in usual (for them) way. What do you think?

Thanks,
- Igor

On Tue, Mar 29, 2016 at 7:52 PM, Roman Prykhodchenko  wrote:
> Please, propose your options here then:
> https://etherpad.openstack.org/p/shotgun-rename
>
> 29 бер. 2016 р. о 18:15 Jay Pipes  написав(ла):
>
> On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote:
>
> Should we propose options and then arrange a poll?
>
>
> Yup, ++ :)
>
> 29 бер. 2016 р. о 16:40 Neil Jerram 
> написав(ла):
>
> On 29/03/16 15:17, Jay Pipes wrote:
>
> Hi!
>
> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
> something different? I know in the past that Anita and a few others
> thought the name was not something we should really be encouraging in
> the OpenStack ecosystem.
>
> Just something to consider since it's being decoupled anyway and may be
> a good opportunity to rename at that point...
>
> Best,
> -jay
>
>
> +1
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Igor Kalnitsky]

Hey Roman,

Thank you for investigation. However, I think that changing
'deadlock_timeout' won't help us. According to PostgreSQL
documentation [1], this option sets how frequently to check if there
is a deadlock condition. So it won't fix deadlocks themselves.

Thus I see no reason why we should change that option and wait more
time before raising the deadlock exception.

- Igor

[1]: http://www.postgresql.org/docs/9.4/static/runtime-config-locks.html

On Mon, Mar 21, 2016 at 6:39 PM, Roman Prykhodchenko  wrote:
> Folks,
>
> We have been analyzing a bunch of random failures in Fuel tests and 
> encountered several ones caused by detector raising errors occasionally [1]. 
> After attempts to reproduce the same behavior have failed we’ve decided to 
> run the same test suit on overloaded nodes. Those test-runs allowed us to 
> catch the same behavior we’ve seen on CI slaves. After analyzing both 
> PostgreSQL logs and Nailgun’s code we’ve found no reasons for those deadlocks 
> to occur.
>
> Thinking about the facts mentioned we came up with the idea that those random 
> deadlocks occur in cases when CI slaves are overloaded by other jobs and 
> transactions start hitting deadlock timeout. Thus I propose to change 
> PostgreSQL’s deadlock_timeout value from the default one to 3-5 seconds. That 
> will slow down tests, if they run on an overloaded CI slave but will help to 
> avoid random and false-positive deadlock warnings.
>
>
> References:
>
> 1. https://bugs.launchpad.net/fuel/+bug/1556070
>
>
> - romcheg
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][Nailgun] Random failures in unit tests

[Igor Kalnitsky]

Hey Fuelers,

As you might know recently we encounter a lot of random test failures
on CI, and they are still there (likely with a bit less probability).
A nature of that random failures is actually not a random, they are
happened because of so called fake threads.

Fake threads, actually, ain't fake at all. They are native OS threads
that are designed to emulate Astute behaviour (i.e. catch RPC call and
respond with appropriate message). Since they are native threads and
we use SQLAlchemy's scoped_session, fake threads are using a separate
database session, hence - transaction. That leads to the following
issues:

* Races. We don't know when threads are switched, therefore, we don't
know what's committed and what's not. Some Nailgun tests sends
something via RPC (catched by fake threads) and immediately checks
something. The issue is, we can't guarantee fake threads is already
committed produced result. That could be avoided by waiting for
'ready' status of created nailgun task, however, it's better to simply
do not use fake threads in that case and simply call appropriate
Nailgun receiver's method directly in the test.

* Deadlocks. It's incredibly hard to ensure the same order of database
locks in test + business code on one hand and fake thread code on
other hand. That's why we can (and we do) encounter deadlocks on CI,
when test case waits for lock acquired by fake thread, and fake thread
waits for lock acquired by test case.

Fake threads are became a bottleneck of landing patches to master in
time, and we can't ignore it anymore. We have ~190 tests that use fake
threads, and fixing them all at once is a boring routine. So I kindly
ask Nailgun contrubitors to fix them as soon as we face them. Let's
file a bug on each file in CI, and quicly prepare a separate patch
that removes fake thread from failed test.

Thanks in advance,
Igor

__
OpenStack Development Mailing 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] Random failures in unit tests

[Igor Kalnitsky]

Hey Vitaly,

Thanks for your feedback, it's an important notice. However, I think
you didn't get the problem quite well so let me explain it again.

You see, Nailgun unit tests are failing due to races or deadlocks
happened by two transactions: test transaction and fake thread
transaction, and we must face it and fix it. This problem has nothing
to do with the problem you're encountering in UI tests. Besides,
removing them from test doesn't mean removing them from Nailgun code
base.

So your problem must be addressed, but it's kinda another story.

Thanks,
Igor

On Wed, Mar 16, 2016 at 4:21 PM, Vitaly Kramskikh
<vkramsk...@mirantis.com> wrote:
> Igor,
>
> We have UI and CLI integration tests which use fake mode of Nailgun, and we
> can't avoid using fake threads for them. So I think we need to think how to
> fix fake threads instead. There is a critical bug which is the main reason
> of randomly failing UI tests. To fix it, we need to fix fake threads
> behaviour.
>
> 2016-03-16 17:06 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>:
>>
>> Hey Fuelers,
>>
>> As you might know recently we encounter a lot of random test failures
>> on CI, and they are still there (likely with a bit less probability).
>> A nature of that random failures is actually not a random, they are
>> happened because of so called fake threads.
>>
>> Fake threads, actually, ain't fake at all. They are native OS threads
>> that are designed to emulate Astute behaviour (i.e. catch RPC call and
>> respond with appropriate message). Since they are native threads and
>> we use SQLAlchemy's scoped_session, fake threads are using a separate
>> database session, hence - transaction. That leads to the following
>> issues:
>>
>> * Races. We don't know when threads are switched, therefore, we don't
>> know what's committed and what's not. Some Nailgun tests sends
>> something via RPC (catched by fake threads) and immediately checks
>> something. The issue is, we can't guarantee fake threads is already
>> committed produced result. That could be avoided by waiting for
>> 'ready' status of created nailgun task, however, it's better to simply
>> do not use fake threads in that case and simply call appropriate
>> Nailgun receiver's method directly in the test.
>>
>> * Deadlocks. It's incredibly hard to ensure the same order of database
>> locks in test + business code on one hand and fake thread code on
>> other hand. That's why we can (and we do) encounter deadlocks on CI,
>> when test case waits for lock acquired by fake thread, and fake thread
>> waits for lock acquired by test case.
>>
>> Fake threads are became a bottleneck of landing patches to master in
>> time, and we can't ignore it anymore. We have ~190 tests that use fake
>> threads, and fixing them all at once is a boring routine. So I kindly
>> ask Nailgun contrubitors to fix them as soon as we face them. Let's
>> file a bug on each file in CI, and quicly prepare a separate patch
>> that removes fake thread from failed test.
>>
>> Thanks in advance,
>> Igor
>>
>> __
>> OpenStack Development Mailing 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] [FFE] Unlock Settings Tab

[Igor Kalnitsky]

Hey Dmitry,

I confirm that we agreed on feature design, and you can proceed with
granting exception.

,- Igor

On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
<ashtoko...@mirantis.com> wrote:
> Hi Dmitry,
>
> We've reached the design consensus with Igor today. Could you please remove
> the conditional status of the FFE request?
> As agreed: the merge deadline is March 24.
>
> --
> WBR, Alexey Shtokolov
>
> 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <dborodae...@mirantis.com>:
>>
>> Granted. Design consensus deadline for the task history part of this
>> feature is extended to March 11. This does not change the merge deadline
>> for other parts of this feature, which is still March 24.
>>
>> --
>> Dmitry Borodaenko
>>
>>
>> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>> > Dmitry,
>> >
>> > We are really close to have the consensus, but we need one more meeting
>> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>> > decision.
>> > All patches [0] are on review. The meeting is scheduled for tomorrow
>> > (03/11
>> > 1:30pm CET).
>> > Could you please grant us one more day for it?
>> >
>> > [0] -
>> > https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>> >
>> > --
>> > WBR, Alexey Shtokolov
>> >
>> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <dborodae...@mirantis.com>:
>> >
>> > > Granted, merge deadline March 24, task history part of the feature is
>> > > to
>> > > be excluded from this exception grant unless a consensus is reached by
>> > > March 10.
>> > >
>> > > Relevant part of the meeting log starts at:
>> > >
>> > >
>> > > http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>> > >
>> > > --
>> > > Dmitry Borodaenko
>> > >
>> > >
>> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
>> > > > Oh, so there is a spec. I was worried that this patch has
>> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
>> > > > thought
>> > > > there is no spec for it. So the commit message should be updated to
>> > > > avoid
>> > > > such confusion.
>> > > >
>> > > > It's really good I've seen this spec. There are plans to overhaul UI
>> > > > data
>> > > > format description which we use for cluster and node settings to
>> > > > solve
>> > > some
>> > > > issues and implement long-awaited features like nested structures,
>> > > > so we
>> > > > might also want to deprecate our expression language and also switch
>> > > > to
>> > > > YAQL (and thus port YAQL to JS).
>> > > >
>> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <vkuk...@mirantis.com>:
>> > > >
>> > > > > Vitaly
>> > > > >
>> > > > > Thanks for bringing this up. Actually the spec has been on review
>> > > > > for
>> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
>> > > > > Essentially,
>> > > > > this is not introducing new DSL but replacing the existing one
>> > > > > with
>> > > more
>> > > > > powerful extendable language which is being actively developed
>> > > > > within
>> > > > > OpenStack and is already a part of other projects (Murano,
>> > > > > Mistral),
>> > > which
>> > > > > has much more contributors, can return not only boolean but any
>> > > arbitrary
>> > > > > collections. So it means that we want to deprecate current
>> > > > > Expression
>> > > > > language that you wrote and replace it with YAQL due to those
>> > > > > reasons.
>> > > You
>> > > > > are not going to extend this Expression-based language in 3 weeks
>> > > > > up to
>> > > > > level of support of extensions, method overloading, return of
>> > > > > arbitrary
>> > > > > collections (e.g. we also want to calculate cross-depends and
>> > > > > requires
>> > > > > fields on the fly which requ

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

[Igor Kalnitsky]

Patrick,

Sorry, but I meant another question. I thought that LMA plugin should
be installed in some environment before we can start use it. Is this a
case? If so, it means we can't use for master node until some
environment is deployed.

On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit <ppe...@mirantis.com> wrote:
>
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com)
> wrote:
>
> Hey Roman,
>
> Thank you for bringing this up. +1 from my side, especially taking
> into account the patch where we tried to solve logrotated logs problem
> [1]. It's complex and unsupportable, as well as already existed
> logview code in Nailgun.
>
> Patrick, Simon,
>
> Does LMA plugin support logs from master node? Or it's designed to
> watch environment's logs?
>
> No it’s not designed specifically for environment logs. Can be adapted to
> any log format.
>
> Would just need to write a parser like you would with logstach when logs are
> not standard.
>
> Patrick
>
>
>
> Thanks,
> Igor
>
>
> [1]: https://review.openstack.org/#/c/243240/
>
> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com> wrote:
>> Fuelers,
>>
>> As Simon said, we already have a log centralisation solution for MOS
>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>> objectively, there is no need to have log management in Nailgun anymore.
>> To
>> go one step further we suggested several times to have a StackLight agent
>> installed on the Fuel master node to also collect and centralise those
>> logs.
>> There is a little bit of a chicken and egg problem to resolve but I think
>> it
>> is worth a try to have that nailed down in the roadmap for Fuel 10.
>> Cheers
>> - Patrick
>>
>>
>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com)
>> wrote:
>>
>> Hello Roman,
>>
>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me>
>> wrote:
>>>
>>> Fuelers,
>>>
>>> I remember we’ve discussing this topic in our couloirs before but I’d
>>> like
>>> to bring that discussion to a more official format.
>>>
>>> Let me state a few reasons to do this:
>>>
>>> - Log management code in Nailgun is overcomplicated
>>> - Working with logs on big scale deployments is barely possible given the
>>> current representation
>>> - Due to overcomplexity and ineffectiveness of the code we always get
>>> recurring bugs like [1]. That eats tons of time to resolve.
>>> - There are much better specialized tools, say Logstash [2], that can
>>> deal
>>> with logs much more effectively.
>>>
>>>
>>> There may be more reasons bus I think even the already mentioned ones are
>>> enough to think about the following proposal:
>>>
>>> - Remove Logs tab from Fuel Web UI
>>> - Remove logs support from Nailgun
>>> - Create mechanism that allows to configure different log management
>>> software, say Logstash, Loggly, etc
>>>
>>> - Choose a default software to install and provide a plugin for it from
>>> the box
>>
>>
>> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
>> develop anything new.
>>
>> And I'm +1 with the removal of log management from Fuel. As you said, it
>> can't scale...
>>
>> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
>> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>>
>>
>>>
>>>
>>>
>>> References
>>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
>>> 2. https://www.elastic.co/products/logstash
>>>
>>>
>>> - 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
>>
>
> __
> OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Igor Kalnitsky]

Hey Roman,

Thank you for bringing this up. +1 from my side, especially taking
into account the patch where we tried to solve logrotated logs problem
[1]. It's complex and unsupportable, as well as already existed
logview code in Nailgun.

Patrick, Simon,

Does LMA plugin support logs from master node? Or it's designed to
watch environment's logs?

Thanks,
Igor


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

On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  wrote:
> Fuelers,
>
> As Simon said, we already have a log centralisation solution for MOS
> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> objectively, there is no need to have log management in Nailgun anymore. To
> go one step further we suggested several times to have a StackLight agent
> installed on the Fuel master node to also collect and centralise those logs.
> There is a little bit of a chicken and egg problem to resolve but I think it
> is worth a try to have that nailed down in the roadmap for Fuel 10.
> Cheers
>  - Patrick
>
>
> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) wrote:
>
> Hello Roman,
>
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  wrote:
>>
>> Fuelers,
>>
>> I remember we’ve discussing this topic in our couloirs before but I’d like
>> to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can deal
>> with logs much more effectively.
>>
>>
>> There may be more reasons bus I think even the already mentioned ones are
>> enough to think about the following proposal:
>>
>> - Remove Logs tab from Fuel Web UI
>> - Remove logs support from Nailgun
>> - Create mechanism that allows to configure different log management
>> software, say Logstash, Loggly, etc
>>
>> - Choose a default software to install and provide a plugin for it from
>> the box
>
>
> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
> develop anything new.
>
> And I'm +1 with the removal of log management from Fuel. As you said, it
> can't scale...
>
> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>
>
>>
>>
>>
>> References
>> 1.  https://bugs.launchpad.net/fuel/+bug/1553170
>> 2. https://www.elastic.co/products/logstash
>>
>>
>> - 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
>

__
OpenStack Development Mailing 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] Should we maintain example plugins?

[Igor Kalnitsky]

mean by "templates" the plugin which is create by just
>> >>>> "fpb
>> >>>> --create plugin-name"?
>> >>>> It doesn't cover enough, package installation and all range of tasks
>> >>>> executions.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov <ikutu...@mirantis.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Igor, i completely agree, actually plugin examples is almost a
>> >>>>> copy-paste.
>> >>>>>
>> >>>>> The only thing i see useful in the built plugins example is the
>> >>>>> ability
>> >>>>> to point some code lines, discussing plugin design and writing
>> >>>>> documentation. Why not to generate this examples automatically from
>> >>>>> templates?
>> >>>>>
>> >>>>> Also, as developer and administrator i love to use
>> >>>>> examples/templates
>> >>>>> where all essential settings and options are persist but commented
>> >>>>> (e.g.
>> >>>>> ProFTPD or Apache) and i could uncomment and copy-paste them not
>> >>>>> being
>> >>>>> afraid of typos. Also it allows to keep documentation actual and
>> >>>>> head
>> >>>>> documentation small. Duplication of inline documentation between
>> >>>>> examples
>> >>>>> and templates making things more weird and overshadows idea of
>> >>>>> inline
>> >>>>> documentation itself.
>> >>>>>
>> >>>>> Eugeny, why not to run integration tests against plugins generated
>> >>>>> from
>> >>>>> templates? It's will be even better integration tests.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
>> >>>>> <ikalnit...@mirantis.com> wrote:
>> >>>>>>
>> >>>>>> > and really lowering barriers for people who just begin create
>> >>>>>> > plugins.
>> >>>>>>
>> >>>>>> Nonsense. First, people usually create them via running `fpb
>> >>>>>> --create
>> >>>>>> plugin-name` that generates plugin boilerplate. And that
>> >>>>>> boilerplate
>> >>>>>> won't contain that changes.
>> >>>>>>
>> >>>>>> Second, if people ain't smart enough to change few lines in
>> >>>>>> `metadata.yaml` of generated boilerplate to make it work with
>> >>>>>> latest
>> >>>>>> Fuel, maybe it's better for them to do not develop plugins at all?
>> >>>>>>
>> >>>>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>> >>>>>> <sbogat...@mirantis.com> wrote:
>> >>>>>> > +1 to maintain example plugins. It is easy enough and really
>> >>>>>> > lowering
>> >>>>>> > barriers for people who just begin create plugins.
>> >>>>>> >
>> >>>>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
>> >>>>>> > <mmoses...@mirantis.com>
>> >>>>>> > wrote:
>> >>>>>> >>
>> >>>>>> >> Igor,
>> >>>>>> >>
>> >>>>>> >> It seems you are proposing an IKEA approach to plugins. Take
>> >>>>>> >> Fuel's
>> >>>>>> >> example plugin, add in the current Fuel release, and then build
>> >>>>>> >> it.
>> >>>>>> >> We
>> >>>>>> >> maintained these plugins in the past, but now it should a manual
>> >>>>>> >> step
>> >>>>>> >> to test it out on the current release.
>> >>>>>> >>
>> >>>>>> >> What would be a more ideal situation that meets the needs of
>> >>>>>> >> users
>> >>>>>&

Re: [openstack-dev] [fuel][Fuel-web] : make html command not working

[Igor Kalnitsky]

Hey Prameswar,

That't because dependencies weren't installed. I can't remember which
ones are required for building docs so my suggestion is to install
them all.

$ virtualenv venv
$ . venv/bin/activate
$ pip install -r ../nailgun/test-requirements.txt
$ make html

Let me know if you need some help.

- Igor

On Thu, Mar 10, 2016 at 10:01 AM, Prameswar Lal  wrote:
> i have cloned fuel repo and follow
> https://docs.fuel-infra.org/fuel-dev/develop/env.html steps : in section 5.7
> building Documentaion . when i run command  " make html " it gives follow
> error.
>
>
> (fuel-web-venv)pramesh@pramesh:~/Documents/fuel-web/docs$ make html
> sphinx-build -b html -W -d _build/doctrees   . _build/html
> Traceback (most recent call last):
>   File "/usr/local/bin/sphinx-build", line 5, in 
> from pkg_resources import load_entry_point
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2749, in
> 
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 446, in
> _build_master
> return cls._build_from_requirements(__requires__)
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 459, in
> _build_from_requirements
> dists = ws.resolve(reqs, Environment())
>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 628, in
> resolve
> raise DistributionNotFound(req)
> pkg_resources.DistributionNotFound: Sphinx==1.4b1
> make: *** [html] Error 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

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Igor Kalnitsky]

Hey Jeremy,

I got it and I'm working on patch [1] that must solve it. I simply
stop doing postre setup since it seems is already setup.

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

On Mon, Mar 7, 2016 at 4:38 PM, Jeremy Stanley  wrote:
> On 2016-03-07 16:02:40 +0530 (+0530), Prameswar Lal wrote:
>> I recently started exploring Fuel. Found a small error in documentation but
>> when i am trying to push the fix, jenkins is throwing following errors:
> [...]
>> | Creating role openstack_citest with password
>> openstack_citest2016-03-07 10:05:18.684
>> 
>> | psql: FATAL:  password authentication failed for user
>> "postgres"2016-03-07 10:05:18.684
>> 
> [...]
>
> Late last week we moved unit test jobs to a new minimal worker type
> which requires installation of distro packages and database
> configuration during job runtime. I tried to recreate (as closely as
> possible) with shell scripts the setup previously performed by
> corresponding Puppet modules which took place during image creation
> for the prior worker type. You can see at
> http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_04_22_654
> that the job successfully logs into postgres with a root password of
> "insecure_slave" and creates an openstack_citest role with password
> "openstack_citest".
>
> Any help from those more familiar with the database use in Fuel's
> unit tests in narrowing down what's different about this postgrest
> setup vs the old one would be most appreciated.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Should we maintain example plugins?

[Igor Kalnitsky]

> and really lowering barriers for people who just begin create plugins.

Nonsense. First, people usually create them via running `fpb --create
plugin-name` that generates plugin boilerplate. And that boilerplate
won't contain that changes.

Second, if people ain't smart enough to change few lines in
`metadata.yaml` of generated boilerplate to make it work with latest
Fuel, maybe it's better for them to do not develop plugins at all?

On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
<sbogat...@mirantis.com> wrote:
> +1 to maintain example plugins. It is easy enough and really lowering
> barriers for people who just begin create plugins.
>
> On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <mmoses...@mirantis.com>
> wrote:
>>
>> Igor,
>>
>> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> example plugin, add in the current Fuel release, and then build it. We
>> maintained these plugins in the past, but now it should a manual step
>> to test it out on the current release.
>>
>> What would be a more ideal situation that meets the needs of users and
>> QA? Right now we have failed tests until we can decide on a solution
>> that works for everybody.
>>
>> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>> > No, this is a wrong road to go.
>> >
>> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> > Remove v1 example from source tree? That doesn't seem good to me.
>> >
>> > Example plugins are only examples. The list of supported releases must
>> > be maintained on system test side, and system tests must inject that
>> > information into plugin's metadata.yaml and test it.
>> >
>> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> > responsible for preparing plugins. I can say even more: tests should
>> > not rely on what is produced by plugins, since it's something that
>> > could be changed and tests start failing.
>> >
>> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <scroi...@mirantis.com>
>> > wrote:
>> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> very
>> >> valuable for plugin developers.
>> >>
>> >> For example, I've encountered [0] the case where "plugin as role"
>> >> feature
>> >> wasn't easily testable with fuel-qa because not compliant with the last
>> >> plugin data structure,
>> >> and more recently we've spotted a regression [1] with "vip-reservation"
>> >> feature introduced by a change in nailgun.
>> >> These kind of issues are time consuming for plugin developers and
>> >> can/must
>> >> be avoided by testing them.
>> >>
>> >> I don't even understand why the question is raised while fuel plugins
>> >> are
>> >> supposed to be supported and more and more used [3], even by murano [4]
>> >> ...
>> >>
>> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> [3]
>> >>
>> >> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> [4] https://review.openstack.org/#/c/286310/
>> >>
>> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> <mmoses...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> Hi Fuelers,
>> >>>
>> >>> I would like to bring your attention a dilemma we have here. It seems
>> >>> that there is a dispute as to whether we should maintain the releases
>> >>> list for example plugins[0]. In this case, this is for adding version
>> >>> 9.0 to the list.
>> >>>
>> >>> Right now, we run a swarm test that tries to install the example
>> >>> plugin and do a deployment, but it's failing only for this reason. I
>> >>> should add that this is the only automated daily test that will verify
>> >>> that our plugin framework actually works. During the Mitaka
>> >>> development  cycle, we already had an extended period where plugins
>> >>> were broken[1]. Removing this test (or leaving it permanently red,
>> >>> which is effectively the same), would raise the risk to any member of
>> >>> the Fuel community who depends on plugins actually working.
>> >>

Re: [openstack-dev] [Fuel][Fuel-web] Jenkins failing, tox -e py27 error

[Igor Kalnitsky]

Hey Prameswar,

It seems we're experiencing that issue on all our patches. For
example, the same error blocks that patch from merge [1].

I think it's some OpenStack CI issue. Let's give a time.

- Igor

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

On Mon, Mar 7, 2016 at 12:32 PM, Prameswar Lal  wrote:
> Hi All,
>
> I recently started exploring Fuel. Found a small error in documentation but
> when i am trying to push the fix, jenkins is throwing following errors:
>
>
>
> 2016-03-07 10:05:18.619 | psql: FATAL:  password authentication failed for
> user "postgres"
> 2016-03-07 10:05:18.619 | FATAL:  password authentication failed for user
> "postgres"
> 2016-03-07 10:05:18.619 | password retrieved from file
> "/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"
> 2016-03-07 10:05:18.620 | Creating role openstack_citest with password
> openstack_citest
> 2016-03-07 10:05:18.684 | psql: FATAL:  password authentication failed for
> user "postgres"
> 2016-03-07 10:05:18.684 | FATAL:  password authentication failed for user
> "postgres"
> 2016-03-07 10:05:18.684 | password retrieved from file
> "/home/jenkins/workspace/gate-fuel-web-python27/test_run/pgpass"
> 2016-03-07 10:05:18.686 | ERROR: InvocationError: '/bin/bash -c
> /home/jenkins/workspace/gate-fuel-web-python27/nailgun/tools/env.sh
> prepare_nailgun_database'
>
>
>
> http://logs.openstack.org/40/289240/1/check/gate-fuel-web-python27/bd6300b/console.html#_2016-03-07_10_05_18_684
>
>
> Can anybody please provide me pointers on how to resolve this?
>
>
>
> Thanks & Regards
> Prameswar
>
> __
> OpenStack Development Mailing 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] Should we maintain example plugins?

[Igor Kalnitsky]

No, this is a wrong road to go.

What if in Fuel 10 we drop v1 plugins support? What should we do?
Remove v1 example from source tree? That doesn't seem good to me.

Example plugins are only examples. The list of supported releases must
be maintained on system test side, and system tests must inject that
information into plugin's metadata.yaml and test it.

Again, I don't say we shouldn't test plugins. I say, tests should be
responsible for preparing plugins. I can say even more: tests should
not rely on what is produced by plugins, since it's something that
could be changed and tests start failing.

On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset  wrote:
> IMHO it is important to keep plugin examples and keep testing them, very
> valuable for plugin developers.
>
> For example, I've encountered [0] the case where "plugin as role" feature
> wasn't easily testable with fuel-qa because not compliant with the last
> plugin data structure,
> and more recently we've spotted a regression [1] with "vip-reservation"
> feature introduced by a change in nailgun.
> These kind of issues are time consuming for plugin developers and can/must
> be avoided by testing them.
>
> I don't even understand why the question is raised while fuel plugins are
> supposed to be supported and more and more used [3], even by murano [4] ...
>
> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> [4] https://review.openstack.org/#/c/286310/
>
> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn 
> wrote:
>>
>> Hi Fuelers,
>>
>> I would like to bring your attention a dilemma we have here. It seems
>> that there is a dispute as to whether we should maintain the releases
>> list for example plugins[0]. In this case, this is for adding version
>> 9.0 to the list.
>>
>> Right now, we run a swarm test that tries to install the example
>> plugin and do a deployment, but it's failing only for this reason. I
>> should add that this is the only automated daily test that will verify
>> that our plugin framework actually works. During the Mitaka
>> development  cycle, we already had an extended period where plugins
>> were broken[1]. Removing this test (or leaving it permanently red,
>> which is effectively the same), would raise the risk to any member of
>> the Fuel community who depends on plugins actually working.
>>
>> The other impact of abandoning maintenance of example plugins is that
>> it means that a given interested Fuel Plugin developer would not be
>> able to easily get started with plugin development. It might not be
>> inherently obvious to add the current Fuel release to the
>> metadata.yaml file and it would likely discourage such a user. In this
>> case, I would propose that we remove example plugins from fuel-plugins
>> GIT repo if they are not maintained. Non-functioning code is worse
>> than deleted code in my opinion.
>>
>> Please share your opinions and let's decide which way to go with this
>> bug[2]
>>
>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
>> [2] https://launchpad.net/bugs/1548340
>>
>> Best Regards,
>> Matthew Mosesohn
>>
>> __
>> OpenStack Development Mailing 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] Feature Freeze Exception Request - switching to CentOS-7.2

[Igor Kalnitsky]

Dmitry, Igor,

> Very important thing is that CentOS 7.1 which master node is based now
> don't get updates any longer.

If you are using "fixed" release you must be ready that you won't get
any updates. So with CentOS 7.2 the problem still the same.

However, let's wait for Fuel PTL decision. I only shared my POV:
that's not a critical feature, and taking into account the risks of
regression - I'd prefer to do not accept it in 9.0.

Regards,
Igor

On Wed, Mar 2, 2016 at 4:42 PM, Igor Marnat <imar...@mirantis.com> wrote:
> Igor,
> please note that this is pretty much not like update of master node which we
> had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which team
> tested for more than 2 months already.
>
> We don't expect it to require any additional efforts from core or qa team.
>
> Very important thing is that CentOS 7.1 which master node is based now don't
> get updates any longer. Updates are only provided for CentOS 7.2.
>
> So we'll have to switch CentOS 7.1 to CentOS 7.2 anyways.
>
> We can do it now for more or less free, later in release cycle for higher
> risk and QA efforts and after the release for 2x price because of additional
> QA cycle we'll need to pass through.
>
>
>
> Regards,
> Igor Marnat
>
> On Wed, Mar 2, 2016 at 2:57 PM, Dmitry Teselkin <dtesel...@mirantis.com>
> wrote:
>>
>> Hi Igor,
>>
>> Postponing this till Fuel 10 means we have to elaborate a plan to do such
>> upgrade for Fuel 9 after the release - the underlying system will not get
>> updated on it's own, and the security issues will not close themselves. The
>> problem here is that such upgrade of deployed master node requires a lot of
>> QA work also.
>>
>> Since we are not going to update package we build on our own (they still
>> targeted 7.1) switching master node base to CentOS-72 is not that dangerous
>> as it seems.
>>
>> On Wed, Mar 2, 2016 at 1:54 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>>
>>> Hey Dmitry,
>>>
>>> No offence, but I rather against that exception. We have too many
>>> things to do in Mitaka, and moving to CentOS 7.2 means
>>>
>>> * extra effort from core team
>>> * extra effort from qa team
>>>
>>> Moreover, it might block development by introducing unpredictable
>>> regressions. Remember 8.0? So I think it'd be better to reduce risk of
>>> regressions that affects so many developers by postponing CentOS 7.2
>>> till Fuel 10.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin <dtesel...@mirantis.com>
>>> wrote:
>>> > I'd like to ask for a feature freeze exception for switching to
>>> > CentOS-7.2
>>> > feature [0].
>>> >
>>> > CentOS-7.2 ISO's have been tested periodically since the beginning of
>>> > the
>>> > year, and all major issues were addressed / fixed at the moment. During
>>> > the
>>> > last weekend I've made 70 BVT runs to verify that the  solution [2] for
>>> > the
>>> > last issue - e1000 transmit unit hangs works. And it works, 0 tests of
>>> > 35
>>> > failed [3].
>>> >
>>> > Benefits of switching to CentOS-7.2 are quite obvious - we will return
>>> > to
>>> > latest supported CentOS release, will fix a lot of bugs / security
>>> > issues
>>> > [4] and will make further updates easier.
>>> >
>>> > Risk of regression still exists, but it's quite low, 35 successful BVTs
>>> > can't be wrong.
>>> >
>>> > To finish that feature the following should be done:
>>> > * review and merge e1000 workaround [2]
>>> > * review and merge spec [0]
>>> > * review and merge request that switches build CI to CentOS-7.2 [5]
>>> >
>>> > I expect the last day it could be done is March, 4.
>>> >
>>> > [0] https://review.openstack.org/#/c/280338/
>>> > [1] https://bugs.launchpad.net/fuel/+bug/1526544
>>> > [2] https://review.openstack.org/#/c/285306/
>>> > [3] https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350
>>> > [4] https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630
>>> > [5] https://review.fuel-infra.org/#/c/17400/
>>> >
>>> >
>>> > --
>>> > Thanks,
>>> > Dmitry Teselkin
>>> > Mirantis
>>> > http://www.mirantis.com
&

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

[Igor Kalnitsky]

Hey Dmitry,

No offence, but I rather against that exception. We have too many
things to do in Mitaka, and moving to CentOS 7.2 means

* extra effort from core team
* extra effort from qa team

Moreover, it might block development by introducing unpredictable
regressions. Remember 8.0? So I think it'd be better to reduce risk of
regressions that affects so many developers by postponing CentOS 7.2
till Fuel 10.

Thanks,
Igor


On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin  wrote:
> I'd like to ask for a feature freeze exception for switching to CentOS-7.2
> feature [0].
>
> CentOS-7.2 ISO's have been tested periodically since the beginning of the
> year, and all major issues were addressed / fixed at the moment. During the
> last weekend I've made 70 BVT runs to verify that the  solution [2] for the
> last issue - e1000 transmit unit hangs works. And it works, 0 tests of 35
> failed [3].
>
> Benefits of switching to CentOS-7.2 are quite obvious - we will return to
> latest supported CentOS release, will fix a lot of bugs / security issues
> [4] and will make further updates easier.
>
> Risk of regression still exists, but it's quite low, 35 successful BVTs
> can't be wrong.
>
> To finish that feature the following should be done:
> * review and merge e1000 workaround [2]
> * review and merge spec [0]
> * review and merge request that switches build CI to CentOS-7.2 [5]
>
> I expect the last day it could be done is March, 4.
>
> [0] https://review.openstack.org/#/c/280338/
> [1] https://bugs.launchpad.net/fuel/+bug/1526544
> [2] https://review.openstack.org/#/c/285306/
> [3] https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350
> [4] https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630
> [5] https://review.fuel-infra.org/#/c/17400/
>
>
> --
> Thanks,
> Dmitry Teselkin
> Mirantis
> http://www.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][FFE] Use RGW as a default object store instead of Swift

[Igor Kalnitsky]

Hey Konstantin,

I see that provided patch [1] is for stable/8.0. Fuel 8.0 is recently
released and we usually do not accept any features to stable branch.

Or your meant that patch for master branch?

Thanks,
Igor

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

On Tue, Mar 1, 2016 at 4:44 PM, Konstantin Danilov
 wrote:
> Colleagues,
> I would like to request a feature freeze exception for
> 'Use RGW as a default object store instead of Swift' [1].
>
> To merge the changes we need at most one week of time.
>
> [1]: https://review.openstack.org/#/c/286100/
>
> Thanks
> --
>
> Kostiantyn Danilov aka koder.ua
> Principal software engineer, Mirantis
>
> skype:koder.ua
> http://koder-ua.blogspot.com/
> http://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] [Plugins] Fuel Plugin Builder 4.0.0 released

[Igor Kalnitsky]

Hey Fuelers,

I want to announce that FPB (fuel plugin builder) v4.0.0 has been
released on PyPI [1].

New package version "4.0.0" includes but not limited to:

* New flag `is_hotpluggable` in `metadata.yaml` that allows to install
and use plugin on previously deployed environments.
* Plugin can specify settings group using "group" field in metadata in
environment_config.yaml file.
* New group `equipment` added to groups list in `metadata.yaml`.
* New `components.yaml` file that allows to declare new components.

Bugfixes:

* Fix of missing strategy parameter in V3 and V4 deployment tasks LP1522785 [2].

Thanks,
Igor

[1] https://pypi.python.org/pypi/fuel-plugin-builder/4.0.0
[2] https://bugs.launchpad.net/fuel/+bug/1522785

__
OpenStack Development Mailing 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][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Igor Kalnitsky]

Hey Denis,

I didn't read the spec yet, but want to raise one important question.
AFAIU, you plan to release Murano plugin between Fuel 9.0 and Fuel 10,
so the question is do you plan to support installation of Murano
plugin on Fuel 9.0? If so, that might be a problem.

Thanks,
- Igor

On Wed, Feb 24, 2016 at 6:30 PM, Denis Egorenko  wrote:
> Hello folks,
>
> i would like to notify you, that we are going to remove Murano as built in
> Fuel and move this functionality to fuel-plugin.
>
> Transition from Fuel built in to Fuel plugin deployment will follow next
> way:
>
> * Murano deployment in Fuel 9.0 will be deprecated: we leave an ability to
> deploy it,
>   keeping puppet manifests for Murano in fuel-library, keeping UI settings
>   untill plugin will be prepared and tested;
>
> * Once plugin is ready, Fuel 9.0 deployment from built in Murano will
>   forbidden. All Murano codebase will be removed from Fuel in next release.
>
> Since Murano will be a plugin, it will have his own development cycle,
> differ from Fuel releases.
>
> There is specification for this activity [1]. Any feedback is welcome.
>
> [1] https://review.openstack.org/275124
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Igor Kalnitsky]

Kyrylo G. wrote:
> So who is voting for the path to be abandoned?

I vote to abandon it. Let's do not break existing plugins, and do not
add *undo* tasks for plugin developers. If they want to configure
network, they'll ask it explicitly.


Kyrylo G. wrote:
> By the way, there is already a task running by the wildcard:
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4

Yes, exactly, but the thing is that our original task for setuping
repos was executed on all nodes before, including ones provided by
plugins. Making it executing on core nodes only may break plugins that
rely on it. So generally, it's about backward compatibility.


Bulat G. wrote:
> This tasks should run on all nodes and it does not matter, the node
> has role from plugin or core-role.

Nope, they shouldn't. Why do I need to install the following packages

  'screen',
  'tmux',
  'htop',
  'tcpdump',
  'strace',
  'fuel-misc',
  'man-db',
  'fuel-misc',
  'fuel-ha'

if I have no plans to use them? As a deployer engineer, I'd prefer to
keep my role as clear as possible, and decide what to install in my
own way.


On Fri, Feb 19, 2016 at 1:06 PM, Bulat Gaifullin
<bgaiful...@mirantis.com> wrote:
> +1 to use wildcards for common tasks like netconfig and setup repositories.
> This tasks should run on all nodes and it does not matter, the node has role
> from plugin or core-role.
> In my opinion we should one approach for basic configuration of node.
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 19 Feb 2016, at 13:36, Kyrylo Galanov <kgala...@mirantis.com> wrote:
>
> Hi,
>
> So who is voting for the path to be abandoned?
>
> By the way, there is already a task running by the wildcard:
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4
> However, it this case it might work with plugins.
>
> Best regards,
> Kyrylo
>
> On Fri, Feb 19, 2016 at 1:09 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hey Kyrylo,
>>
>> As it was mentioned in the review: you're about to break roles defined
>> by plugins. That's not good move, I believe.
>>
>> Regarding 'exclude' directive, I have no idea what you're talking
>> about. We don't support it now, and, anyway, there should be no
>> difference between roles defined by plugins and core roles.
>>
>> - Igor
>>
>> On Thu, Feb 18, 2016 at 12:53 PM, Kyrylo Galanov <kgala...@mirantis.com>
>> wrote:
>> > Hello,
>> >
>> > We are about to switch to wildcards instead of listing all groups in
>> > tasks
>> > explicitly [0].
>> > This change must make deployment process more obvious for developers.
>> > However, it might lead to confusion when new groups are added either by
>> > plugin or fuel team in future.
>> >
>> > As mention by Bogdan, it is possible to use 'exclude' directive to
>> > mitigate
>> > the risk.
>> > Any thoughts on the topic are appreciated.
>> >
>> >
>> > [0] https://review.openstack.org/#/c/273596/
>> >
>> > Best regards,
>> > Kyrylo
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.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] Wildcards instead of

[Igor Kalnitsky]

Hey Kyrylo,

As it was mentioned in the review: you're about to break roles defined
by plugins. That's not good move, I believe.

Regarding 'exclude' directive, I have no idea what you're talking
about. We don't support it now, and, anyway, there should be no
difference between roles defined by plugins and core roles.

- Igor

On Thu, Feb 18, 2016 at 12:53 PM, Kyrylo Galanov  wrote:
> Hello,
>
> We are about to switch to wildcards instead of listing all groups in tasks
> explicitly [0].
> This change must make deployment process more obvious for developers.
> However, it might lead to confusion when new groups are added either by
> plugin or fuel team in future.
>
> As mention by Bogdan, it is possible to use 'exclude' directive to mitigate
> the risk.
> Any thoughts on the topic are appreciated.
>
>
> [0] https://review.openstack.org/#/c/273596/
>
> Best regards,
> Kyrylo
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

[Igor Kalnitsky]

Vladimir,

Obviously, there will be regressions in other scenarios. However, it's
better to catch them now. We have not much time before FF, and it'd be
better to merge such features as early as possible, and do not wait
for merge hell a day before FF.

The thing we need to know is that BVT is green, and that means most
developers aren't blocked.

Thanks,
Igor

On Wed, Feb 17, 2016 at 7:48 PM, Vladimir Kuklin  wrote:
> Fuelers
>
> I have strong opinion against this merge freeze right now. We have critical
> bugs blocking bvt and we do not have enough info on mitaka readiness for
> other scenarios than bvt.
>
> 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko"
>  написал:
>
>> Fuel core reviewers,
>>
>> Fuel CI is being migrated to an ISO image with Mitaka packages, please
>> don't merge any commits to any Fuel repositories without coordination
>> with Aleksandra until further notice.
>>
>> This merge freeze is expected to last a few hours.
>>
>> --
>> Dmitry Borodaenko
>>
>> __
>> OpenStack Development Mailing 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 Fedor Zhadaev for the fuel-menu-core team

[Igor Kalnitsky]

Well, voting period is over and there's no objections from cores. So
I'm going to add Fedor to fuel-menu-core group.

Congrats Fedor! :)

On Mon, Feb 8, 2016 at 2:34 PM, Aleksey Kasatkin <akasat...@mirantis.com> wrote:
> +1
>
>
> Aleksey Kasatkin
>
>
> On Mon, Feb 8, 2016 at 12:04 PM, Tatyana Leontovich
> <tleontov...@mirantis.com> wrote:
>>
>> +1
>>
>>
>>
>> On Mon, Feb 8, 2016 at 11:54 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>>
>>> Hey Fuelers,
>>>
>>> I'd like to nominate Fedor Zhadaev for the fuel-menu-core team.
>>> Fedor's doing good review with detailed feedback [1], and has
>>> contributes over 20 patches during Mitaka release cycle [2].
>>>
>>> Fuel Cores, please reply back with +1/-1.
>>>
>>> - igor
>>>
>>> [1] http://stackalytics.com/?module=fuel-menu=mitaka
>>> [2]
>>> http://stackalytics.com/?module=fuel-menu=mitaka_id=fzhadaev
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://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] URL of Horizon is hard to find on the dashboard

[Igor Kalnitsky]

Vitaly,

> Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon and 
> every plugin link

Why? And how do you handle it with link now?

On Fri, Feb 12, 2016 at 11:15 AM, Vitaly Kramskikh
<vkramsk...@mirantis.com> wrote:
> Igor,
>
> Then we'll end up with 2 buttons (for HTTP and HTTPS links) for Horizon and
> every plugin link, which would look quite ugly. We had all these options in
> mind when we designed this change and decided to go with the current look.
>
> Seriously guys, I don't understand you concerns. After dismissing the
> deployment result message, Horizon link is in the top block on the dashboard
> - it's very hard to get lost.
>
> 2016-02-11 20:10 GMT+07:00 Igor Kalnitsky <ikalnit...@mirantis.com>:
>>
>> Vitaly,
>>
>> What about adding some button with "Go" or "Visit" text? Somewhere on
>> the right size of line? It'd be easy to understand what to click to
>> visit the dashboard.
>>
>> - Igor
>>
>> On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh
>> <vkramsk...@mirantis.com> wrote:
>> > Roman,
>> >
>> > For with enabled SSL it still can be quite long as it contains FQDN. And
>> > we
>> > also need to change plugin link representation accordingly, which I
>> > don't
>> > fine acceptable. I think you just got used to the old interface where
>> > the
>> > link to Horizon was a part of deployment task result message. We've
>> > merged
>> > small style update to underline Horizon/plugin links, I think it would
>> > be
>> > enough to solve the issue.
>> >
>> > 2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko <m...@romcheg.me>:
>> >>
>> >> Cannot we use display the same link we use in the title?
>> >>
>> >> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh <vkramsk...@mirantis.com>
>> >> написав(ла):
>> >>
>> >> Hi, Roman,
>> >>
>> >> I think the only solution here is to underline the title so it would
>> >> look
>> >> like a link. I don't think it's a good idea to show full URL because:
>> >>
>> >> If SSL is enabled, there will be 2 links - HTTP and HTTPS.
>> >> Plugins can provide their own links for their dashboards, and they
>> >> would
>> >> be shown using exactly the same representation which is used for
>> >> Horizon.
>> >> These links could be quite long.
>> >>
>> >>
>> >> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko <m...@romcheg.me>:
>> >>>
>> >>> Whoops! I forgot to attach the link. Sorry!
>> >>>
>> >>> 1. http://i.imgur.com/8GaUtDq.png
>> >>>
>> >>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko <m...@romcheg.me>
>> >>> > написав(ла):
>> >>> >
>> >>> > Hi fuelers!
>> >>> >
>> >>> > I’m not sure, if it’s my personal problem or the UX can be improved
>> >>> > a
>> >>> > little, but I’ve literary spend more than 5 minutes trying to figure
>> >>> > out how
>> >>> > to find a URL of Horizon. I’ve made a screenshot [1] and I suggest
>> >>> > to add a
>> >>> > full a link with the full URL in its test after "The OpenStack
>> >>> > dashboard
>> >>> > Horizon is now available". That would make things much more usable.
>> >>> >
>> >>> >
>> >>> > - romcheg
>> >>> >
>> >>> >
>> >>> >
>> >>> > __
>> >>> > OpenStack Development Mailing List (not for usage questions)
>> >>> > Unsubscribe:
>> >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> > http://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
>> >>>
>> >>
>> >&g

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Igor Kalnitsky]

Stanislaw B.,

You're somehow contradicting in your statements. However, taking into
account your's -

> Both of these approaches can be used, so I'm against forcing plugin
> developers to use just one approach.

I can conclude that you support idea of having multi-release plugins?
Because no one can restrict you use different VCS repos/branches for
single release if you want to.

Is that the case?

- Igor

On Fri, Feb 12, 2016 at 11:18 AM, Stanislaw Bogatkin
<sbogat...@mirantis.com> wrote:
>>>With plugins we extend Fuel capabilities, which supports multiple
>>> operating system releases, so it's absolutely natural to extend multiple
>>> releases at the same time.
> It is okay for me when we talk about different operating system release, but
> initial question was about different Fuel and OpenStack releases, it is not
> the same. We can have one operating system thru several Fuel releases.
> As I said - approach when you need extend plugin functionality to multiple
> releases lead to mess in a plugin repo if you change the codebase from one
> release to another. From other hand - it works wonderful if plugin codebase
> doesn't change and all you need to support multiple Fuel releases is to
> change metadata.yaml. Both of these approaches can be used, so I'm against
> forcing plugin developers to use just one approach.
>
> On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <e...@mirantis.com> wrote:
>>
>> Ilya,
>>
>> >> My opinion that i've seen no example of multiple software of plugins
>> >> versions shipped in one package or other form of bundle. Its not a common
>> >> practice.
>>
>> With plugins we extend Fuel capabilities, which supports multiple
>> operating system releases, so it's absolutely natural to extend multiple
>> releases at the same time.
>>
>> >> Anyway we need to provide ability to override paths in manifest
>> >> (metadata.yaml).
>>
>> Could you please provide more information on that? I'm not sure if I
>> understand your solution.
>>
>> Also I'm not sure what we are arguing about, if plugin developer (or
>> certification process of some company) requires to have plugin per release,
>> it's *very easy* and straight forward to do it even now *without any*
>> changes.
>>
>> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc,
>> let them do it, and again when we get full support of multi-version
>> environments it's going to be even more crucial for UX to have a single
>> plugin with multi-release support.
>>
>> Thanks,
>>
>> On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutu...@mirantis.com>
>> wrote:
>>>
>>> My opinion that i've seen no example of multiple software of plugins
>>> versions shipped in one package or other form of bundle. Its not a common
>>> practice.
>>>
>>> Anyway we need to provide ability to override paths in manifest
>>> (metadata.yaml).
>>>
>>> So the plugin developers could use this approaches to provide multiple
>>> versions support:
>>>
>>> * tasks logic (do the plugin developers have access to current release
>>> info?)
>>> * hooks in pre-build process. Its not a big deal to preprocess source
>>> folder to build different packages with scripts that adding or removing some
>>> files or replacing some paths.
>>> * and, perhaps, logic anchors with YACL or other DSL in tasks
>>> dependancies if this functionality will be added this in theory could allow
>>> to use or not to use some graph parts depending on release.
>>>
>>> I think its already better than nothing and more flexible than any
>>> standardised approach.
>>>
>>> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasqu...@mirantis.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky
>>>> <ikalnit...@mirantis.com> wrote:
>>>>>
>>>>> Hey folks,
>>>>>
>>>>> The original idea is to provide a way to build plugin that are
>>>>> compatible with few releases. It makes sense to me, cause it looks
>>>>> awful if you need to maintain different branches for different Fuel
>>>>> releases and there's no difference in the sources. In that case, each
>>>>> bugfix to deployment scripts requires:
>>>>>
>>>>> * backport bugfix to other branches (N backports)
>>>>> * build new packages for supported releases (N builds)
>>&

Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on the dashboard

[Igor Kalnitsky]

Vitaly,

What about adding some button with "Go" or "Visit" text? Somewhere on
the right size of line? It'd be easy to understand what to click to
visit the dashboard.

- Igor

On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh
 wrote:
> Roman,
>
> For with enabled SSL it still can be quite long as it contains FQDN. And we
> also need to change plugin link representation accordingly, which I don't
> fine acceptable. I think you just got used to the old interface where the
> link to Horizon was a part of deployment task result message. We've merged
> small style update to underline Horizon/plugin links, I think it would be
> enough to solve the issue.
>
> 2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko :
>>
>> Cannot we use display the same link we use in the title?
>>
>> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh 
>> написав(ла):
>>
>> Hi, Roman,
>>
>> I think the only solution here is to underline the title so it would look
>> like a link. I don't think it's a good idea to show full URL because:
>>
>> If SSL is enabled, there will be 2 links - HTTP and HTTPS.
>> Plugins can provide their own links for their dashboards, and they would
>> be shown using exactly the same representation which is used for Horizon.
>> These links could be quite long.
>>
>>
>> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :
>>>
>>> Whoops! I forgot to attach the link. Sorry!
>>>
>>> 1. http://i.imgur.com/8GaUtDq.png
>>>
>>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko  написав(ла):
>>> >
>>> > Hi fuelers!
>>> >
>>> > I’m not sure, if it’s my personal problem or the UX can be improved a
>>> > little, but I’ve literary spend more than 5 minutes trying to figure out 
>>> > how
>>> > to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to add 
>>> > a
>>> > full a link with the full URL in its test after "The OpenStack dashboard
>>> > Horizon is now available". That would make things much more usable.
>>> >
>>> >
>>> > - romcheg
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing 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
>>
>
>
>
> --
> 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] Task Based Deployment Is at Least Twice Faster

[Igor Kalnitsky]

Well, I'm going to build a new ISO and run BVT. As soon as they are
green, I'm going to approve the change.

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

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

[Igor Kalnitsky]

> I've run BVT more than 100 times, it works,

You run it some time ago. There were a lot of opportunities to
introduce regression in both Nailgun and tasks of Fuel Library. ;)

> We are going to run a swarm test today against the ISO with enabled 
> task-based deployment

So there will be a custom ISO, correct? If so, it works for me and
I'll wait for its result.

On Tue, Feb 9, 2016 at 1:17 PM, Alexey Shtokolov
<ashtoko...@mirantis.com> wrote:
> Igor,
>
> We are going to run a swarm test today against the ISO with enabled
> task-based deployment, than check results and merge changes tomorrow.
> I've run BVT more than 100 times, it works, but I would like to check more
> deployment cases.
> And I guess it should be easy to troubleshoot if docker-related and
> task-based related changes will be separated by a few days.
>
> 2016-02-09 13:39 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>:
>>
>> Well, I'm going to build a new ISO and run BVT. As soon as they are
>> green, I'm going to approve the change.
>>
>> On Tue, Feb 9, 2016 at 12:32 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
>> wrote:
>> > On 08.02.2016 17:05, Igor Kalnitsky wrote:
>> >> Hey Fuelers,
>> >>
>> >> When we are going to enable it? I think since HCF is passed for
>> >> stable/8.0, it's time to enable task-based deployment for master
>> >> branch.
>> >>
>> >> Opinion?
>> >
>> > This must be done for the 9.0, IMHO.
>> >
>> >>
>> >> - Igor
>> >>
>> >> On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya
>> >> <bdobre...@mirantis.com> wrote:
>> >>> On 02.02.2016 17:35, Alexey Shtokolov wrote:
>> >>>> Hi Fuelers!
>> >>>>
>> >>>> As you may be aware, since [0] Fuel has implemented a new
>> >>>> orchestration
>> >>>> engine [1]
>> >>>> We switched the deployment paradigm from role-based (aka granular) to
>> >>>> task-based and now Fuel can deploy all nodes simultaneously using
>> >>>> cross-node dependencies between deployment tasks.
>> >>>
>> >>> That is great news! Please do not forget about docs updates as well.
>> >>> Those docs are always forgotten like poor orphans... I submitted a
>> >>> patch
>> >>> [0] to MOS docs, please review and add more details, if possible, for
>> >>> plugins impact as well.
>> >>>
>> >>> [0] https://review.fuel-infra.org/#/c/16509/
>> >>>
>> >>>>
>> >>>> This feature is experimental in Fuel 8.0 and will be enabled by
>> >>>> default
>> >>>> for Fuel 9.0
>> >>>>
>> >>>> Allow me to show you the results. We made some benchmarks on our bare
>> >>>> metal lab [2]
>> >>>>
>> >>>> Case #1. 3 controllers + 7 computes w/ ceph.
>> >>>> Task-based deployment takes *~38* minutes vs *~1h15m* for granular
>> >>>> (*~2*
>> >>>> times faster)
>> >>>> Here and below the deployment time is average time for 10 runs
>> >>>>
>> >>>> Case #2. 3 controllers + 3 mongodb + 4 computes w/ ceph.
>> >>>> Task-based deployment takes *~41* minutes vs *~1h32m* for granular
>> >>>> (*~2.24* times faster)
>> >>>>
>> >>>>
>> >>>>
>> >>>> Also we took measurements for Fuel CI test cases. Standard BVT
>> >>>> (Master
>> >>>> node + 3 controllers + 3 computes w/ ceph. All are in qemu VMs on one
>> >>>> host)
>> >>>>
>> >>>> Fuel CI slaves with *4 *cores *~1.1* times faster
>> >>>> In case of 4 cores for 7 VMs they are fighting for CPU resources and
>> >>>> it
>> >>>> marginalizes the gain of task-based deployment
>> >>>>
>> >>>> Fuel CI slaves with *6* cores *~1.6* times faster
>> >>>>
>> >>>> Fuel CI slaves with *12* cores *~1.7* times faster
>> >>>
>> >>> These are really outstanding results!
>> >>> (tl;dr)
>> >>> I believe the next step may be to leverage the "external install & svc
>> >>> management" feature (example [1]) of the Liberty release (7.0.0) of
>> >>> Puppet-Openstack (PO) module

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

[Igor Kalnitsky]

Hey Fuelers,

When we are going to enable it? I think since HCF is passed for
stable/8.0, it's time to enable task-based deployment for master
branch.

Opinion?

- Igor

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

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

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

[Igor Kalnitsky]

Hey Fuelers,

I'd like to nominate Fedor Zhadaev for the fuel-menu-core team.
Fedor's doing good review with detailed feedback [1], and has
contributes over 20 patches during Mitaka release cycle [2].

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

- igor

[1] http://stackalytics.com/?module=fuel-menu=mitaka
[2] http://stackalytics.com/?module=fuel-menu=mitaka_id=fzhadaev

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

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Igor Kalnitsky]

Simon,

> Nope, it doesn't work for me since it should run for *all* the nodes,
> irrespective of their roles. AFAIK update_required doesn't support '*'.

If your plugin provides a new node role as well as additional tasks
for other node roles, you may try to workaround that by using

  reexecute_on: [deploy_changes]

task marker. In that case, the task will be executed each time you hit
"Deploy Changes" button, so make sure it's idempotent task.

- igor


On Fri, Feb 5, 2016 at 1:04 PM, Evgeniy L  wrote:
> Simon,
>
>>> Any plan to have a nicer experience in future Fuel releases?
>
> I haven't heard about any plans on improvements for that, but management
> team should know better whether it's on roadmap or not.
>
> Thanks,
>
> On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier 
> wrote:
>>
>> Thanks Evgeniy.
>>
>> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L  wrote:
>>>
>>> Hi Simon,
>>>
>>> As far as I know it's expected behaviour (at least for the current
>>> release), and it's expected that user reruns deployment on required nodes
>>> using fuel cli, in order to install plugin on a live environment.
>>
>>
>> Ok. For the record, this means running this command for every node that is
>> already deployed:
>> $ fuel node --node-id  --deploy
>>
>> Any plan to have a nicer experience in future Fuel releases?
>>
>>>
>>> It depends on specific role, but "update_required" field may help you, it
>>> can be added to role description, Fuel reruns deployment on nodes with
>>> roles, which are specified in the list, if new node with the role is added
>>> to the environment.
>>
>>
>> Nope, it doesn't work for me since it should run for *all* the nodes,
>> irrespective of their roles. AFAIK update_required doesn't support '*'.
>>
>>>
>>>
>>> Thanks,
>>>
>>> [1]
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18
>>>
>>> On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
>>> wrote:

 Hi,
 I'm testing the ability to install Fuel plugins in a an environment that
 is already deployed.
 My starting environment is quite simple: 1 controller + 1 compute. After
 the initial deployment, I've installed the 4 LMA plugins:
 - LMA collector
 - Elasticsearch-Kibana [*]
 - InfluxDB-Grafana [*]
 - Infrastructure Alerting [*]
 [*] adds a new role
 Of course, all plugins have "is_hotpluggable: true" in their metadata
 definition.
 My expectation is that I can add a new node with the new roles and that
 the LMA collector tasks are executed for all 3 nodes. So I've added the new
 node and click the "Deploy changes" button. My re-deployment runs fine but 
 I
 notice that the plugins aren't installed on the existing nodes (eg
 /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
 executed on already deployed nodes... Is this a known limitation? Am I
 missing something?
 Best regards,
 Simon



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.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] CentOS bootstrap image retirement

[Igor Kalnitsky]

No objections from my side. Let's do it.

On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov  wrote:
> Hi Sergey,
>
> I fully support this idea. It was our plan as well when we were developing
> Ubuntu Bootstrap feature. So let's proceed with CentOS bootstrap removal.
>
> BR,
> Dmitry.
>
> On Tue, Feb 2, 2016 at 2:55 PM, Sergey Kulanov 
> wrote:
>>
>> Hi Folks,
>>
>> I think it's time to declare CentOS bootstrap image retirement.
>> Since Fuel 8.0 we've switched to Ubuntu bootstrap image usage [1, 2] and
>> CentOS one became deprecated,
>> so in Fuel 9.0 we can freely remove it [2].
>> For now we are building CentOS bootstrap image together with ISO and then
>> package it into rpm [3], so by removing fuel-bootstrap-image [3] we:
>>
>> * simplify patching/update story, since we don't need to rebuild/deliver
>> this
>>   package on changes in dependent packages [4].
>>
>> * speed-up ISO build process, since building centos bootstrap image takes
>> ~ 20%
>>   of build-iso time.
>>
>> We've prepared related blueprint for this change [5] and spec [6]. We also
>> have some draft patchsets [7]
>> which passed BVT tests.
>>
>> So the next steps are:
>> * get feedback by reviewing the spec/patches;
>> * remove related code from the rest fuel projects (fuel-menu, fuel-devops,
>> fuel-qa).
>>
>>
>> Thank you
>>
>>
>> [1]
>> https://specs.openstack.org/openstack/fuel-specs/specs/7.0/fuel-bootstrap-on-ubuntu.html
>> [2]
>> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/dynamically-build-bootstrap.html
>> [3]
>> https://github.com/openstack/fuel-main/blob/master/packages/rpm/specs/fuel-bootstrap-image.spec
>> [4]
>> https://github.com/openstack/fuel-main/blob/master/bootstrap/module.mk#L12-L50
>> [5]
>> https://blueprints.launchpad.net/fuel/+spec/remove-centos-bootstrap-from-fuel
>> [6] https://review.openstack.org/#/c/273159/
>> [7]
>> https://review.openstack.org/#/q/topic:bp/remove-centos-bootstrap-from-fuel
>>
>>
>> --
>> Sergey
>> DevOps Engineer
>> IRC: SergK
>> Skype: Sergey_kul
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Igor Kalnitsky]

Roman P. wrote:
> Putting extra checks will create a more fool-proof but less configurable
> software. I’d vote for letting users shoot their feet using their plugins
> but making Fuel more flexible.

I won't agree here. You see, what if two plugins wants to override the
core network role? Consider that plugin A wants to extend VIPs:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip:
- name: "management"
  namespace: "haproxy"
# new VIP we want to add
- name: "myvip"
  namespace: "haproxy"

while plugin B wants to remove them:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip: []

How do you suppose to resolve this action? We don't know in which
order they will be resolved, and I'm strongly against unpredictable
situation (especiall it may be different time-to-time and depends on
which order plugins will be selected).

Moreover, it makes a little sense to try to resolve this situation. If
two plugins change something in core, they are probably incompatible.
Manual actions are required.

So that's, basically, why I think we should warn user about
incompatible changes to core stuff. Just like we do for deployment
tasks.

- igor

On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko  wrote:
> I would not check that. We are not talking about installing browser plugins
> when users may not know what they want. Putting extra checks will create a
> more fool-proof but less configurable software. I’d vote for letting users
> shoot their feet using their plugins but making Fuel more flexible.
>
>
> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
> написав(ла):
>
>> jsonpatch
>
> There were +1's regarding overriding VIPs above. I'd stick with that. It is
> done for tasks now. But we will need to check conflicts between plugins
> there (as for tasks).
>
>
> Aleksey Kasatkin
>
>
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:
>>
>> Frankly, I have not though about how to deal with multiple plugins yet.
>> However, what I think is that we must not restrict this too much and let
>> users configure it more flexibly even if it allows to shoot one’s foot.
>> Perhaps we can add a per-cluster priority for enabled plugins which users
>> can configure via UI, CLI or API. My other thought is that we should not
>> invent our own mechanics for changing a configuration and use an existing
>> one, say, jsonpatch. What do you guys think?
>>
>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>> please check it out. If it does not break anything, lets merge it ASAP.
>>
>> - romcheg
>>
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
>> написав(ла):
>>
>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>> what VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>> you cannot remove them this way.
>>
>> And the order of plugins processing is not defined so there is no warranty
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>>
>> The original goal, actually, was to remove VIPs for controllers (or for
>> some particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>>
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
>> wrote:
>>>
>>> > How are we handling this now for multiple plugins?
>>>
>>> OK, so right now we can only add VIPs to array, we can't remove them. So
>>> overriding would disable such possibility of adding VIPs from different
>>> plugins. But with [0] patch it will be still possible to add and to remove
>>> by providing empty array. But we'll have the problem with multiple plugins
>>> in such case.
>>> I've changed my mind :) I vote for leaving as in [0] since it's less
>>> destructive comparing to what we have now.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/273169/1
>>>
>>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko
>>>  wrote:

 Well, with merging instead of overriding, I believe, this problem with
 multiple plugins still exists, right? How are we handling this now for
 multiple plugins?
 Since VIPs is array I also vote for overriding, since merging it could
 be a pain (how do you remove existing element during array merge?).

 On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin
  wrote:
>
> Roman, please provide more details on how VIPs are overridden. And how
> do you deal with multiple plugins.
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin
>  wrote:
>>
>> Good idea, overally.
>>
>> How 

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

[Igor Kalnitsky]

Hey folks,

Simon P. wrote:
> 1. Run task X for plugin A (if installed).
> 2. Run task Y for plugin B (if installed).
> 3. Run task Z for plugin A (if installed).

Simon, could you please explain do you need this at the first place? I
can imagine this case only if your two plugins are kinda dependent on
each other. In this case, it's better to do what was said by Andrew W.
- set 'Task Y' to require 'Task X' and that requirement will be
satisfied anyway (even if Task X doesn't exist in the graph).


Alex S. wrote:
> Before we get rid of tasks.yaml can we provide a mechanism for plugin
> devs could leverage to have tasks executes at specific points in the
> deploy process.

Yeah, I think that may be useful sometime. However, I'd prefer to
avoid anchor usage as much as possible. There's no guarantees that
other plugin didn't make any destructive actions early, that breaks
you later. Anchors is good way to resolve possible conflicts, but they
aren't bulletproof.

- igor

On Thu, Jan 28, 2016 at 1:31 PM, Bogdan Dobrelya  wrote:
> On 27.01.2016 14:44, Simon Pasquier wrote:
>> Hi,
>>
>> I see that tasks.yaml is going to be deprecated in the future MOS
>> versions [1]. I've got one question regarding the ordering of tasks
>> between different plugins.
>> With tasks.yaml, it was possible to coordinate the execution of tasks
>> between plugins without prior knowledge of which plugins were installed [2].
>> For example, lets say we have 2 plugins: A and B. The plugins may or may
>> not be installed in the same environment and the tasks execution should be:
>> 1. Run task X for plugin A (if installed).
>> 2. Run task Y for plugin B (if installed).
>> 3. Run task Z for plugin A (if installed).
>>
>> Right now, we can set task priorities like:
>>
>> # tasks.yaml for plugin A
>> - role: ['*']
>>   stage: post_deployment/1000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_X.pp
>> puppet_modules: puppet/modules
>>
>> - role: ['*']
>>   stage: post_deployment/3000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Z.pp
>> puppet_modules: puppet/modules
>>
>> # tasks.yaml for plugin B
>> - role: ['*']
>>   stage: post_deployment/2000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Y.pp
>> puppet_modules: puppet/modules
>>
>> How would it be handled without tasks.yaml?
>
> I created a kinda related bug [0] and submitted a patch [1] to MOS docs
> [2] to kill some entropy on the topic of tasks schema roles versus
> groups and using wildcards for basic and custom roles from plugins as
> well. There is also a fancy picture to clarify things a bit. Would be
> nice to put more details there about custom stages as well!
>
> If plugins are not aware of each other, they cannot be strictly ordered
> like "to be the very last in the deployment" as one and only shall be
> so. That is why "coordinating the execution of tasks
> between plugins without prior knowledge of which plugins were installed"
> looks very confusing for me. Though, maybe wildcards with the "skipped"
> task type may help to organize things better?
>
> Perhaps the Fuel plugins team could answer the question better.
>
> [0] https://bugs.launchpad.net/fuel/+bug/1538982
> [1] https://review.fuel-infra.org/16509
> [2]
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
>
>>
>> Regards,
>> Simon
>>
>> [1] https://review.openstack.org/#/c/271417/
>> [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [All][Packetary][Fuel] New project: Packetary (Repository management library)

[Igor Kalnitsky]

Hey Bulat,

It's nice to hear that packetary finally got its own repo. However, I
took a look at roadmap [1] and wonder why do you plan to add
possibility to build RPM/DEB packages? It seems to me like it
shouldn't be packetary's concern, and I'd like to see packetary as
repo management tool, not a package build system. Each Linux
distributive came out with its own set of tools to build packages, and
that would be enough in my opinion. Maybe I'm wrong, though it'd be
nice to see your input here. :)

Thanks,
Igor





[1] https://wiki.openstack.org/wiki/Packetary/Roadmap

On Mon, Jan 25, 2016 at 10:25 AM, Bulat Gaifullin
 wrote:
> We are happy to introduce Packetary [0], which was separated from fuel-mirror 
> [1].
>
> Packetary provides flexible and data driven interface to manage (clone/build) 
> rpm/deb repos and packages (not implemented yet).
> Packetary provides object model and API.
> One can use this framework to implement operations like building repository 
> from a set of packages, clone repository, find package dependencies,
> mix repositories, pull out a subset of packages into a separate repository, 
> etc.
> Packetary is to be used either as a library to easily integrate it with 
> deployment tools and CI infrastructures and as CLI so a user can use it 
> manually or in shell scripts.
>
> In a nutshell Packetary is:
> * Common interface to various package repositories (rpm/deb).
> * Utility to build dependency graph for package(s).
> * Utility to create mirror/partial mirror of a repository according to 
> dependency graph.
>
> Thanks!
>
> [0] https://wiki.openstack.org/wiki/Packetary
> [1] https://github.com/openstack/fuel-mirror/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Stop deployment can break production cluster. How we should avoid it?

[Igor Kalnitsky]

Dmitry,

> We can mark a cluster 'operational' after successful deployment. And we
> can disable 'stop' button on this kind of clusters.

I think this is a best solution so far. Moreover, I don't know how to
fix it properly since there could be a lot of questions how this
button should behave at all.

Taking into account all this, I propose to solve this issue as a
blueprint (so we can think and cover all edge cases in the spec) or
drop stop button functionality at all.

The latest, perhaps, may be a good solution. I don't know how often
someone use Stop deployment.


Bogdan,

> This is the critical issue. The *worst* of possible situations for
> cluster operations. I believe this should be covered by a dedicated
> bulletin issued, the stop action shall be disabled for all releases as
> emergency fix, and fixed by next maintenance updates.

It wasn't always the case. Some time ago we didn't execute any tasks
on controllers when adding new nodes. It's become a case, I assume,
since Fuel 8.0, when we start executing netconfig and other puppet
task on each deployment run.

So we need to investigate in which release we have introduced
re-execution some tasks on controllers, and only then thinking about
bulletins.


Thanks,
Igor

On Fri, Jan 22, 2016 at 1:06 PM, Bogdan Dobrelya  wrote:
> On 22.01.2016 11:45, Dmitry Pyzhov wrote:
>> Guys,
>>
>> There is a tricky bug with our 'stop deployment'
>> feature: https://bugs.launchpad.net/fuel/+bug/1529691
>>
>> It cannot be fixed easily because it is a design flaw. By design we
>> cannot leave a node in unpredictable state. So we move all nodes that
>> are not in ready state back to bootstrap.
>>
>> But when user adding a node and deploying cluster system reruns puppet
>> on controllers. If user press 'stop' button controllers will be erased.
>> Cluster will be destroyed. Definitely this is not expected behaviour.
>
> This is the critical issue. The *worst* of possible situations for
> cluster operations. I believe this should be covered by a dedicated
> bulletin issued, the stop action shall be disabled for all releases as
> emergency fix, and fixed by next maintenance updates.
>
>>
>> Taking into account that we are going to rewrite this feature in 9.0 and
>> we are close to HCF there is no value in major changes for this feature
>> in 8.0. Let's do a simple workaround.
>>
>> We can mark a cluster 'operational' after successful deployment. And we
>> can disable 'stop' button on this kind of clusters.
>>
>> Any concerns or other proposals?
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] New gate jobs for 'fuel-agent' and 'python-fuelclient' packages

[Igor Kalnitsky]

Hey Dmitry -

That's cool, thank you. I wonder you build RPM or DEB or both?

- Igor

On Thu, Jan 21, 2016 at 12:48 PM, Dmitry Kaiharodsev
 wrote:
> Hi to all,
>
> please be informed that starting from today we're launching additional
> gating jobs [1] [2]:
>
> - for 'fuel-agent' package [3]
> - for 'python-fuelclient' package [4]
>
> Mentioned jobs will be started on each commit and will do following steps:
> - build packages from the commit
> - run system tests scenario [5] [6] with using created packages
> - vote in a patchset
>
> Job duration:
> - for 'fuel-agent' package - 20 min [7]
> - for 'python-fuelclient' package - 45 min [8]
>
> For any additional questions please use our #fuel-infra IRC channel
>
> [1]
> https://ci.fuel-infra.org/job/master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision/
> [2]
> https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/
> [3] https://github.com/openstack/fuel-agent
> [4] https://github.com/openstack/python-fuelclient
> [5] for 'fuel-agent' package
> https://github.com/openstack/fuel-qa/blob/master/gates_tests/tests/test_review_in_fuel_agent.py#L41-L48
> [6] for 'python-fuelclient' package
> https://github.com/openstack/fuel-qa/blob/master/gates_tests/tests/test_review_in_fuel_client.py#L102-L113
> [7]
> https://ci.fuel-infra.org/job/master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision/buildTimeTrend
> [8]
> https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/buildTimeTrend
> --
>
> Dmitry Kaigarodtsev
>
> IRC: dkaiharodsev
>
> __
> OpenStack Development Mailing 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] New gate jobs for 'fuel-agent' and 'python-fuelclient' packages

[Igor Kalnitsky]

Thanks. Any plans to add similar job for fuel-web?

On Thu, Jan 21, 2016 at 1:34 PM, Dmitry Kaiharodsev
<dkaiharod...@mirantis.com> wrote:
> Hi Igor,
>
> according to the script [1] - by default we're building RPM package,
> and if in a package repository exists 'debian' folder - trying to build DEB
> as well
>
> [1]
> https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/builders/build-pkgs.sh
>
> On Thu, Jan 21, 2016 at 12:51 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hey Dmitry -
>>
>> That's cool, thank you. I wonder you build RPM or DEB or both?
>>
>> - Igor
>>
>> On Thu, Jan 21, 2016 at 12:48 PM, Dmitry Kaiharodsev
>> <dkaiharod...@mirantis.com> wrote:
>> > Hi to all,
>> >
>> > please be informed that starting from today we're launching additional
>> > gating jobs [1] [2]:
>> >
>> > - for 'fuel-agent' package [3]
>> > - for 'python-fuelclient' package [4]
>> >
>> > Mentioned jobs will be started on each commit and will do following
>> > steps:
>> > - build packages from the commit
>> > - run system tests scenario [5] [6] with using created packages
>> > - vote in a patchset
>> >
>> > Job duration:
>> > - for 'fuel-agent' package - 20 min [7]
>> > - for 'python-fuelclient' package - 45 min [8]
>> >
>> > For any additional questions please use our #fuel-infra IRC channel
>> >
>> > [1]
>> >
>> > https://ci.fuel-infra.org/job/master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision/
>> > [2]
>> >
>> > https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/
>> > [3] https://github.com/openstack/fuel-agent
>> > [4] https://github.com/openstack/python-fuelclient
>> > [5] for 'fuel-agent' package
>> >
>> > https://github.com/openstack/fuel-qa/blob/master/gates_tests/tests/test_review_in_fuel_agent.py#L41-L48
>> > [6] for 'python-fuelclient' package
>> >
>> > https://github.com/openstack/fuel-qa/blob/master/gates_tests/tests/test_review_in_fuel_client.py#L102-L113
>> > [7]
>> >
>> > https://ci.fuel-infra.org/job/master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision/buildTimeTrend
>> > [8]
>> >
>> > https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.ubuntu.review_fuel_client/buildTimeTrend
>> > --
>> >
>> > Dmitry Kaigarodtsev
>> >
>> > IRC: dkaiharodsev
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>
>
>
>
> --
> Kind Regards,
> Dmitry Kaigarodtsev
> Fuel Ci Engineer
>
> IRC: dkaiharodsev
>
> __
> OpenStack Development Mailing 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] nova-network removal

[Igor Kalnitsky]

Roman, Sheena,

You meant to remove nova-network completely? Or only for new
environments? Should we support nova-network for old (let's say, 7.0)
clusters?

Thanks,
Igor

On Fri, Jan 15, 2016 at 10:03 PM, Sheena Gregson  wrote:
> Adrian – can someone from the PI team please confirm what testing was
> performed?
>
>
>
> From: Roman Alekseenkov [mailto:ralekseen...@mirantis.com]
> Sent: Friday, January 15, 2016 11:30 AM
>
>
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel] nova-network removal
>
>
>
> I agree with Sheena. Sounds like removing support for nova-network would be
> the best option, even though it's late.
>
>
>
> However, I'd like us to think about the impact on vCenter integration.
> vCenter+nova-network was fully supported before. Since we are now
> recommending DVS or NSX backends, I'd like the team to explicitly confirm
> that those configurations have been tested.
>
>
>
> Thanks,
>
> Roman
>
>
>
> On Fri, Jan 15, 2016 at 6:43 AM, Sheena Gregson 
> wrote:
>
> Although we are very close to HCF, I see no option but to continue removing
> nova-network as I understand it is not currently functional or well-tested
> for the Mitaka release.  We must either remove it or test it, and we want to
> remove it anyway so that seems like the better path.
>
>
>
> Mike, what do you think?
>
>
>
> From: Roman Prykhodchenko [mailto:m...@romcheg.me]
> Sent: Friday, January 15, 2016 8:04 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel] nova-network removal
>
>
>
> I’d like to add that nova-network support was removed from python-fuelclient
> in 8.0.
>
>
>
> 14 січ. 2016 р. о 17:54 Vitaly Kramskikh 
> написав(ла):
>
>
>
> Folks,
>
> We have a request on review which prohibits creating new envs with
> nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks away
> from HCF, and I think this is too late for such a change. What do you think?
> Should we proceed and remove nova-network support in 8.0, which is
> deprecated since 7.0?
>
>
> --
>
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing 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] How to auto allocate VIPs for roles in different network node groups?

[Igor Kalnitsky]

> Random choices aren't good IMHO, let's use defaults.

What if neither of node is in default group? Still use default group?
And prey that some third-party plugin will handle this case properly?

AFAIU, default nodegroup is slightly artificial thing. There's no such
thing like *default* nodegroup. Nodes may be in either group A or
group B. No defaults. Default is just pre-created nodegroup and that's
it, so there's nothing special in it. That's why I think it's bad idea
to remove limitation just because someone somewhere with manual hacks
and workaround *may* deploy controllers in different multi-racks. We
don't support load-balancing for nodes in different racks out-of-box.
Let's proceed with it for 8.0, and make a proper fix in 9.0.

On Fri, Jan 15, 2016 at 11:50 AM, Bogdan Dobrelya
 wrote:
> On 15.01.2016 10:19, Aleksandr Didenko wrote:
>> Hi,
>>
>> We need to come up with some solution for a problem with VIP generation
>> (auto allocation), see the original bug [0].
>>
>> The main problem here is: how do we know what exactly IPs to auto
>> allocate for VIPs when needed roles are in different nodegroups (i.e. in
>> different IP networks)?
>> For example 'public_vip' for 'controller' roles.
>>
>> Currently we have two possible solutions.
>>
>> 1) Fail early in pre-deployment check (when user hit "Deploy changes")
>> with error about inability to auto allocate VIP for nodes in different
>> nodegroups (racks). So in order to run deploy user has to put all roles
>> with the same VIPs in the same nodegroups (for example: all controllers
>> in the same nodegroup).
>>
>> Pros:
>>
>>   * VIPs are always correct, they are from the same network as nodes
>> that are going to use them, thus user simply can't configure invalid
>> VIPs for cluster and break deployment
>>
>> Cons:
>>
>>   * hardcoded limitation that is impossible to bypass, does not allow to
>> spread roles with VIPs across multiple racks even if it's properly
>> handled by Fuel Plugin, i.e. made so by design
>
> That'd be no good at all.
>
>>
>>
>> 2) Allow to move roles that use VIPs into different nodegroups, auto
>> allocate VIPs from "default" nodegroup and send an alert/notification to
>> user that such configuration may not work and it's up to user how to
>> proceed (either fix config or deploy at his/her own risk).
>
> It seems we have not much choice then, but use the option 2
>
>>
>> Pros:
>>
>>   * relatively simple solution
>>
>>   * impossible to break VIP serialization because in the worst case we
>> allocate VIPs from default nodegroup
>>
>> Cons:
>>
>>   * user can deploy invalid environment that will fail during deployment
>> or will not operate properly (for example when public_vip is not
>> able to migrate to controller from different rack)
>>
>>   * which nodegroup to choose to allocate VIPs? default nodegroup?
>> random pick? in case of random pick troubleshooting may become
>> problematic
>
> Random choices aren't good IMHO, let's use defaults.
>
>>
>>   * waste of IPs - IP address from the network range will be implicitly
>> allocated and marked as used, even it's not used by deployment
>> (plugin uses own ones)
>>
>>
>> *Please also note that this solution is needed for 8.0 only.*In 9.0 we
>> have new feature for manual VIPs allocation [1]. So in 9.0, if we can't
>> auto allocate VIPs for some cluster configuration, we can simply ask
>> user to manually set those problem VIPs or move roles to the same
>> network node group (rack).
>>
>> So, guys, please feel free to share your thoughts on this matter. Any
>> input is greatly appreciated.
>>
>> Regards,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1524320
>> [1] https://blueprints.launchpad.net/fuel/+spec/allow-any-vip
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] Diagnostic snapshot generation is broken due to lack of disk space

[Igor Kalnitsky]

Sheena -

What do you mean by *targeted*? Shotgun's designed to be a *targeted*
solution. If someone wants more *precise* targets - it's easy to
specify them in Nailgun's settings.yaml.

- Igor

On Fri, Jan 15, 2016 at 5:02 PM, Sheena Gregson <sgreg...@mirantis.com> wrote:
> I’ve also seen the request multiple times to be able to provide more
> targeted snapshots which might also (partially) solve this problem as it
> would require significantly less disk space to grab logs from a subset of
> nodes for a specific window of time, instead of the more robust grab-all
> solution we have now.
>
>
>
> From: Maciej Kwiek [mailto:mkw...@mirantis.com]
> Sent: Thursday, January 14, 2016 5:59 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken
> due to lack of disk space
>
>
>
> Igor,
>
>
>
> I will investigate this, thanks!
>
>
>
> Artem,
>
>
>
> I guess that if we have an untrusted user on master node, he could just put
> something he wants to be in the snapshot in /var/log without having to time
> the attack carefully with tar execution.
>
>
>
> I want to use links for directories, this saves me the trouble of creating
> hardlinks for every single file in the directory. Although with how
> exclusion is currently implemented it can cause deleting log files from
> original directories, need to check this out.
>
>
>
> About your PS: whole /var/log on master node (not in container) is currently
> downloaded, I think we shouldn't change this as we plan to drop containers
> in 9.0.
>
>
>
> Cheers,
>
> Maciej
>
>
>
> On Thu, Jan 14, 2016 at 12:32 PM, Artem Panchenko <apanche...@mirantis.com>
> wrote:
>
> Hi,
>
> using symlinks is a bit dangerous, here is a quote from the man you
> mentioned [0]:
>
>> The `--dereference' option is unsafe if an untrusted user can modify
>> directories while tar is running.
>
> Hard links usage is much safer, because you can't use them for directories.
> But at the same time implementation in shotgun would be more complicated
> than with symlinks.
>
> Anyway, in order to determine what linking to use we need to decide where
> (/var/log or another partition) diagnostic snapshot will be stored.
>
> p.s.
>
>>This doesn't really give us much right now, because most of the logs are
>> fetched from master node via ssh due to shotgun being run in mcollective
>> container
>
>
>
> AFAIK '/var/log/docker-logs/' is available from mcollective container and
> mounted to /var/log/:
>
> [root@fuel-lab-cz5557 ~]# dockerctl shell mcollective mount -l | grep
> os-varlog
> /dev/mapper/os-varlog on /var/log type ext4
> (rw,relatime,stripe=128,data=ordered)
>
> From my experience '/var/log/docker-logs/remote' folder is most ' heavy'
> thing in snapshot.
>
> [0] http://www.gnu.org/software/tar/manual/html_node/dereference.html
>
> Thanks!
>
>
>
> On 14.01.16 13:00, Igor Kalnitsky wrote:
>
> I took a glance on Maciej's patch and it adds a switch to tar command
>
> to make it follow symbolic links
>
> Yeah, that should work. Except one thing - we previously had fqdn ->
>
> ipaddr links in snapshots. So now they will be resolved into full
>
> copy?
>
>
>
> I meant that symlinks also give us the benefit of not using additional
>
> space (just as hardlinks do) while being able to link to files from
>
> different filesystems.
>
> I'm sorry, I got you wrong. :)
>
>
>
> - Igor
>
>
>
> On Thu, Jan 14, 2016 at 12:34 PM, Maciej Kwiek <mkw...@mirantis.com> wrote:
>
> Igor,
>
>
>
> I meant that symlinks also give us the benefit of not using additional space
>
> (just as hardlinks do) while being able to link to files from different
>
> filesystems.
>
>
>
> Also, as Barłomiej pointed out the `h` switch for tar should do the trick
>
> [1].
>
>
>
> Cheers,
>
> Maciej
>
>
>
> [1] http://www.gnu.org/software/tar/manual/html_node/dereference.html
>
>
>
> On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski
>
> <bpiotrow...@mirantis.com> wrote:
>
> Igor,
>
>
>
> I took a glance on Maciej's patch and it adds a switch to tar command to
>
> make it follow symbolic links, so it looks good to me.
>
>
>
> Bartłomiej
>
>
>
> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>
> wrote:
>
> Hey Maceij -
>
>
>
> About hardlinks - wouldn't it be better to use symlinks?
>
> This way we

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

[Igor Kalnitsky]

Hey Maceij -

> About hardlinks - wouldn't it be better to use symlinks?
> This way we don't occupy more space than necessary

AFAIK, hardlinks won't occupy much space. They are the links, after all. :)

As for symlinks, I'm afraid shotgun (and fabric underneath) won't
resolve them and links are get to snapshot As Is. That means if there
will be no content in the snapshot they are pointing to, they are
simply useless. Needs to be checked, though.

- Igor

On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek  wrote:
> Thanks for your insight guys!
>
> I agree with Oleg, I will see what I can do to make this work this way.
>
> About hardlinks - wouldn't it be better to use symlinks? This way we don't
> occupy more space than necessary, and we can link to files and directories
> that are in other block device than /var. Please see [1] review for a
> proposed change that introduces symlinks.
>
> This doesn't really give us much right now, because most of the logs are
> fetched from master node via ssh due to shotgun being run in mcollective
> container, but it's something! When we remove containers, this will prove
> more useful.
>
> Regards,
> Maciej Kwiek
>
> [1] https://review.openstack.org/#/c/266964/
>
> On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh  wrote:
>>
>> I think we need to find a way to:
>>
>> 1) verify the size of snapshot without actually making it and compare to
>> the available disk space beforehand.
>> 2) refuse to create snapshot if space is insufficient and notify user
>> (otherwise it breaks Admin node as we have seen)
>> 3) provide a way to prioritize elements of the snapshot and exclude them
>> based on the priorities or user choice.
>>
>> This will allow for better and safer UX with the snapshot.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek  wrote:
>>>
>>> Hi!
>>>
>>> I need some advice on how to tackle this issue. There is a bug [1]
>>> describing the problem with creating a diagnostic snapshot. The issue is
>>> that /var/log has 100GB available, while /var (where diagnostic snapshot is
>>> being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has
>>> 10GB available, so dumping the logs can be an issue when logs size exceed
>>> free space in /var.
>>>
>>> There are several things we could do, but I am unsure on which course to
>>> take. Should we
>>> a) Allocate more disk space for /var/www (or for whole /var)?
>>> b) Make the snapshot location share the diskspace of /var/log?
>>> c) Something else? What?
>>>
>>> Please share your thoughts on this.
>>>
>>> Cheers,
>>> Maciej Kwiek
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1529182
>>> [2]
>>> https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] Diagnostic snapshot generation is broken due to lack of disk space

[Igor Kalnitsky]

> I took a glance on Maciej's patch and it adds a switch to tar command
> to make it follow symbolic links

Yeah, that should work. Except one thing - we previously had fqdn ->
ipaddr links in snapshots. So now they will be resolved into full
copy?

> I meant that symlinks also give us the benefit of not using additional
> space (just as hardlinks do) while being able to link to files from
> different filesystems.

I'm sorry, I got you wrong. :)

- Igor

On Thu, Jan 14, 2016 at 12:34 PM, Maciej Kwiek <mkw...@mirantis.com> wrote:
> Igor,
>
> I meant that symlinks also give us the benefit of not using additional space
> (just as hardlinks do) while being able to link to files from different
> filesystems.
>
> Also, as Barłomiej pointed out the `h` switch for tar should do the trick
> [1].
>
> Cheers,
> Maciej
>
> [1] http://www.gnu.org/software/tar/manual/html_node/dereference.html
>
> On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski
> <bpiotrow...@mirantis.com> wrote:
>>
>> Igor,
>>
>> I took a glance on Maciej's patch and it adds a switch to tar command to
>> make it follow symbolic links, so it looks good to me.
>>
>> Bartłomiej
>>
>> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>>
>>> Hey Maceij -
>>>
>>> > About hardlinks - wouldn't it be better to use symlinks?
>>> > This way we don't occupy more space than necessary
>>>
>>> AFAIK, hardlinks won't occupy much space. They are the links, after all.
>>> :)
>>>
>>> As for symlinks, I'm afraid shotgun (and fabric underneath) won't
>>> resolve them and links are get to snapshot As Is. That means if there
>>> will be no content in the snapshot they are pointing to, they are
>>> simply useless. Needs to be checked, though.
>>>
>>> - Igor
>>>
>>> On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek <mkw...@mirantis.com>
>>> wrote:
>>> > Thanks for your insight guys!
>>> >
>>> > I agree with Oleg, I will see what I can do to make this work this way.
>>> >
>>> > About hardlinks - wouldn't it be better to use symlinks? This way we
>>> > don't
>>> > occupy more space than necessary, and we can link to files and
>>> > directories
>>> > that are in other block device than /var. Please see [1] review for a
>>> > proposed change that introduces symlinks.
>>> >
>>> > This doesn't really give us much right now, because most of the logs
>>> > are
>>> > fetched from master node via ssh due to shotgun being run in
>>> > mcollective
>>> > container, but it's something! When we remove containers, this will
>>> > prove
>>> > more useful.
>>> >
>>> > Regards,
>>> > Maciej Kwiek
>>> >
>>> > [1] https://review.openstack.org/#/c/266964/
>>> >
>>> > On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh <ogelb...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> I think we need to find a way to:
>>> >>
>>> >> 1) verify the size of snapshot without actually making it and compare
>>> >> to
>>> >> the available disk space beforehand.
>>> >> 2) refuse to create snapshot if space is insufficient and notify user
>>> >> (otherwise it breaks Admin node as we have seen)
>>> >> 3) provide a way to prioritize elements of the snapshot and exclude
>>> >> them
>>> >> based on the priorities or user choice.
>>> >>
>>> >> This will allow for better and safer UX with the snapshot.
>>> >>
>>> >> --
>>> >> Best regards,
>>> >> Oleg Gelbukh
>>> >>
>>> >> On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek <mkw...@mirantis.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi!
>>> >>>
>>> >>> I need some advice on how to tackle this issue. There is a bug [1]
>>> >>> describing the problem with creating a diagnostic snapshot. The issue
>>> >>> is
>>> >>> that /var/log has 100GB available, while /var (where diagnostic
>>> >>> snapshot is
>>> >>> being generated - /var/www/nailgun/dump/fuel-snapshot according to
>>> >>> [2]) has
>>> >>> 10GB available, so dumping the logs can be

Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Igor Kalnitsky]

Great New-Year gift! :D

On Thu, Dec 31, 2015 at 3:11 PM, Tatyana Leontovich
<tleontov...@mirantis.com> wrote:
> Artem has now been added to the fuel-qa-core group in gerrit.
>
> Congrats Artem!!
>
> On Thu, Dec 24, 2015 at 11:46 AM, Kyrylo Galanov <kgala...@mirantis.com>
> wrote:
>>
>> Hi,
>>
>> I am not QA engineer at all, but it is always a pleasure to work with
>> Artem. I would vote +1.
>>
>> --
>> Kyrylo
>>
>> On Wed, Dec 23, 2015 at 7:20 PM, Igor Marnat <imar...@mirantis.com> wrote:
>>>
>>> Folks,
>>> I'm not a fuel-qa core, but if I was, I'd vote with +1:)
>>>
>>> I'm really impressed with quality of analysis which Artem provides in bug
>>> reports and his overall help with bugs resolving. Keep going!
>>>
>>> Regards,
>>> Igor Marnat
>>>
>>> On Wed, Dec 23, 2015 at 8:05 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>>> wrote:
>>>>
>>>> Artem is doing a great job! Definitely +1.
>>>>
>>>> On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
>>>> <bgaiful...@mirantis.com> wrote:
>>>> > +1
>>>> >
>>>> > Regards,
>>>> > Bulat Gaifullin
>>>> > Mirantis Inc.
>>>> >
>>>> >
>>>> >
>>>> > On 23 Dec 2015, at 17:29, Aleksey Kasatkin <akasat...@mirantis.com>
>>>> > wrote:
>>>> >
>>>> > +1
>>>> >
>>>> > Aleksey Kasatkin
>>>> >
>>>> >
>>>> > On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko
>>>> > <adide...@mirantis.com>
>>>> > wrote:
>>>> >>
>>>> >> +1
>>>> >>
>>>> >> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich
>>>> >> <tleontov...@mirantis.com> wrote:
>>>> >>>
>>>> >>> Absolutely agree
>>>> >>>
>>>> >>> +1
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy
>>>> >>> <asledzins...@mirantis.com> wrote:
>>>> >>>>
>>>> >>>> Hi guys,
>>>> >>>> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>>>> >>>>
>>>> >>>> Artem has great technical expertise in fuel-qa and he developed a
>>>> >>>> lot of
>>>> >>>> vital parts of framework. His first place in a number of commits is
>>>> >>>> a good
>>>> >>>> proof of that.
>>>> >>>> His reviews are always thorough and consistent.
>>>> >>>> Please, vote for Artem!
>>>> >>>>
>>>> >>>> [0]
>>>> >>>>
>>>> >>>> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>>>> >>>>
>>>> >>>> --
>>>> >>>> Thanks,
>>>> >>>> Andrey Sledzinskiy
>>>> >>>> QA Engineer,
>>>> >>>> Mirantis, Kharkiv
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> __
>>>> >>>> OpenStack Development Mailing List (not for usage questions)
>>>> >>>> Unsubscribe:
>>>> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> >>>> http://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] Deadlocks and random test failures

[Igor Kalnitsky]

Hey Vitaly,

Are you the problem is in deadlock? I see the deadlock detecter
traceback, but not an actual deadlock.

I'm not sure could it be a reason for failure or not, it's better to
ask Alexander Kislitsky.

Thanks,
Igor

On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
 wrote:
> Hi,
>
> We have a long-living issue with deadlocks in nailgun which used to almost
> harmless and caused rare test failures. But test failures become more
> frequent and today there is ~20% probability that they will fail on a
> working code, which is really annoying. Moreover, a few weeks ago it started
> to affect UI functional tests: cluster reset task may hang, so this issue
> now may affect real deployments.
>
> I think we need to do something with it ASAP.
>
> --
> 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] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

Hey Tomasz -

I see that *packaging team* have decided to update PostgreSQL to 9.3
[1]. However, we aren't going to use PostgreSQL's JSON column for
VIPs, as it was pointed in the initial mail.

My IMO here - despite the fact PostgreSQL is cool and provides a lot
of useful feature, I'd prefer to be as DB-agnostic as possible.

Thanks,
Igor

[1] 
http://mirror.fuel-infra.org/mos-repos/centos/mos8.0-centos7-fuel/os/x86_64/Packages/

On Mon, Dec 28, 2015 at 11:53 PM, Tomasz Napierala
<tnapier...@mirantis.com> wrote:
> Hi,
>
> Just wondering what is fine result and decision? This change is pretty wide 
> and impacts many dev (and users), I think we should be listening to the 
> feedback before making any decision.
>
> Regards,
>
>
>> On 17 Dec 2015, at 11:01, Artem Silenkov <asilen...@mirantis.com> wrote:
>>
>> Hello!
>> We have merged 9.3 a week ago. From packaging team side downgrade is not an 
>> option and was made by mistake.
>> Regards
>> Artem Silenkov
>> ---
>> MOS-PAckaging
>>
>>
>> On Thu, Dec 17, 2015, 12:32 Oleg Gelbukh <ogelb...@mirantis.com> wrote:
>> In fact, it seems that 9.2 is in the mix since the introduction of centos7. 
>> Thus, all tests that have been made since then are made against 9.2. So, 
>> upgrading it to 9.3 actually is a change that has to be blocked by FF/SCF.
>>
>> Just my 2c.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Thu, Dec 17, 2015 at 12:13 PM, Evgeniy L <e...@mirantis.com> wrote:
>> Hi Andrew,
>>
>> It doesn't look fair at all to say that we use Postgres specific feature for 
>> no reasons
>> or as you said "just because we want".
>> For example we used Arrays which fits pretty well for our roles usage, which 
>> improved
>> readability and performance.
>> Or try to fit into relational system something like that [1], I don't think 
>> that we will get
>> a good result.
>>
>> P.S. sending a link to a holywar topic (schema vs schemaless), won't help to 
>> solve our
>> specific problem with Postgres downgrading vs keeping old (new) version.
>>
>> [1] 
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml
>>
>>
>> On Tue, Dec 15, 2015 at 10:53 PM, Andrew Maksimov <amaksi...@mirantis.com> 
>> wrote:
>> +1 to Igor suggestion to downgrade Postgres to 9.2. Our users don't work 
>> directly with Postgres, so there is no any deprecation of Fuel features.
>> Maintaining our own custom Postgres package just because we want "JSON 
>> column" is not a rational decision. Come on, fuel is not a billing system 
>> with thousands tables and special requirements to database. At least, we 
>> should try to keep it simple and avoid unnecessary complication.
>>
>> PS
>>  BTW, some people suggest to avoid using  json columns, read [1] PostgreSQL 
>> anti-patterns: unnecessary json columns.
>>
>> [1] - 
>> http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary-jsonhstore-dynamic-columns/
>>
>> Regards,
>> Andrey Maximov
>> Fuel Project Manager
>>
>>
>> On Tue, Dec 15, 2015 at 9:34 PM, Vladimir Kuklin <vkuk...@mirantis.com> 
>> wrote:
>> Folks
>>
>> Let me add my 2c here.
>>
>> I am for using Postgres 9.3. Here is an additional argument to the ones 
>> provided by Artem, Aleksandra and others.
>>
>> Fuel is being sometimes highly customized by our users for their specific 
>> needs. It has been Postgres 9.3 for a while and they might have as well 
>> gotten used to it and assumed by default that this would not change. So some 
>> of their respective features they are developing for their own sake may 
>> depend on Postgres 9.3 and we will never be able to tell the fraction of 
>> such use cases. Moreover, downgrading DBMS version of Fuel should be 
>> inevitably considered as a 'deprecation' of some features our software suite 
>> is providing to our users. This actually means that we MUST provide our 
>> users with a warning and deprecation period to allow them to adjust to these 
>> changes. Obviously, accidental change of Postgres version does not follow 
>> such a policy in any way. So I see no other ways except for getting back to 
>> Postgres 9.3.
>>
>>
>> On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com> 
>> wrote:
>> Hey Mike,
>>
>> Thanks for your input.
>>
>> > actually not.  if you replace your ARRAY columns with JSON entirely,
>>
>> It still nee

Re: [openstack-dev] [Fuel] Liberty naming in Fuel 8.0

[Igor Kalnitsky]

Hi Sergii,

You've raised an old thread started by Oleg G. once again [1]. Last
time we didn't reach any agreements, but I'm sure that it would be
better to change version into "liberty-8.0" instead of "2015.2.0-8.0".

What do you think? It could be done easily with two patches - one to
nalgun, and one to library. And we have to merge it at once, in order
to do not break BVT. We'll need to update Fuel ISO on Fuel CI also,
because otherwise deployment will fail (nailgun uses version as
building block for making path to puppet manifests).

Regards,
Igor

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077135.html

On Fri, Dec 25, 2015 at 12:59 AM, Sergii Golovatiuk
 wrote:
> Hi crew,
>
> Looking at our repositories I have found a lot of '2015.1.0' references.
> According to [1] Liberty has different versioning scheme. Should we change
> them to '2015.2.0' to meet [2]?
>
> [1] https://wiki.openstack.org/wiki/Liberty_Release_Schedule
> [2] https://wiki.openstack.org/wiki/Release_Naming
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> __
> OpenStack Development Mailing 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 Artem Roma for fuel-ostf core

[Igor Kalnitsky]

I believe fuel-ostf project needs a python dev to take care of
adapter. So +1 from my side.

P.S: I'm not a fuel-ostf core, but I think Dmitry S. doesn't show any
attention to this project. In order to maintain a high quality of
code, I'd consider to remove him from this group.

On Wed, Dec 23, 2015 at 5:28 PM, Aleksandr Didenko
 wrote:
> +1
>
> On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy
>  wrote:
>>
>> +1
>>
>> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich
>>  wrote:
>>>
>>> Hi guys,
>>> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>>>
>>> Artem  cares about fuel-ostf more then 2 years, always provide a great
>>> reviews(always thorough and consistent and comes in time), extend unit tests
>>> coverages and provide a lot of bug fixes and improvements there.
>>>
>>> Please, vote for Artem!
>>>
>>>
>>> http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Thanks,
>> Andrey Sledzinskiy
>> QA Engineer,
>> Mirantis, Kharkiv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://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 Artem Panchenko for fuel-qa core

[Igor Kalnitsky]

Artem is doing a great job! Definitely +1.

On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
 wrote:
> +1
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 23 Dec 2015, at 17:29, Aleksey Kasatkin  wrote:
>
> +1
>
> Aleksey Kasatkin
>
>
> On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko 
> wrote:
>>
>> +1
>>
>> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich
>>  wrote:
>>>
>>> Absolutely agree
>>>
>>> +1
>>>
>>>
>>>
>>>
>>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy
>>>  wrote:

 Hi guys,
 I'd like to nominate Artem Panchenko [0] for fuel-qa core.

 Artem has great technical expertise in fuel-qa and he developed a lot of
 vital parts of framework. His first place in a number of commits is a good
 proof of that.
 His reviews are always thorough and consistent.
 Please, vote for Artem!

 [0]
 http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa

 --
 Thanks,
 Andrey Sledzinskiy
 QA Engineer,
 Mirantis, Kharkiv


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

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

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according
to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

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

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.

Sheena, are you sure it works this way? Some time ago we didn't
support this. However, I fully support this idea and believe this is
the way to go. In this case the hypervisor entry could be called
something like  "Qemu (+ KVM if available)".


On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson <sgreg...@mirantis.com> wrote:
> We should collapse this into one entry - I don't have any preference on
> the naming convention, but as Fuel checks to see whether the hardware is
> capable of performing KVM acceleration, there's no reason to continue
> giving a selection to the user regarding KVM.
>
> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.  We
> should keep this behavior and make the entry a single KVM/QEMU selection
> to eliminate the false perception of choice (and the ability for users to
> select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> <ikalnit...@mirantis.com>
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
> VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
> Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
> OpenStack Development Mailing 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 Bulat Gaifulin for fuel-web & fuel-mirror cores

[Igor Kalnitsky]

Well, the agreement is reached. I added Bulat to both fuel-web-core
and fuel-mirror-core groups.

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

On Tue, Dec 15, 2015 at 11:49 AM, Evgeniy L <e...@mirantis.com> wrote:
> +1
>
> On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova
> <aurlap...@mirantis.com> wrote:
>>
>> +1
>>
>> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov <rvya...@mirantis.com>
>> wrote:
>>>
>>> +1
>>>
>>> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin
>>> <akasat...@mirantis.com> wrote:
>>>>
>>>> +1.
>>>>
>>>>
>>>> Aleksey Kasatkin
>>>>
>>>>
>>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov
>>>> <vshars...@mirantis.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> +1 from me to Bulat.
>>>>>
>>>>> On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky
>>>>> <ikalnit...@mirantis.com> wrote:
>>>>>>
>>>>>> Hi Fuelers,
>>>>>>
>>>>>> I'd like to nominate Bulat Gaifulin [1] for
>>>>>>
>>>>>> * fuel-web-core [2]
>>>>>> * fuel-mirror-core [3]
>>>>>>
>>>>>> Bulat's doing a really good review with detailed feedback and he's a
>>>>>> regular participant in IRC. He's co-author of packetary and
>>>>>> fuel-mirror projects, and he made valuable contribution to fuel-web
>>>>>> (e.g. task-based deployment engine).
>>>>>>
>>>>>> Fuel Cores, please reply back with +1/-1.
>>>>>>
>>>>>> - Igor
>>>>>>
>>>>>> [1] http://stackalytics.com/?module=fuel-web_id=bgaifullin
>>>>>> [2] http://stackalytics.com/report/contribution/fuel-web/90
>>>>>> [3] http://stackalytics.com/report/contribution/fuel-mirror/90
>>>>>>
>>>>>>
>>>>>> __
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

Hello,

Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
single entry point) for dealing with other hypervisors, including qemu
and kvm.

So it's kinda confusing, I'd prefer to find another solution.

Thanks,
Igor

On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M  wrote:
> I think it may be confusing to a fair number of the users you are targeting.
> libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
> saying libvirt makes people have to know that when you say libvirt you mean
> just the qemu/kvm that nova supports using the implementation detail of
> using libvirt.
>
> Thanks,
> Kevin
> 
> From: Aleksandr Didenko [adide...@mirantis.com]
> Sent: Friday, December 18, 2015 4:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on
> Wizard
>
> Hi,
>
> looks good to me.
>
> Regards,
> Alex
>
> On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych 
> wrote:
>>
>> Hi fuelers,
>>
>> We want to throw KVM/QEMU options from Wizard and instead of them leave
>> only one: Libvirt [0]. Libvirt option enables QEMU by default and there are
>> still be possibility to change it on KVM in settings. It looks more
>> logically because both QEMU\KVM are options for libvirt which manage them.
>>
>> What are you think about it?
>>
>> [0] https://review.openstack.org/#/c/258690
>>
>> __
>> OpenStack Development Mailing 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] Removal of support for nova-network

[Igor Kalnitsky]

I don't think it's a good idea to drop support of 7.0 nova-network
setup in 8.0. We should keep compatibility for at least one release.

On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin
 wrote:
> Sergii,
>
> We could remove it completely from nailgun if support for 7.0 and earlier is
> not required.
>
>
> Aleksey Kasatkin
>
>
> On Tue, Dec 22, 2015 at 3:27 AM, Sergii Golovatiuk
>  wrote:
>>
>> Hi,
>>
>> Finally we can deprecate nova-network ...
>> We should remove it from UI, nailgun logic and tests to have less
>> technical debt.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
>> wrote:
>>>
>>> Hey guys –
>>>
>>>
>>>
>>> I know this has been a topic of a lot of discussion – Adrian informed me
>>> on Friday that QA has confirmed the multi-hypervisor use case has been
>>> tested successfully without nova-network, so we can finally deprecate it!
>>>
>>>
>>>
>>> Users who want to deploy multiple hypervisors will need to use the Fuel
>>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and the
>>> KVM/QEMU computes can use Neutron + GRE/VXLAN.
>>>
>>>
>>>
>>> I’ve created a kind of “cover all the things” bug here:
>>> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
>>> nova-network right now in Fuel, I have marked it as Critical.
>>>
>>>
>>>
>>> Let’s start the conversation on here and make sure all the bases are
>>> covered – if additional bugs need to be logged or there’s administrative
>>> overhead, let me know and I’ll be happy to help out!
>>>
>>>
>>>
>>> Sheena Gregson | Sr. Product Manager | Mirantis
>>>
>>> p: +1 650 646 3302 | e: sgreg...@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 Development Mailing 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][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

What about hypervisor "Qemu", and checkbox option on Settings tab -
"Use KVM extension"?

On Mon, Dec 21, 2015 at 1:22 PM, Andrey Danin <ada...@mirantis.com> wrote:
> Hi,
>
> Let's call this hypervisor type "Qemu-KVM". So it will be a separate HV like
> vCenter, Xen, or HyperV. The actual selection between qemu and kvm will be a
> HV specific option in this case.
>
> On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hello,
>>
>> Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
>> single entry point) for dealing with other hypervisors, including qemu
>> and kvm.
>>
>> So it's kinda confusing, I'd prefer to find another solution.
>>
>> Thanks,
>> Igor
>>
>> On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>> > I think it may be confusing to a fair number of the users you are
>> > targeting.
>> > libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
>> > saying libvirt makes people have to know that when you say libvirt you
>> > mean
>> > just the qemu/kvm that nova supports using the implementation detail of
>> > using libvirt.
>> >
>> > Thanks,
>> > Kevin
>> > 
>> > From: Aleksandr Didenko [adide...@mirantis.com]
>> > Sent: Friday, December 18, 2015 4:16 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
>> > on
>> > Wizard
>> >
>> > Hi,
>> >
>> > looks good to me.
>> >
>> > Regards,
>> > Alex
>> >
>> > On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych
>> > <apopov...@mirantis.com>
>> > wrote:
>> >>
>> >> Hi fuelers,
>> >>
>> >> We want to throw KVM/QEMU options from Wizard and instead of them leave
>> >> only one: Libvirt [0]. Libvirt option enables QEMU by default and there
>> >> are
>> >> still be possibility to change it on KVM in settings. It looks more
>> >> logically because both QEMU\KVM are options for libvirt which manage
>> >> them.
>> >>
>> >> What are you think about it?
>> >>
>> >> [0] https://review.openstack.org/#/c/258690
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing 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
>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing 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][Bareon] Fuel & Bareon integration (fuel modularisation)

[Igor Kalnitsky]

> create Bareon-API repository, and start production ready implementation

For what reason do we need a separate repo? I thought API will be a
part of bareon repo. Or bareon is just a provisioning agent, which
will be driven by bareon-api?

On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L  wrote:
> Hi,
>
> Some time ago, we’ve started a discussion [0] about Fuel modularisation
> activity.
> Due to unexpected circumstances POC has been delayed.
>
> Regarding to partitioning/provisioning system, we have POC with a demo [1]
> (thanks to Sylwester), which shows how the integration of Fuel and Bareon
> [2] can
> be done.
>
> To summarise the implementation:
> * we have a simple implementation of Bareon-API [3], which stores
> partitioning
>   related data and allows to edit it
> * for Nailgun new extension has been implemented [4], which uses Bareon-API
>   to store partitioning information, so we will be able to easily switch
> between
>   classic volume_manager implementation and Bareon-API extension
> * when provisioning gets started, extensions retrieves the data from
> Bareon-API
>
> Next steps:
> * create Bareon-API repository, and start production ready implementation
> * create a spec for Fuel project
> * create a spec for Bareon project
>
> If you have any questions don’t hesitate to ask them in this thread, also
> you can
> find us on #openstack-bareon channel.
>
> Thanks!
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
> [1] https://www.youtube.com/watch?v=GTJM8i7DL0w
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
> [3] https://github.com/Mirantis/bareon-api
> [4] https://review.openstack.org/#/c/250864/
>
>
> __
> OpenStack Development Mailing 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][Ubuntu bootstrap] WebUI notification

[Igor Kalnitsky]

>  As I already told deployment was finished, but bootstrap wasn't built.

Bootstrap building *is* a part of master node deployment. If you guys
show "deployment is successful" before running building bootstrap,
then it's something you have to fix.


> Fuel deploying => WebUI blocked => deployment is failed due to some minor
> thing => I fix it => Ooops how can I activate WebUI

I see no problem here. You fix the problem, run deployment script
again and it unblocks everything for you. Usually it won't be enough
to fix something without re-running deployment, simply because a lot
of steps may be skipped due to the error.

> I really can't understand why is it bad to set error message by default

So far I can provide two reasons:

* What if user choose CentOS bootstrap? We ship it on ISO, so why do
we need to show error message?
* Nailgun should have good defaults, and showing error by default is
bad practice (it's something unrelated to Nailgun itself). Moreover,
it's a good practice to separate areas of responsibility, and it's
building script who's responsible to show and hide error message if
necessary.

- Igor


On Wed, Dec 16, 2015 at 3:31 PM, Artur Svechnikov
<asvechni...@mirantis.com> wrote:
>> We keep it As Is, and say "user should not use Fuel until Fuel
>> Master deployment is finished".
>
> Yep deployment can be finished, but was it successful? As I already told
> deployment was finished, but bootstrap wasn't built. Command for building
> bootstrap wasn't called because of some reason.
>
>> We make API / Web UI unaccessible externally until Fuel Master is
>> deployed (e.g. iptables rules or nginx ones).
>
> This approach seems too suspicious for me, due to the same reason as above.
> I can imagine some workflow: Fuel deploying => WebUI blocked => deployment
> is failed due to some minor thing => I fix it => Ooops how can I activate
> WebUI... But maybe I'm wrong, anyway this approach required serious change
> of nailgun by handling deployment process.
>
> I really can't understand why is it bad to set error message by default. By
> default before all deployment is not finished master hasn't any valid
> bootstrap image, hence this error message is not bad or weird, it's in right
> place. Error message will be disabled by fuel-bootstrap-cli after building,
> activation of bootstrap image.
>
> Best regards,
> Svechnikov Artur
>
> On Wed, Dec 16, 2015 at 4:05 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> > I really don't like setting the error message as the default one in
>> > the DB schema and consider it as a last resort solution. If
>> > possible update the message to error one just before you start
>> > to build the image.
>>
>> +1.
>>
>> > What about add some check or some message
>> > "Fuel-master Deployment in progress, please wait %s" ?
>>
>> I don't like this idea, since I believe it's something that user
>> shouldn't care at all. I see two possible *right* appraoch to handle
>> this:
>>
>> 1. We keep it As Is, and say "user should not use Fuel until Fuel
>> Master deployment is finished".
>> 2. We make API / Web UI unaccessible externally until Fuel Master is
>> deployed (e.g. iptables rules or nginx ones).
>>
>> What do you say?
>>
>> - Igor
>>
>> On Wed, Dec 16, 2015 at 12:00 PM, Aleksey Zvyagintsev
>> <azvyagint...@mirantis.com> wrote:
>> > Actually, its gloval problem :
>> > UI accessible for user earlier then deployment has been done. I think we
>> > should also handle this somehow - otherwise user can start doing "some
>> > things" like spawning HW - and fail .
>> > What about add some check or some message "Fuel-master Deployment  in
>> > progress, please wait %s" ?
>> >
>> >
>> >
>> >
>> > On Tue, Dec 15, 2015 at 6:56 PM, Vitaly Kramskikh
>> > <vkramsk...@mirantis.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I really don't like setting the error message as the default one in the
>> >> DB
>> >> schema and consider it as a last resort solution. If possible update
>> >> the
>> >> message to error one just before you start to build the image.
>> >>
>> >> 2015-12-15 18:48 GMT+03:00 Artur Svechnikov <asvechni...@mirantis.com>:
>> >>>
>> >>> Hi folks,
>> >>> Recently was introduced special notification about absented bootstrap
>> >>> image.
>> >>>
>> >>> C

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

> From what I understand, we are using 9.2 since the CentOS 7 switch. Can
> anyone point me to a bug caused by that?

AFAIK, there's no such bugs. Some folks have just *concerns*. Anyway,
it's up to packaging team to decide whether to package or not.

From Nailgun POV, I'd like to see classical RDBMS schemas as much as
possible, and do not rely on database backend and its version.

On Wed, Dec 16, 2015 at 11:30 AM, Bartłomiej Piotrowski
 wrote:
> On 2015-12-16 10:14, Bartłomiej Piotrowski wrote:
>> On 2015-12-16 08:23, Mike Scherbakov wrote:
>>> We could consider downgrading in Fuel 9.0, but I'd very carefully
>>> consider that. As Vladimir Kuklin said, there are may be other users who
>>> already rely on 9.3 for some of their enhancements.
>>
>> That will be way too late for that, as it will make upgrade procedure
>> more complicated. Given no clear upgrade path from 7.0 to 8.0, it sounds
>> like perfect opportunity to use what is provided by base distribution.
>> Are there actual users facilitating 9.3 features or is it some kind of
>> Invisible Pink Unicorn?
>>
>> Bartłomiej
>>
>
> I also want to remind that we are striving for possibility to let users
> do 'yum install fuel' (or apt) to make the magic happen. There is not
> much magic in requiring potential users to install specific PostgreSQL
> version because someone said so. It's either supporting the lowest
> version available (CentOS 7 – 9.2, Ubuntu 14.04 – 9.3, Debian Jessie –
> 9.4, openSUSE Leap – 9.4) or "ohai add this repo with our manually
> imported and rebuilt EPEL package".
>
> From what I understand, we are using 9.2 since the CentOS 7 switch. Can
> anyone point me to a bug caused by that?
>
> BP
>
> __
> OpenStack Development Mailing 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][Ubuntu bootstrap] WebUI notification

[Igor Kalnitsky]

> I really don't like setting the error message as the default one in
> the DB schema and consider it as a last resort solution. If
> possible update the message to error one just before you start
> to build the image.

+1.

> What about add some check or some message
> "Fuel-master Deployment in progress, please wait %s" ?

I don't like this idea, since I believe it's something that user
shouldn't care at all. I see two possible *right* appraoch to handle
this:

1. We keep it As Is, and say "user should not use Fuel until Fuel
Master deployment is finished".
2. We make API / Web UI unaccessible externally until Fuel Master is
deployed (e.g. iptables rules or nginx ones).

What do you say?

- Igor

On Wed, Dec 16, 2015 at 12:00 PM, Aleksey Zvyagintsev
 wrote:
> Actually, its gloval problem :
> UI accessible for user earlier then deployment has been done. I think we
> should also handle this somehow - otherwise user can start doing "some
> things" like spawning HW - and fail .
> What about add some check or some message "Fuel-master Deployment  in
> progress, please wait %s" ?
>
>
>
>
> On Tue, Dec 15, 2015 at 6:56 PM, Vitaly Kramskikh 
> wrote:
>>
>> Hi,
>>
>> I really don't like setting the error message as the default one in the DB
>> schema and consider it as a last resort solution. If possible update the
>> message to error one just before you start to build the image.
>>
>> 2015-12-15 18:48 GMT+03:00 Artur Svechnikov :
>>>
>>> Hi folks,
>>> Recently was introduced special notification about absented bootstrap
>>> image.
>>>
>>> Currently this notification is sent from fuel-bootstrap-cli. It means
>>> that error message will not be sent when failure occurs before first
>>> building (like in [1]). I think it will be better to set error message on
>>> WebUI by default through fixtures and then remove it if first build is
>>> successful.
>>>
>>> Please share your opinions about this issue.
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1526351
>>>
>>> Best regards,
>>> Svechnikov Artur
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>
>
>
> --
> ---
> Best regards,
>Aleksey Zvyagintsev
>
> __
> OpenStack Development Mailing 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] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

Hey Mike,

Thanks for your input.

> actually not.  if you replace your ARRAY columns with JSON entirely,

It still needs to fix the code, i.e. change ARRAY-specific queries
with JSON ones around the code. ;)

> there's already a mostly finished PR for SQLAlchemy support in the queue.

Does it mean SQLAlchemy will have one unified interface to make JSON
queries? So we can use different backends if necessary?

Thanks,
- Igor

On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer <mba...@redhat.com> wrote:
>
>
> On 12/15/2015 07:20 AM, Igor Kalnitsky wrote:
>> Hey Julien,
>>
>>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql
>>
>> I believe this blueprint is about DB for OpenStack cloud (we use
>> Galera now), while here we're talking about DB backend for Fuel
>> itself. Fuel has a separate node (so called Fuel Master) and we use
>> PostgreSQL now.
>>
>>> does that mean Fuel is only going to be able to run with PostgreSQL?
>>
>> Unfortunately we already tied up to PostgreSQL. For instance, we use
>> PostgreSQL's ARRAY column type. Introducing JSON column is one more
>> way to tighten knots harder.
>
> actually not.  if you replace your ARRAY columns with JSON entirely,
> MySQL has JSON as well now:
> https://dev.mysql.com/doc/refman/5.7/en/json.html
>
> there's already a mostly finished PR for SQLAlchemy support in the queue.
>
>
>
>>
>> - Igor
>>
>> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou <jul...@danjou.info> wrote:
>>> On Mon, Dec 14 2015, Igor Kalnitsky wrote:
>>>
>>>> The things I want to notice are:
>>>>
>>>> * Currently we aren't tied up to PostgreSQL 9.3.
>>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a
>>>> set of JSON operations.
>>>
>>> I'm curious and have just a small side question: does that mean Fuel is
>>> only going to be able to run with PostgreSQL?
>>>
>>> I also see
>>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql,
>>> maybe it's related?
>>>
>>> Thanks!
>>>
>>> --
>>> Julien Danjou
>>> // Free Software hacker
>>> // https://julien.danjou.info
>>
>> __
>> OpenStack Development Mailing 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] OpenStack versioning in Fuel

[Igor Kalnitsky]

Folks,

I want to bring this up again. There were no progress since last
Oleg's mail, and we must decide. It's good that we still have
"2015.1.0-8.0" version while OpenStack uses "Liberty" name for
versions.

Let's decide which name to use, file a bug and finally resolve it.

- Igor

On Thu, Oct 22, 2015 at 10:23 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote:
> Igor, it is interesting that you mention backward compatibility in this
> context.
>
> I can see lots of code in Nailgun that checks for release version to
> enable/disable features that were added or removed more than 2 releases
> before [1] [2] [3] (there's a lot more).
>
> What should we do about that code? I believe we could 'safely' delete it. It
> will make our code base much more compact and supportable without even
> decoupling serializers, etc. Is my assumption correct, or I just missing
> something?
>
> This will also help to switch to another scheme of versioning of releases,
> since there will be much less places where those version scheme is
> hardcoded.
>
> [1]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/release.py#L142-L145
> [2]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L554-L555
> [3]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Oct 19, 2015 at 6:34 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Oleg,
>>
>> I think we can remove this function for new releases and keep them
>> only for backward compatibility with previous ones. Why not? If
>> there's a way to do things better let's do them better. :)
>>
>> On Sat, Oct 17, 2015 at 11:50 PM, Oleg Gelbukh <ogelb...@mirantis.com>
>> wrote:
>> > In short, because of this:
>> >
>> > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/release.py#L74-L99
>> >
>> > Unless we use dashed 2-component version where OpenStack version comes
>> > first, followed by version of Fuel, this will break creation of a
>> > cluster
>> > with given release.
>> >
>> > -Oleg
>> >
>> > On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk
>> > <sgolovat...@mirantis.com> wrote:
>> >>
>> >> Why can't we use 'liberty' without 8.0?
>> >>
>> >> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelb...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> After closer look, the only viable option in closer term seems to be
>> >>> 'liberty-8.0' version. It does not to break comparisons that exist in
>> >>> the
>> >>> code and allows for smooth transition.
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Oleg Gelbukh
>> >>>
>> >>> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky
>> >>> <ikalnit...@mirantis.com>
>> >>> wrote:
>> >>>>
>> >>>> Oleg,
>> >>>>
>> >>>> Awesome! That's what I was looking for. :)
>> >>>>
>> >>>> - Igor
>> >>>>
>> >>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh <ogelb...@mirantis.com>
>> >>>> wrote:
>> >>>> > Igor,
>> >>>> >
>> >>>> > Got your question now. Coordinated point (maintenance) releases are
>> >>>> > dropped.
>> >>>> > [1] [2]
>> >>>> >
>> >>>> > [1]
>> >>>> >
>> >>>> > http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
>> >>>> > [2]
>> >>>> >
>> >>>> >
>> >>>> > https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
>> >>>> >
>> >>>> > --
>> >>>> > Best regards,
>> >>>> > Oleg Gelbukh
>> >>>> >
>> >>>> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky
>> >>>> > <ikalnit...@mirantis.com>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> Oleg,
>> >>>> >>
>> >>>> >> Yes, I know. Still you didn't answer my question - are they
>> >>>> >

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

FYI: so far (according to poll [1]) we have

* 11 votes for keeping 9.2
* 4 votes for restoring 9.3

[1] 
https://docs.google.com/spreadsheets/d/1RNcEVFsg7GdHIXlJl-6LCELhlwQ_zmTbd40Bk_jH1m4/edit?usp=sharing

On Tue, Dec 15, 2015 at 8:34 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote:
> Folks
>
> Let me add my 2c here.
>
> I am for using Postgres 9.3. Here is an additional argument to the ones
> provided by Artem, Aleksandra and others.
>
> Fuel is being sometimes highly customized by our users for their specific
> needs. It has been Postgres 9.3 for a while and they might have as well
> gotten used to it and assumed by default that this would not change. So some
> of their respective features they are developing for their own sake may
> depend on Postgres 9.3 and we will never be able to tell the fraction of
> such use cases. Moreover, downgrading DBMS version of Fuel should be
> inevitably considered as a 'deprecation' of some features our software suite
> is providing to our users. This actually means that we MUST provide our
> users with a warning and deprecation period to allow them to adjust to these
> changes. Obviously, accidental change of Postgres version does not follow
> such a policy in any way. So I see no other ways except for getting back to
> Postgres 9.3.
>
>
> On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hey Mike,
>>
>> Thanks for your input.
>>
>> > actually not.  if you replace your ARRAY columns with JSON entirely,
>>
>> It still needs to fix the code, i.e. change ARRAY-specific queries
>> with JSON ones around the code. ;)
>>
>> > there's already a mostly finished PR for SQLAlchemy support in the
>> > queue.
>>
>> Does it mean SQLAlchemy will have one unified interface to make JSON
>> queries? So we can use different backends if necessary?
>>
>> Thanks,
>> - Igor
>>
>> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer <mba...@redhat.com> wrote:
>> >
>> >
>> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote:
>> >> Hey Julien,
>> >>
>> >>>
>> >>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql
>> >>
>> >> I believe this blueprint is about DB for OpenStack cloud (we use
>> >> Galera now), while here we're talking about DB backend for Fuel
>> >> itself. Fuel has a separate node (so called Fuel Master) and we use
>> >> PostgreSQL now.
>> >>
>> >>> does that mean Fuel is only going to be able to run with PostgreSQL?
>> >>
>> >> Unfortunately we already tied up to PostgreSQL. For instance, we use
>> >> PostgreSQL's ARRAY column type. Introducing JSON column is one more
>> >> way to tighten knots harder.
>> >
>> > actually not.  if you replace your ARRAY columns with JSON entirely,
>> > MySQL has JSON as well now:
>> > https://dev.mysql.com/doc/refman/5.7/en/json.html
>> >
>> > there's already a mostly finished PR for SQLAlchemy support in the
>> > queue.
>> >
>> >
>> >
>> >>
>> >> - Igor
>> >>
>> >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou <jul...@danjou.info>
>> >> wrote:
>> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote:
>> >>>
>> >>>> The things I want to notice are:
>> >>>>
>> >>>> * Currently we aren't tied up to PostgreSQL 9.3.
>> >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a
>> >>>> set of JSON operations.
>> >>>
>> >>> I'm curious and have just a small side question: does that mean Fuel
>> >>> is
>> >>> only going to be able to run with PostgreSQL?
>> >>>
>> >>> I also see
>> >>>
>> >>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql,
>> >>> maybe it's related?
>> >>>
>> >>> Thanks!
>> >>>
>> >>> --
>> >>> Julien Danjou
>> >>> // Free Software hacker
>> >>> // https://julien.danjou.info
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.op

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

Hey Julien,

> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql

I believe this blueprint is about DB for OpenStack cloud (we use
Galera now), while here we're talking about DB backend for Fuel
itself. Fuel has a separate node (so called Fuel Master) and we use
PostgreSQL now.

> does that mean Fuel is only going to be able to run with PostgreSQL?

Unfortunately we already tied up to PostgreSQL. For instance, we use
PostgreSQL's ARRAY column type. Introducing JSON column is one more
way to tighten knots harder.

- Igor

On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou <jul...@danjou.info> wrote:
> On Mon, Dec 14 2015, Igor Kalnitsky wrote:
>
>> The things I want to notice are:
>>
>> * Currently we aren't tied up to PostgreSQL 9.3.
>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a
>> set of JSON operations.
>
> I'm curious and have just a small side question: does that mean Fuel is
> only going to be able to run with PostgreSQL?
>
> I also see
> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql,
> maybe it's related?
>
> Thanks!
>
> --
> Julien Danjou
> // Free Software hacker
> // https://julien.danjou.info

__
OpenStack Development Mailing 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] Ways to improve plugin links handling in 9.0

[Igor Kalnitsky]

Hey Vitaly,

I agree that having a lot of logic (receiving auth token, creating
payload and doing post request) in RPM post_install section is a huge
overhead, and definitely it's not a way to go. We have to find better
solution, and I think it should be done declaratively (via some YAML).

Moreover, I'd like to see the same approach for cluster's dashboard. I
see no reason why YAML + custom formatting wouldn't be enough.

- Igor

On Tue, Dec 15, 2015 at 11:53 AM, Vitaly Kramskikh
 wrote:
> Hi,
>
> As you may know, in Fuel 8.0 we've implemented blueprint
> external-dashboard-links-in-fuel-dashboard. It will allow plugins to add
> links to their dashboards to the Fuel UI after deployment. As link
> construction logic could be rather complex (what IP should be used -
> public_vip or a separate public IP, should HTTPS be used, etc), we decided
> to create a new API handler with auth exepmtion for POST requests
> (/api/clusters/:id/plugin_links), which should be used from post-deployment
> tasks of plugins. Relative links (without a protocol and a hostname) are
> treated relative to public_vip (or SSL hostname in case of enabled SSL for
> Horizon). Here are the examples of such post-deployment tasks: for absolute
> url and for relative url. For me this approach was designed during 7.0
> development cycle and looks fine to me and some other python developers.
>
> But by the end of the development cycle the we figured out that we also need
> to cover the case for plugins which install their dashboard on the master
> node. We decided to go with the same approach and add same API handler for
> plugins (/api/plugins/:id/plugin_links), but without auth exemption. It
> should be used from post_install.sh script to create links. But the logic of
> the script appeared to be pretty complex:
>
> It needs to fork (as post_install is run before the plugin registration
> process)
> It needs to extract login/password from /etc/fuel/astute.yaml to access API
> (so in case they are outdated this approach won't work; it won't also be
> possible to request actual credentials from the user as it's a fork)
> It needs to obtain a new Keystone token
> Using this token, it should poll /api/plugins and look for the plugin with
> the needed name until it appears (after registration process)
> After the plugin is registered, script should construct a url using the
> found id and send a POST request to add a link.
>
> Registering a plugin-level link shouldn't be that complex and we need to
> think for a better approach. Do you have any ideas?
>
> I have one: unlike cluster-level links, plugin-level links don't need custom
> construction logic as they are always relative to the master node IP and use
> the same protocol, so that they can be specified in plugin metadata. We also
> can use metadata describe cluster-level links in 2 most frequent cases:
> relative to public_vips (Horizon plugins case) and for plugins which provide
> only one role with public_ip_required=true and limits.max=1 (monitoring
> solutions case). For more complex cases plugins will still use the API to
> create the links manually.
>
>
> --
> 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] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

Artem -

> PostgreSQL-9.2 will reach end-of-life at September 2017 according to [0].

Python 2.7 will reach end-of-life at the beginning of 2020. However,
we don't drop Python 2.7 and don't start using Python 3.5 instead.

Moreover we aren't going to have CentOS 7 forever. I believe either
new CentOS will be released or they will update PostgreSQL package. So
it's all about support one-more-package by packaging team (what I'm
trying to avoid).

> 9.2 is slightly incompatible with 9.3, according to [1]

Nice catch, thank you. However, we don't backup database as
PostgreSQL's binaries. We use SQL-based backup, and we use psql client
to restore it (not pg_upgrade). So there should be no problems.

> Shared memory usage is different between 9.2 and 9.3 and this could
> bring some troubles and would require config file reworking.

AFAIK, we use default settings (no custom configs). But that must be checked.


On Tue, Dec 15, 2015 at 2:23 PM, Artem Silenkov <asilen...@mirantis.com> wrote:
> Hello!
>
> I got another few points against downgrading.
>
> 1. PostgreSQL-9.2 will reach end-of-life at September 2017 according to [0].
> With high probability it means that we will have 9.2 version in centos repos
> when fuel9.0 arrives.
> It means that we will have to repackage it anyway just later a little bit.
>
> 2. 9.2 is slightly incompatible with 9.3, according to [1].
> Downgrading is not an easy task,pg_dump, pg_restore from different package
> versions can't work together.
>
> 3. Shared memory usage is different between 9.2 and 9.3 and this could bring
> some troubles and would require config file reworking.
>
>
> [0]: http://www.postgresql.org/support/versioning/
> [1]: http://www.postgresql.org/docs/9.3/static/release-9-3.html
>
> Offtopic sorry for this ->
> If we want to reduce number of package we maintain we should start from ruby
> Eg.
> Gems we use are deprecated like 5 years ago and bring to the table a lot of
> efforts repackaging unsupported software.
>
> Regards,
>
> Artem Silenkov
> ---
> MOS-Packaging
>
> On Tue, Dec 15, 2015 at 1:28 PM, Julien Danjou <jul...@danjou.info> wrote:
>>
>> On Mon, Dec 14 2015, Igor Kalnitsky wrote:
>>
>> > The things I want to notice are:
>> >
>> > * Currently we aren't tied up to PostgreSQL 9.3.
>> > * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a
>> > set of JSON operations.
>>
>> I'm curious and have just a small side question: does that mean Fuel is
>> only going to be able to run with PostgreSQL?
>>
>> I also see
>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql,
>> maybe it's related?
>>
>> Thanks!
>>
>> --
>> Julien Danjou
>> // Free Software hacker
>> // https://julien.danjou.info
>>
>> __
>> OpenStack Development Mailing 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] Separate master node provisioning and deployment

[Igor Kalnitsky]

Vladimir,

Thanks for raising this question. I totally support idea of separating
provisioning and deployment steps. I believe it'll simplify a lot of
things.

However I have some comments regarding this topic, see them inline. :)

> For a package it is absolutely normal to throw a user dialog.

It kills idea of fuel-menu, since each package will need to implement
configuration menu of its own. Moreover, having such configuration
menu in fuel-menu and in each package is too expensive, it will
require more effort that I'd like to have.

> Fuel package could install default astute.yaml (I'd like to rename it
> into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the
> file by default not running fuelmenu

I don't like idea of having one common configuration file for Fuel
components. I think it'd be better when each component (subproject)
has its own configuration file, and knows nothing about external ones.

Meantime we can provide fuel-menu which will become a configuration
gate for different subprojects. Perhaps we could consider to use
pluggable approach, so each component will export plugin for fuel-menu
with own settings.

> What is wrong with 'deployment script' approach?

The wrong thing is that with such approach it would be impossible to
setup Fuel with just something like

$ yum install fuel

In my opinion we should go into the following approach:

* yum install fuel
* fuel-menu

The first command should install a basic Fuel setup, and everything
should work when it's done.

While the second one prompts a configuration menu where one might
change default settings (reconfigure default installation).

Thanks,
Igor

On Mon, Dec 14, 2015 at 9:30 AM, Vladimir Kozhukalov
 wrote:
> Oleg,
>
> Thanks a lot for your opinion. Here are some more thoughts on this topic.
>
> 1) For a package it is absolutely normal to throw a user dialog. But
> probably there is kind of standard for the dialog that does not allow to use
> fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial [0]
> how to get user input during post install. I don't know if there is such a
> standard for RPM packages. In some MLs it is written that any command line
> program could be run in %post section including those like fuel-menu.
>
> 2) Fuel package could install default astute.yaml (I'd like to rename it
> into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the file
> by default not running fuelmenu. A user then is supposed to run fuelmenu if
> he/she needs to re-configure fuel installation. However, it is gonna be
> quite intrusive. What if a user installs fuel and uses it for a while with
> default configuration. What if some clusters are already in use and then the
> user decides to re-configure the master node. Will it be ok?
>
> 3) What is wrong with 'deployment script' approach? Why can not fuel just
> install kind of deployment script? Fuel is not a service, it consists of
> many components. Moreover some of these components could be optional (not
> currently but who knows?), some of this components could be run on an
> external node (after all Fuel components use REST, AMQP, XMLRPC to interact
> with each other).
> Imagine you want to install OpenStack. It also consists of many components.
> Some components like database or AMQP service could be deployed using HA
> architecture. What if one needs Fuel to be run with external HA database,
> amqp? From this perspective I'd say Fuel package should not exist at all.
> Let's maybe think of Fuel package as a convenient way to deploy Fuel on a
> single node, i.e single node deployment script.
>
> 4) If Fuel is just a deployment script, then I'd say we should not run any
> post install dialog. Deployment script is to run this dialog (fuelmenu) and
> then run puppet. IMO it sounds reasonable.
>
>
> [0] http://www.fifi.org/doc/debconf-doc/tutorial.html
>
> Vladimir Kozhukalov
>
> On Fri, Dec 11, 2015 at 11:14 PM, Oleg Gelbukh 
> wrote:
>>
>> For the package-based deployment, we need to get rid of 'deployment
>> script' whatsoever. All configuration stuff should be done in package specs,
>> or by the user later on (maybe via some fuelmenu-like lightweight UI, or via
>> WebUI).
>>
>> Thus, fuel package must install everything that is required for running
>> base Fuel as it's dependencies (or dependencies of it's dependencies, as it
>> could be more complicated with cross-deps between our components).
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov
>>  wrote:
>>>
>>> Dear colleagues,
>>>
>>> At the moment part of the Fuel master deployment logic is located in ISO
>>> kickstart file, which is bad. We'd better carefully split provisioning and
>>> deployment stages so as to install base operating system during provisioning
>>> stage and then everything else on the deployment stage. That would make it
>>> possible to deploy 

[openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Igor Kalnitsky]

Hi Fuelers,

As you might know, recently we moved to CentOS 7 and as a result we
got a small regression with PostgreSQL:

* Fuel 7 runs on CentOS 6.6 and uses  manually built PostgreSQL 9.3.
* Fuel 8 runs on CentOS 7 and uses PostgreSQL 9.2 from CentOS upstream repos.

There are different opinions whether this regression is acceptable or
not (see details in bug [1]).

The things I want to notice are:

* Currently we aren't tied up to PostgreSQL 9.3.
* There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a
set of JSON operations.

So the question is: Should we drop compatibility with upstream CentOS
7 in favor of using new features of PostgreSQL?

I've prepared a small poll, so please vote [3].

My opinion here is that I don't like that we're going to build and
maintain one more custom package (just take a look at this patch [4]
if you don't believe me), but I'd like to hear more opinion here.

Thanks,
Igor

[1] https://bugs.launchpad.net/fuel/+bug/1523544
[2] https://review.openstack.org/#/c/249656/
[3] http://goo.gl/forms/Hk1xolKVP0
[4] https://review.fuel-infra.org/#/c/14623/

__
OpenStack Development Mailing 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] Separate master node provisioning and deployment

[Igor Kalnitsky]

> One of potential disadvantages is that it is harder to track package 
> dependencies, but I think
> a deployment script should be a root of the package dependency tree.

That's something I'd try to avoid. Let's be close to distro upstream
practice. I never saw something like "fuel-deploy" that runs puppet
that runs package installation. You usually install packages you want
to use. If you want to use something beyond default distribution, you
install some additional optional packages and that's it.

On Mon, Dec 14, 2015 at 3:21 PM, Vladimir Kozhukalov
<vkozhuka...@mirantis.com> wrote:
>> Meantime we can provide fuel-menu which will become a configuration
>> gate for different subprojects. Perhaps we could consider to use
>> pluggable approach, so each component will export plugin for fuel-menu
>> with own settings.
>
> fuel-menu could be a configuration gate for fuel deployment script
>
>> The wrong thing is that with such approach it would be impossible to
>> setup Fuel with just something like
>
>>$ yum install fuel
>
> I see nothing wrong here. 'yum install fuel' would be appropriate approach
> if fuel was a service,
> not a bunch of services some of which are not even limited to be installed
> on the master node.
>
> when you run
>
> # yum install fuel
> # fuel-menu
>
> it the same as you run
>
> # yum install fuel
> # fuel_deploy_script (which runs fuel-menu and then runs puppet which
> installs everything else)
>
> I like the idea when fuel (let's rename it into fuel-deploy) package
> provides just a deployment script.
> It does not require a lot of changes and it corresponds to what we really
> do. Besides, it is more flexible
> because deployment could be modular (several stages).
>
> One of potential disadvantages is that it is harder to track package
> dependencies, but I think
> a deployment script should be a root of the package dependency tree.
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Dec 14, 2015 at 12:53 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Vladimir,
>>
>> Thanks for raising this question. I totally support idea of separating
>> provisioning and deployment steps. I believe it'll simplify a lot of
>> things.
>>
>> However I have some comments regarding this topic, see them inline. :)
>>
>> > For a package it is absolutely normal to throw a user dialog.
>>
>> It kills idea of fuel-menu, since each package will need to implement
>> configuration menu of its own. Moreover, having such configuration
>> menu in fuel-menu and in each package is too expensive, it will
>> require more effort that I'd like to have.
>>
>> > Fuel package could install default astute.yaml (I'd like to rename it
>> > into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the
>> > file by default not running fuelmenu
>>
>> I don't like idea of having one common configuration file for Fuel
>> components. I think it'd be better when each component (subproject)
>> has its own configuration file, and knows nothing about external ones.
>>
>> Meantime we can provide fuel-menu which will become a configuration
>> gate for different subprojects. Perhaps we could consider to use
>> pluggable approach, so each component will export plugin for fuel-menu
>> with own settings.
>>
>> > What is wrong with 'deployment script' approach?
>>
>> The wrong thing is that with such approach it would be impossible to
>> setup Fuel with just something like
>>
>> $ yum install fuel
>>
>> In my opinion we should go into the following approach:
>>
>> * yum install fuel
>> * fuel-menu
>>
>> The first command should install a basic Fuel setup, and everything
>> should work when it's done.
>>
>> While the second one prompts a configuration menu where one might
>> change default settings (reconfigure default installation).
>>
>> Thanks,
>> Igor
>>
>> On Mon, Dec 14, 2015 at 9:30 AM, Vladimir Kozhukalov
>> <vkozhuka...@mirantis.com> wrote:
>> > Oleg,
>> >
>> > Thanks a lot for your opinion. Here are some more thoughts on this
>> > topic.
>> >
>> > 1) For a package it is absolutely normal to throw a user dialog. But
>> > probably there is kind of standard for the dialog that does not allow to
>> > use
>> > fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial
>> > [0]
>> > how to get user input during post install. I don't know if there is such
>> > a
>> > stand

[openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

[Igor Kalnitsky]

Hi Fuelers,

I'd like to nominate Bulat Gaifulin [1] for

* fuel-web-core [2]
* fuel-mirror-core [3]

Bulat's doing a really good review with detailed feedback and he's a
regular participant in IRC. He's co-author of packetary and
fuel-mirror projects, and he made valuable contribution to fuel-web
(e.g. task-based deployment engine).

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

- Igor

[1] http://stackalytics.com/?module=fuel-web_id=bgaifullin
[2] http://stackalytics.com/report/contribution/fuel-web/90
[3] http://stackalytics.com/report/contribution/fuel-mirror/90

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

Re: [openstack-dev] [Fuel] Multiple repos UX

[Igor Kalnitsky]

Hey folks -

+1 from my side on the idea of having the unified repo format. It will
simplify a cross-project contribution. I think we can file a blueprint
for 9.0.

I have only two questions to discuss:

* We need to declare format for RPM repos either.
* Shouldn't we use slightly different set of fields for flat Debian repos?

- Igor

On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev  wrote:
> Hello Vladimir,
>
> I definitely agree that using one uri for generating number of repos is not
> the best solution.
> According to Fuel Menu - there was the discussion in gerrit [1] about
> repositories format. The first version of my patch implements actually your
> idea about equality and independence of repositories. It meets disagreements
> and no one voted for this POV. So I had to change the implementation in
> favor to the current version.
>
> According to this situation I would like to discuss if proposed changes are
> needed before making new patch. Guys, who took part in the previous patch
> discussion, please share your opinions.
>
> [1] https://review.openstack.org/#/c/242646/
>
> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov :
>>
>> Dear colleagues,
>>
>> At the moment we have several places where we configure multiple rpm/deb
>> repositories. Those are:
>>
>> Web UI (cluster settings tab) where we define repos for cluster deployment
>> Fuel-menu (bootstrap section) where we define repos for building ubuntu
>> bootstrap image
>> Fuel-mirror where we define repos that are to be cloned (full or partial
>> mirrors)
>>
>> I'd prefer all these places to provide the same UX. By that I mean that
>> these components should use the same input data structure like this [0],
>> i.e. a flat list of fully independent repositories (see an example below).
>> First repo in the list is supposed to be a base OS repo (i.e. contains base
>> packages like libc).
>>
>> [
>>  {
>> type: deb,
>> url: some-url,
>> section: some-section,
>> suite: some-suite,
>> priority: some-priority
>>   },
>>   {
>> type: deb,
>> url: another-url,
>> section: another-section,
>> suite: another-suite,
>> priority: another-priority
>>   },
>> ...
>> ]
>>
>> I'd like to focus on the fact that these repositories should be defined
>> independently (no base url, no base suite, etc.) That makes little sense to
>> speculate about consistency of a particular repository. We only should talk
>> about consistency of the whole list of repositories together.
>>
>> I'll try to explain. In the real world we usually deal with sets of
>> repositories which look like this:
>>
>> http://archive.ubuntu.com/ubuntu/dists/trusty/
>> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/
>> http://archive.ubuntu.com/ubuntu/dists/trusty-security/
>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/
>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/
>> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/
>>
>> As you can see these repositories have common hosts and base suites and it
>> instills us to think that repositories should not be defined separately
>> which is wrong. This special case does not break the whole approach. It is
>> just a special case. Repositories are nothing more than just sets of
>> packages that can depend on each other forming a tree when taken together.
>> Package relation does matter, not repository location, not suite name.
>> Parsing package tree for a set of repositories we can easily figure out
>> whether this set is consistent or not (e.g. python-packetary allows to do
>> this).
>>
>> Taking into account the above, I'd say UI should allow a user to define
>> repositories independently not forcing to use special patterns like suite +
>> suite-updates + suite-security, not forcing repositories to be located on
>> the same host. That means we should modify fuel-menu bootstrap section which
>> currently allows a user to define a base url that is then used to form a
>> group of repos (base, base-updates, base-security). Besides, it contradicts
>> to our use case when we put mosX.Y locally on the master node while
>> mosX.Y-updates and mosX.Y-security are supposed to be available online.
>>
>> What do you guys think of that?
>>
>>
>> [0]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
>>
>>
>> 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
>>
>
>
>
> --
> Kind Regards,
> Fedor Zhadaev
>
> Skype: zhadaevfm
> IRC: fzhadaev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [Fuel] Multiple repos UX

[Igor Kalnitsky]

> Do we really need a custom format? Why can not we use native format
> for yum.conf and apt.sources files

Because we don't want to parse this format each time we want to verify
/ handle particular component of this format. Moreover, there's no,
for example, priority in Debian repo format. Priority is used by apt
preference (not by repo itself).

We're talking about Fuel internal representation, and it would be nice
to have one internal format across various Fuel projects.


> But UI, in my opinion, should follow practices that already exist, not define 
> something new.

AFAIU, the idea is to unified internal representation and keep UI as
close to distributive standards.

On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova
<afedor...@mirantis.com> wrote:
> Hi,
>
> I agree with the idea of unification for repo configurations, but it
> looks like we are developing yet another standard.
>
> Do we really need a custom format? Why can not we use native format
> for yum.conf and apt.sources files, and native tooling (all those
> python bindings, cli utils and so on) which is already developed to
> work with them?
>
> On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky <ikalnit...@mirantis.com> 
> wrote:
>> Hey folks -
>>
>> +1 from my side on the idea of having the unified repo format. It will
>> simplify a cross-project contribution. I think we can file a blueprint
>> for 9.0.
>>
>> I have only two questions to discuss:
>>
>> * We need to declare format for RPM repos either.
>> * Shouldn't we use slightly different set of fields for flat Debian repos?
>>
>> - Igor
>>
>> On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev <fzhad...@mirantis.com> 
>> wrote:
>>> Hello Vladimir,
>>>
>>> I definitely agree that using one uri for generating number of repos is not
>>> the best solution.
>>> According to Fuel Menu - there was the discussion in gerrit [1] about
>>> repositories format. The first version of my patch implements actually your
>>> idea about equality and independence of repositories. It meets disagreements
>>> and no one voted for this POV. So I had to change the implementation in
>>> favor to the current version.
>>>
>>> According to this situation I would like to discuss if proposed changes are
>>> needed before making new patch. Guys, who took part in the previous patch
>>> discussion, please share your opinions.
>>>
>>> [1] https://review.openstack.org/#/c/242646/
>>>
>>> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <vkozhuka...@mirantis.com>:
>>>>
>>>> Dear colleagues,
>>>>
>>>> At the moment we have several places where we configure multiple rpm/deb
>>>> repositories. Those are:
>>>>
>>>> Web UI (cluster settings tab) where we define repos for cluster deployment
>>>> Fuel-menu (bootstrap section) where we define repos for building ubuntu
>>>> bootstrap image
>>>> Fuel-mirror where we define repos that are to be cloned (full or partial
>>>> mirrors)
>>>>
>>>> I'd prefer all these places to provide the same UX. By that I mean that
>>>> these components should use the same input data structure like this [0],
>>>> i.e. a flat list of fully independent repositories (see an example below).
>>>> First repo in the list is supposed to be a base OS repo (i.e. contains base
>>>> packages like libc).
>>>>
>>>> [
>>>>  {
>>>> type: deb,
>>>> url: some-url,
>>>> section: some-section,
>>>> suite: some-suite,
>>>> priority: some-priority
>>>>   },
>>>>   {
>>>> type: deb,
>>>> url: another-url,
>>>> section: another-section,
>>>> suite: another-suite,
>>>> priority: another-priority
>>>>   },
>>>> ...
>>>> ]
>>>>
>>>> I'd like to focus on the fact that these repositories should be defined
>>>> independently (no base url, no base suite, etc.) That makes little sense to
>>>> speculate about consistency of a particular repository. We only should talk
>>>> about consistency of the whole list of repositories together.
>>>>
>>>> I'll try to explain. In the real world we usually deal with sets of
>>>> repositories which look like this:
>>>>
>>>> http://archive.ubuntu.com/ubuntu/dists/trusty/
>>>> http://archive.ubuntu.com/ubuntu/d

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

[Igor Kalnitsky]

Mike -

I'm not a fuel-docs core, so it's up to fuel-docs-core team to remove
*dead* cores. According to Stackalytics [1] Irina Povolotskaya's
showing a low contribution rate. Regarding Vitaly, I don't know why
Stackalytics marks him as core, since he's not a member of gerrit core
group [2].

- Igor

P.S: I'm not sure what to do with fuel-mirror, fuel-menu and
network-checker repos. They are quite new, not so many patches were
submitted here, so I decided to wait for a while.

[1] http://stackalytics.com/report/contribution/fuel-docs/90
[2] https://review.openstack.org/#/admin/groups/657,members

On Fri, Dec 11, 2015 at 7:11 AM, Mike Scherbakov
<mscherba...@mirantis.com> wrote:
> Igor, thank you for driving this. I think that this is a great practice: we
> need to keep list of cores up to date.
>
> What about other repos, not mentioned here? Are those are fine being as is?
> What about fuel-docs, for instance?
>
> For instance, I see that Irina was able to provide just 5 reviews over 3
> month period [1]. So I suspect that she can't pay that much of an attention
> to docs now..
> Vitaly Kramskikh had 3 reviews, but I don't think is core in that particular
> repo (he is core in fuel-web repo). I'm not sure how stackalytics tracks
> that.
>
> [1] http://stackalytics.com/report/contribution/fuel-docs/90
>
> Thanks,
>
> On Thu, Dec 10, 2015 at 8:12 AM Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hi Evgeniy,
>>
>> Yes, you absolutely right! I as far as possible will ask them to
>> review certain patches (if they have no time to watch all patches_.
>> Moreover, I'm going to add them to MAINTAINERS file.
>>
>> Thanks,
>> Igor
>>
>> P.S: I hope you and others will manage to spend more time on Fuel,
>> since your feedback guys are really appreciated since you're proven
>> authorities here. ;)
>>
>>
>> On Thu, Dec 10, 2015 at 5:59 PM, Evgeniy L <e...@mirantis.com> wrote:
>> > Hi,
>> >
>> > Thank you Igor for cleaning core related groups.
>> >
>> > Also I would like to add that many of removed cores are still SME
>> > (subject
>> > matter experts)
>> > in specific areas, so they will continue reviewing related patches.
>> >
>> > Thanks,
>> >
>> > On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky
>> > <ikalnit...@mirantis.com>
>> > wrote:
>> >>
>> >> Hey folks,
>> >>
>> >> In an effort to do some housekeeping, I clean up the list of core
>> >> reviewers in Fuel.
>> >>
>> >> According to Stackalytics the following cores show a low contribution
>> >> rate:
>> >>
>> >> # fuel-web [1]
>> >>
>> >> * Dmitry Shulyak
>> >> * Evgeniy L
>> >>
>> >> # python-fuelclient [2]
>> >>
>> >> * Dmitry Pyzhov
>> >> * Evgeniy L
>> >>
>> >> # shotgun [3]
>> >>
>> >> * Dmitry Shulyak
>> >> * Evgeniy L
>> >>
>> >> # fuel-upgrade [4]
>> >>
>> >> * Aleksey Kasatkin
>> >> * Vladimir Kozhukalov
>> >>
>> >> # fuel-main [5]
>> >>
>> >> * Dmitry Pyzhov
>> >> * Roman Vyalov
>> >>
>> >> # fuel-agent [6]
>> >>
>> >> * Aleksey Kasatkin
>> >> * Evgeniy L
>> >> * Igor Kalnitsky
>> >>
>> >> Also, I've removed Sebastian Kalinowski as he said he has no time to
>> >> work on Fuel anymore.
>> >>
>> >> Once former cores show high level of contribution again, I'll gladly
>> >> add them back.
>> >>
>> >> - Igor
>> >>
>> >> [1] http://stackalytics.com/report/contribution/fuel-web/90
>> >> [2] http://stackalytics.com/report/contribution/python-fuelclient/90
>> >> [3] http://stackalytics.com/report/contribution/shotgun/90
>> >> [4] http://stackalytics.com/report/contribution/fuel-upgrade/90
>> >> [5] http://stackalytics.com/report/contribution/fuel-main/90
>> >> [6] http://stackalytics.com/report/contribution/fuel-agent/90
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:u

[openstack-dev] [Fuel] Christmas Core Cleanup

[Igor Kalnitsky]

Hey folks,

In an effort to do some housekeeping, I clean up the list of core
reviewers in Fuel.

According to Stackalytics the following cores show a low contribution rate:

# fuel-web [1]

* Dmitry Shulyak
* Evgeniy L

# python-fuelclient [2]

* Dmitry Pyzhov
* Evgeniy L

# shotgun [3]

* Dmitry Shulyak
* Evgeniy L

# fuel-upgrade [4]

* Aleksey Kasatkin
* Vladimir Kozhukalov

# fuel-main [5]

* Dmitry Pyzhov
* Roman Vyalov

# fuel-agent [6]

* Aleksey Kasatkin
* Evgeniy L
* Igor Kalnitsky

Also, I've removed Sebastian Kalinowski as he said he has no time to
work on Fuel anymore.

Once former cores show high level of contribution again, I'll gladly
add them back.

- Igor

[1] http://stackalytics.com/report/contribution/fuel-web/90
[2] http://stackalytics.com/report/contribution/python-fuelclient/90
[3] http://stackalytics.com/report/contribution/shotgun/90
[4] http://stackalytics.com/report/contribution/fuel-upgrade/90
[5] http://stackalytics.com/report/contribution/fuel-main/90
[6] http://stackalytics.com/report/contribution/fuel-agent/90

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

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

[Igor Kalnitsky]

Hi Evgeniy,

Yes, you absolutely right! I as far as possible will ask them to
review certain patches (if they have no time to watch all patches_.
Moreover, I'm going to add them to MAINTAINERS file.

Thanks,
Igor

P.S: I hope you and others will manage to spend more time on Fuel,
since your feedback guys are really appreciated since you're proven
authorities here. ;)


On Thu, Dec 10, 2015 at 5:59 PM, Evgeniy L <e...@mirantis.com> wrote:
> Hi,
>
> Thank you Igor for cleaning core related groups.
>
> Also I would like to add that many of removed cores are still SME (subject
> matter experts)
> in specific areas, so they will continue reviewing related patches.
>
> Thanks,
>
> On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>>
>> Hey folks,
>>
>> In an effort to do some housekeeping, I clean up the list of core
>> reviewers in Fuel.
>>
>> According to Stackalytics the following cores show a low contribution
>> rate:
>>
>> # fuel-web [1]
>>
>> * Dmitry Shulyak
>> * Evgeniy L
>>
>> # python-fuelclient [2]
>>
>> * Dmitry Pyzhov
>> * Evgeniy L
>>
>> # shotgun [3]
>>
>> * Dmitry Shulyak
>> * Evgeniy L
>>
>> # fuel-upgrade [4]
>>
>> * Aleksey Kasatkin
>> * Vladimir Kozhukalov
>>
>> # fuel-main [5]
>>
>> * Dmitry Pyzhov
>> * Roman Vyalov
>>
>> # fuel-agent [6]
>>
>> * Aleksey Kasatkin
>> * Evgeniy L
>> * Igor Kalnitsky
>>
>> Also, I've removed Sebastian Kalinowski as he said he has no time to
>> work on Fuel anymore.
>>
>> Once former cores show high level of contribution again, I'll gladly
>> add them back.
>>
>> - Igor
>>
>> [1] http://stackalytics.com/report/contribution/fuel-web/90
>> [2] http://stackalytics.com/report/contribution/python-fuelclient/90
>> [3] http://stackalytics.com/report/contribution/shotgun/90
>> [4] http://stackalytics.com/report/contribution/fuel-upgrade/90
>> [5] http://stackalytics.com/report/contribution/fuel-main/90
>> [6] http://stackalytics.com/report/contribution/fuel-agent/90
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"

[Igor Kalnitsky]

Hey Dmitry,

Despite the fact the feature promises performance boost (IIUC) and
it's really nice to have it, I agree with Mike's opinion - it's late
to continue working on features. Each delay means less time to test
it, and we need to focus on quality.

I'm sorry, but I have to say "No" on requested exception.

- Igor

On Tue, Dec 8, 2015 at 9:55 AM, Mike Scherbakov
 wrote:
> Hi Dmitry,
> as much as I support the change, and glad that we got time for it, my
> opinion is that we should not extend a FFE. I have following reasons to
> think this way:
>
> 1) Feature Freeze is time based milestone, with the rational "FF ensures
> that sufficient share of the ReleaseCycle is dedicated to QA, until we
> produce the first release candidates. Limiting the changes that affect the
> behavior of the software allow for consistent testing and efficient
> bugfixing" [1]. Even though this feature will be disabled by default, it is
> important to note the first part of this rationale - we need to focus on
> stability now, not on features.
> 2) 7 FFEs for Fuel [2] I'd subjectively consider as high number, as in total
> there are ~25 major blueprints to be delivered. Dmitry, our PTL,
> unfortunately is absent for a couple of weeks, but his opinion is quite
> similar: "The list of exceptions is much longer than I'd like, and some have
> larger impact than I'd like, lets all of us make sure we don't come to
> regret granting these exceptions." [3]. Taking any exception further means
> moving FF, in fact. That means moving of release date, which I don't think
> we should even consider doing.
> 3) Exception to exception, in my opinion, should only be allowed in
> extremely rare cases for essential features only. When it becomes clear that
> the whole release has a major gap or serious issue, which can only be
> resolved by finishing an essential feature. I have no evidence to think that
> this functionality, which will be disabled by default, can fall into this
> category.
> 4) Changeset [4] has a change to the packaging spec. Any small change to
> packaging after FF imposes additional risk, as there is no good test
> automation for such kind of changes. Even if it's just include of a new
> file. In case of regression, we may easily lose a day for figuring out what
> is wrong and reverting a change.
>
> I'd like to hear component leads while PTL is absent these days
>
> [1] https://wiki.openstack.org/wiki/FeatureFreeze
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081149.html
> [4] https://review.openstack.org/#/c/249180/
>
> On Mon, Dec 7, 2015 at 2:30 PM Adam Heczko  wrote:
>>
>> Hello Dmitry,
>> I like this idea and very much appreciate it.
>> +1 from me :)
>>
>> A.
>>
>> On Mon, Dec 7, 2015 at 9:48 PM, Dmitry Mescheryakov
>>  wrote:
>>>
>>> Hello folks,
>>>
>>> I'd like to request extension of current FFE for the feature [1]. During
>>> the three FFE days we merged the spec [2] after big discussion and made a
>>> couple iterations over the implementation [3]. We had a chat with Bogdan on
>>> how to progress and here are the action items still need to be done:
>>>  * part of the change responsible for RabbitMQ policy need to be
>>> upstreamed first to RabbitMQ repo.
>>>  * the change needs to be review and merged by our library folks.
>>>
>>> Overall I think that 2-3 more days should be enough to finish it.
>>>
>>> What do you think folks?
>>>
>>> Dmitry
>>>
>>> [1]
>>> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc
>>> [2] https://review.openstack.org/247517
>>> [3] https://review.openstack.org/249180
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Adam Heczko
>> Security Engineer @ 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
>
> --
> 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

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

[Igor Kalnitsky]

Hey Andrii,

I'm totally agree with you about contribution guides, except one thing
- we need and should force users to split huge patches into set of
small ones. Mostly because it will simplify support and review of
patches. Previously we ignored this rule pretty often, and get a lot
of troubles due to buggy code.

Also, see some comments below.

> So, when an author of a patch gets -1 with the statement «split this
> code», I believe it is not constructive. At least you should roughly
> describe how you see it, how the patch could be split, you should be
> helpful to the author of a patch.

No one is suggesting to set -1 without leaving a comment how the patch
could be divided.


> If you are not sure how the improved code would look like, just let it go!

What if you're not sure how the improved code should look like, but
you definitely sure that it shouldn't look like proposed one? :)

I'd say it's a good reason to set -1 and start discussion. Not only
with author, but with other folks, since everyone in community is
responsible of code quality of the project.

- I

On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov  wrote:
> I believe this is against the code review guidelines.
>
> «Comments must be meaningful and should help an author to change the
> code the right way.» [1]
>
> If you get a comment that says «split this change into the smaller
> commit» I'm sorry, but it doesn't help at all.
>
> «Leave constructive comments
>
> Not everyone in the community is a native English speaker, so make
> sure your remarks are meaningful and helpful for the patch author to
> change his code, but also polite and respectful.
>
> The review is not really about the score. It's all about the
> comments. When you are reviewing code, always make sure that your
> comments are useful and helpful to the author of the patch. Try to
> avoid leaving comments just to show that you reviewed something if
> they don't really add anything meaningful» [2]
>
> So, when an author of a patch gets -1 with the statement «split this
> code», I believe it is not constructive. At least you should roughly
> describe how you see it, how the patch could be split, you should be
> helpful to the author of a patch. So, first of all, you need to review
> the patch! :)
>
> I want to emphasize this: «The review is not really about the
> score. It's all about the comments.»
>
> «In almost all cases, a negative review should be accompanied by clear
> instructions for the submitter how they might fix the patch.» [4]
>
> I believe that the statement "split this change into the smaller
> commit" is too generic, it is mostly the same as the "this patch needs
> further work". It doesn't bring any additional instructions how
> exactly a patch could be fixed.
>
> Please also take a loot at the following conversation from mailing
> list: [3].
>
> «It's not so easy to guess what you mean, and in case of a clumsy
> piece of code, not even that certain that better code can be used
> instead. So always provide an example of what you would rather want to
> see. So instead of pointing to indentation rules, just show properly
> indented code. Instead of talking about grammar or spelling, just type
> the corrected comment or docstring. Finally, instead of saying "use
> list comprehension here" or "don't use has_key", just type your
> proposal of how the code should look like. Then we have something
> concrete to talk about. Of course, you can also say why you think this
> is better, but an example is very important. If you are not sure how
> the improved code would look like, just let it go, chances are it
> would look even worse.» [3]
>
> So, please, bring something concrete to talk about. If you are not
> sure how the improved code would look like, just let it go!
>
> «The simplest way to talk about code is to just show the code. When you
> want the author to fix something, rewrite it in a different way,
> format the code differently, etc. -- it's best to just write in the
> comment how you want that code to look like. It's much faster than
> having the author guess what you meant in your descriptions, and also
> lets us learn much faster by seeing examples.» [2]
>
>
> [1]
> https://docs.google.com/document/d/1tyKhHQRQqTEW6tS7_LCajEpzqn55f-f5nDmtzIeJ2uY/edit
> [2] https://wiki.openstack.org/wiki/CodeReviewGuidelines
> [3]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html
> [4] http://docs.openstack.org/infra/manual/developers.html#peer-review
>
>
> Best regards,
> Andrey Tykhonov (tkhno)
>
>
> __
> OpenStack Development Mailing 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)

Re: [openstack-dev] [Fuel] FFE for Ubuntu bootstrap

[Igor Kalnitsky]

Hey Dmitry,

I'm ok with FFE till Tuesday. Moreover, it makes sense to do so in
order to reduce affection on CentOS 7 patches.

- Igor

On Thu, Dec 3, 2015 at 8:58 PM, Dmitry Klenov  wrote:
> Hi folks,
>
> Let me clarify the situation with Ubuntu bootstrap feature.
>
> First of all, I would like to highlight that all functional commits for this
> feature were merged. This means that starting from yesterday everyone has an
> ability to switch to Ubuntu-based bootstrap manually and start using it. So
> I do not see the risk in loosing testing cycles in the community.
>
> The item which brought concerns on today status meeting was the enablement
> of the feature by default. To do it, 2 patches have to be merged together:
> * https://review.openstack.org/#/c/250662/ - main switch.
> * https://review.openstack.org/#/c/251908/ - compatibility commit to QA
> suite to comply with new bootstrap config format.
>
> I would like to raise the question if we can have a feature freeze exception
> for these 2 patches?
>
> There are a couple of reasons why I consider it safer to merge these patches
> several days later:
> * There is a bug caught today which will block the tests to pass if we
> switch to Ubuntu bootstrap by default:
> https://bugs.launchpad.net/fuel/+bug/1522406
> * There were concerns that a lot of FF commit merges can bring instability
> to QA suite. So it might be reasonable not to bring one more variable right
> now and to enable ubuntu bootstrap by default when all automated tests are
> stabilized.
>
> I would like to ask engineering and QA leads to express their ideas on this.
>
> Thanks,
> Dmitry.
>
> __
> OpenStack Development Mailing 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] Dropping python2.6 compatibility

[Igor Kalnitsky]

> shouldn't we switch tests to work with python2.7 instead of python2.6?

Currently we run tests using both py26 and py27, see the

* gate-fuel-web-python27 (openstack infra)
* verify-fuel-web-py27 (fuel infra)

So the question is should we drop py26 jobs? I think yes, we should..
but once CentOS 7 is merged.

I want to notice that, the py26 gate has been removed from openstack
infra in this patch [1] and due to this bug [2].

Honestly, I have no idea why there were no discussions regarding this
=/ it looks like Alex Kislitsky is issue reporter.

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

- I

On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger  wrote:
> On 2015-12-03 11:21, Evgeniy L wrote:
>>
>> Hi,
>>
>> During Fuel master migration to CentOS7 there was found a problem that
>> tests
>> get failed [0] for python2.6
>>
>> As far as I can see it's a common practise to drop python2.6
>> compatibility [1],
>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>
>> It looks like fuelclient will be an exception, because clients continue
>> supporting
>> python2.6 [1]
>
>
> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
> no 2.6 gates anymore since yesterday.
>
> As mentioned already, we're disabling python 2.6 everywhere.
>
> Patch to remove it from nearly all repos including fuel is at
> https://review.openstack.org/#/c/252448/
>
> Andreas
>
>> Thanks,
>>
>> [0] https://review.openstack.org/#/c/251120/
>> [1]
>>
>> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing 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] Dropping python2.6 compatibility

[Igor Kalnitsky]

> possible to have a working py26 CI for the duration
> of Centos 7 migration (or keep it even after that)

I'd prefer to drop py26 as well as py27 from Fuel CI. We have
openstack gating, that should be more than enough. :)

Fuel CI should be kept for running Fuel UI tests.

On Thu, Dec 3, 2015 at 1:17 PM, Igor Belikov <ibeli...@mirantis.com> wrote:
> Just want to make a couple of things clear:
>
> 1. Openstack-Infra is dropping py26 jobs support, as Andreas said,
> so once https://review.openstack.org/#/c/252448/ is merged all openstack 
> projects
> (including Fuel, of course) won’t have py26 gates.
>
> 2. We still run py26 tests on Fuel-CI side and don’t plan to drop them along 
> with
> OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the 
> duration
> of Centos 7 migration (or keep it even after that).
>
>> On 03 Dec 2015, at 13:49, Igor Kalnitsky <ikalnit...@mirantis.com> wrote:
>>
>>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>
>> Currently we run tests using both py26 and py27, see the
>>
>> * gate-fuel-web-python27 (openstack infra)
>> * verify-fuel-web-py27 (fuel infra)
>>
>> So the question is should we drop py26 jobs? I think yes, we should..
>> but once CentOS 7 is merged.
>>
>> I want to notice that, the py26 gate has been removed from openstack
>> infra in this patch [1] and due to this bug [2].
>>
>> Honestly, I have no idea why there were no discussions regarding this
>> =/ it looks like Alex Kislitsky is issue reporter.
>>
>> [1] https://review.openstack.org/#/c/249242/
>> [2] https://bugs.launchpad.net/fuel/+bug/1519371
>>
>> - I
>>
>> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger <a...@suse.com> wrote:
>>> On 2015-12-03 11:21, Evgeniy L wrote:
>>>>
>>>> Hi,
>>>>
>>>> During Fuel master migration to CentOS7 there was found a problem that
>>>> tests
>>>> get failed [0] for python2.6
>>>>
>>>> As far as I can see it's a common practise to drop python2.6
>>>> compatibility [1],
>>>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>>>
>>>> It looks like fuelclient will be an exception, because clients continue
>>>> supporting
>>>> python2.6 [1]
>>>
>>>
>>> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
>>> no 2.6 gates anymore since yesterday.
>>>
>>> As mentioned already, we're disabling python 2.6 everywhere.
>>>
>>> Patch to remove it from nearly all repos including fuel is at
>>> https://review.openstack.org/#/c/252448/
>>>
>>> Andreas
>>>
>>>> Thanks,
>>>>
>>>> [0] https://review.openstack.org/#/c/251120/
>>>> [1]
>>>>
>>>> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> --
>>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>>   HRB 21284 (AG Nürnberg)
>>>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] Feature Freeze is soon

[Igor Kalnitsky]

Sheena,

Yeah, we will have a meeting in #fuel-dev IRC channel. :)

- Igor

On Wed, Dec 2, 2015 at 4:25 PM, Sheena Gregson  wrote:
> Is the meeting at 8am PST today?
>
>
>
> From: Mike Scherbakov [mailto:mscherba...@mirantis.com]
> Sent: Wednesday, December 02, 2015 1:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel] Feature Freeze is soon
>
>
>
> In order to be effective, I created an etherpad to go over:
>
> https://etherpad.openstack.org/p/8.0-features-status
>
>
>
> I'd like to call everyone to update status of blueprints, so that we can
> have accurate picture of 8.0 deliverables. During the meeting, I'd like us
> to quickly sync on FFEs and clarify status of major blueprints (if it won't
> be updated by some reason).
>
>
>
> In fact, we'd need to go over two first sections of etherpad (around 15
> items now). I assume that 1 hour will be enough, and ideally to go quicker.
> If I'm missing anything believed to be major, please move it in there.
>
>
>
> Thanks,
>
>
>
> On Tue, Dec 1, 2015 at 1:37 AM Vladimir Kuklin  wrote:
>
> Mike I think, it is rather good idea. I guess we can have a couple of
> requests still - although everyone is shy, we might get a little storm of
> FFE's. BTW, I will file at least one.
>
>
>
> On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov 
> wrote:
>
> Hi Fuelers,
>
> we are couple of days away from FF [1]. I have not noticed any request for
> feature freeze exception, so I assume that we pretty much decided what is
> going into 8.0 and what is not.
>
>
>
> If there are items which we'd like to ask exception for, I'd like us to have
> this requested now - so that we all can spend some time on analysis of what
> is done and what is left, and on risks assessment. I'd suggest to not
> consider any exception requests on the day of FF, as it doesn't leave us
> time to spend on it.
>
>
>
> To make a formal checkpoint of what is in and what is out, I suggest to get
> together on FF day, Wednesday, and go over all the items we have been
> working on in 8.0. What do you think folks? For instance, in #fuel-dev IRC
> at 8am PST (4pm UTC)?
>
>
>
> [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule
>
> --
>
> 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
>
>
>
>
>
> --
>
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> 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
>
> --
>
> 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

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

[Igor Kalnitsky]

Hey folks,

I agree that patches must be as small as possible. I believe it will
significantly increase our review experience - more fast review, and,
therefore, landing to master.

However, I don't agree that we should introduce criteria based on LOC,
because of mentioned reasons above. I believe that patches must be
atomic, no matter how much LOC it has. In the same time, we must not
have the whole feature as atomic unit here.

So basically my points are:

* Let's do not go with strict LOC. Decision it's ok to go with one
patch or not, should be up to code reviewers.
* If reviewer thinks that patch could and should be splitted into few,
then he/she set -1 and ask contributor to split it.
* Reviewers shouldn't hesitate to set -1 and ask to split patch.

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

[Igor Kalnitsky]

Fuelers,

As we decided on today's IRC meeting in #fuel-dev, FFE is granted for
1 week only.

Thanks,
igor

On Wed, Dec 2, 2015 at 5:42 PM, Andrian Noga  wrote:
> Colleagues,
>
> Folks,
> I would like to request feature freeze exception for Component registry
> https://blueprints.launchpad.net/fuel/+spec/component-registry
>
> Specification is already merged https://review.openstack.org/#/c/229306/
> Main patch is also merged https://review.openstack.org/#/c/247913/
> We still need to merge UI changes https://review.openstack.org/#/c/246889/53
> The change itself is a very small patch.
>  That should take just several days, so if there will be no other
> objections, we will be able to merge the change in a week timeframe.
>
> Regards,
> Andrian Noga
> Project manager
> Partners Centric Engineering Team,
> Mirantis, Inc.
> +38 (063) 966-21-24
> Skype: bigfoot_ua
> www.mirantis.com
> an...@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] Feature Freeze Exception Request: Task Based Deployment in Astute

[Igor Kalnitsky]

Hey folks,

As we decided on today's IRC meeting in #fuel-dev, FFE exception is
granted on the following conditions (if get them right):

* the feature is marked as experimental
* patches should be merged by the end of next week

Thanks,
igor

On Tue, Dec 1, 2015 at 10:01 PM, Vladimir Kuklin  wrote:
> Hi, Folks
>
> * Intro
>
> During Iteration 3 our Enhancements Team as long as other folks worked on
> the feature called "Task Based Deployment with Astute". Here is a link to
> its blueprint:
> https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute
>
> Major implication of this feature complition is that our deployment process
> will be drastically optimized allowing us to decrease deployment time of
> typical clusters at least by 2,5 times (for BVT/CI cases) and by order of
> magnitude for 100-node clusters.
>
> This is achieved by real parallelization of deployment tasks execution which
> assumes that we do not wait for the whole 'deployment group/role' to deploy,
> but we only wait for particular tasks to finish. For example, we could
> deploy 'database' task on secondary controllers as soon as 'database' task
> is ready on the first controller. As our deployment workflow consists only
> of a small amount of such synchronization points as 'database' task, we will
> be able to deploy majority of deployment tasks in parallel shrinking
> deployment time to "time-of-deployment-of-the-longest-node". This actually
> means that our standard deployment case for development and testing will
> take 30 minutes on our CI servers thus drastically improving developers and
> users experience, as well as shrinking down time of overall acceptance
> testing, time for bug reproducing and so on. This feature also allows one to
> use 7.0 role-as-a-plugin feature in much more effective way as current
> split-services-with-plugins feature may lead to very inoptimal deployment
> flow which might take up to 6 hours even for the simplest HA cluster, while
> it would take again 30 minutes with Task-Based approach.
> Also, when multi-roles were used we ran several tasks for each role each
> time it was used, making deployment suboptimal again.
>
>
> * Short List of Work Items
>
> As we started a little bit lately during iteration 3 we worked on design and
> specification of this feature in a way so that its introduction will bring
> in almost zero chance of regression with ability to disable it. Here is the
> summary
>
> So far we introduce several pieces of code:
> 1. New version of tasks format introducing cross-node dependencies between
> tasks
> 2. Changes to Nailgun
>   a. deduplication of tasks for roles [In Progress]
>   b. support for new tasks format [In Progress]
>   c. new engine that generates an array of hashes of tasks info consumable
> by new Astute engine [In Progress].
> 3. Changes to Astute
>  a. Tasks dependencies parser and visualizer [Ready for review]
>  b. Deployment engine capable of graph traversing and reporting [Read for
> Review]
>  c. Async wrapper for shell-based tasks [Ready for review]
> 4. Changes to Fuel Library
>  a. Add additional fields into existing Fuel Library deployment tasks for
> cross-dependencies [In Progress].
>
> * Ensurance of Little Regression and Backward Compatibility
>
> As we worked on being backward-compatible from the day one, this engine is
> enabled ONLY when 2 requirements are met:
>
> 1. It is globally enabled in Nailgun settings.yaml
> 2. ALL tasks scheduled for deployment execution have v2.0.0
>
> This list seems a little bit huge, but this changes are isolated and
> granular and actually affect the sequence in which tasks are executed on the
> nodes. This means that there will be actually no difference from the view of
> resulting functioning of the cluster. This feature can be safely disabled if
> user does not want to use it.
>
> But if user wants to work with it, he can gain enormous improvement in
> speed, his own engineering/development/testing velocity as well as in Fuel
> user experience.
>
> * Additional Cons of the Feature
>
> Moreover, this feature improves how the following use cases are also
> addressed:
>
> 1. When user deploys a specific set of nodes or tasks
> It will be possible to introduce additional flag for deploy/task run handler
> for Nailgun to pick up dependencies of specified tasks, even if they are
> currently not in place in current deployment graph. This means that instead
> of running
>
> fuel nodes --node-id 2,3 --deploy
>
> and see how it fails as node-1 contains some of the tasks that are required
> by nodes 2 and 3, user will be calm about it as he will be able to specify
> an option to populate deployment flow with needed tasks. No more
>
> fuel nodes --node-id 2 --tasks netconfig  -> Fail, because you forgot to
> specify some of the required tasks, e.g. hiera, globals.
>
> 2. Post-deployment plugin installation
>
> This feature also makes post-deployment plugin installation much easier as
> plugin 

[openstack-dev] [Fuel] Fuel Python Gerrit Dashboard

[Igor Kalnitsky]

Hey Fuelers,

As a part of improving review process, I've prepared a Gerrit
Dashboard for Python projects [1]. First and foremost, I did it for
myself (I believe it will help me to get attention to *ready-to-merge*
patches), but I want to share the link with you.

Feel free to use it!

[1] https://goo.gl/aFHdeQ

Thanks,
Igor

__
OpenStack Development Mailing 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] Getting rid of Docker containers on the Fuel master node

[Igor Kalnitsky]

Hey Vladimir,

Thanks for your effort on doing this job. Unfortunately we have not so
much time left and FF is coming, so I'm afraid it's become unreal to
make it before FF. Especially if it takes 2-3 days to fix system
tests.


Andrew,

I had the same opinion some time ago, but it was changed because
nobody puts effort to fix our Docker experience. Moreover Docker is
still buggy and we have a plenty of issues such as stale mount points
for instance. Besides, I don't like our upgrade procedure -

1. Install fuel-docker-images.rpm
2. Load images from installed tarball to Docker
3. Re-create containers from new images

Where (2) and (3) are manual steps and breaks idea of "yum update"
delivery approach.

Thanks,
Igor

On Wed, Nov 25, 2015 at 9:43 PM, Andrew Woodward  wrote:
> 
> IMO, removing the docker containers is a mistake v.s. fixing them and using
> them properly. They provide an isolation that is necessary (and that we
> mangle) to make services portable and scaleable. We really should sit down
> and document how we really want all of the services to interact before we
> rip the containers out.
>
> I agree, the way we use containers now still is quite wrong, and brings us
> some negative value, but I'm not sold on stripping them out now just because
> they no longer bring the same upgrades value as before.
> 
>
> My opinion aside, we are rushing into this far to late in the feature cycle.
> Prior to moving forward with this, we need a good QA plan, the spec is quite
> light on that and must receive review and approval from QA. This needs to
> include an actual testing plan.
>
> From the implementation side, we are pushing up against the FF deadline. We
> need to document what our time objectives are for this and when we will no
> longer consider this for 8.0.
>
> Lastly, for those that are +1 on the thread here, please review and comment
> on the spec, It's received almost no attention for something with such a
> large impact.
>
> On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov
>  wrote:
>>
>> The status is as follows:
>>
>> 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
>> w/o docker containers
>> 2) I've not built experimental ISO yet (have been testing and debugging
>> manually)
>> 3) There are still some flaws (need better formatting, etc.)
>> 4) Plan for tomorrow is to build experimental ISO and to begin fixing
>> system tests and fix the spec.
>>
>> [1] https://review.openstack.org/#/c/248649
>> [2] https://review.openstack.org/#/c/248650
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov
>>  wrote:
>>>
>>> Colleagues,
>>>
>>> I've started working on the change. Here are two patches (fuel-main [1]
>>> and fuel-library [2]). They are not ready to review (still does not work and
>>> under active development). Changes are not going to be huge. Here is a spec
>>> [3]. Will keep the status up to date in this ML thread.
>>>
>>>
>>> [1] https://review.openstack.org/#/c/248649
>>> [2] https://review.openstack.org/#/c/248650
>>> [3] https://review.openstack.org/#/c/248814
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy
>>>  wrote:



 On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya
  wrote:
>
> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> > Hi all,
> >
> > as you know, Rally runs inside docker on Fuel master node, so docker
> > removal (good improvement) is a problem for Rally users.
> >
> > To solve this, I'm planning to make native Rally installation on Fuel
> > master node that is running on CentOS 7,
> > and then make a step-by-step instruction how to make this
> > installation.
> >
> > So I hope docker removal will not make issues for Rally users.
>
> I believe the most backwards compatible scenario is to keep the docker
> installed while removing the fuel-* docker things back to the host OS.
> So nothing would prevent user from pulling and running whichever docker
> containers he wants to put on the Fuel master node. Makes sense?
>

 Sounds good


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

>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> 

Re: [openstack-dev] [Fuel] CentOS-7 Transition Plan

[Igor Kalnitsky]

Hey Roman,

Few notes about fuel-web patches:

* https://review.openstack.org/#/c/246535/ - Could be (and should be)
merged after FF.
* https://review.openstack.org/#/c/246531/ - Has -1 from Jenkins.
Looks like a floating test failure, so I've restarted tests. But
please track this one, and fix it if it fails again.

Thanks,
Igor

On Thu, Nov 26, 2015 at 12:22 PM, Roman Vyalov <rvya...@mirantis.com> wrote:
> Hi all,
> Part of those change requests may be merged shortly (today). They are
> compatible with Centos6.
> List of change requests ready to merge (compatible with Centos6):
> Fuel-library
>
> https://review.openstack.org/#/c/247066/
> https://review.openstack.org/#/c/248781/
> https://review.openstack.org/#/c/247727/
>
> Fuel-nailgun-agent
>
> https://review.openstack.org/#/c/244810/
>
> Fuel-web
>
> https://review.openstack.org/#/c/248206/
> https://review.openstack.org/#/c/246531/
> https://review.openstack.org/#/c/246535/
>
> Python-fuelclient
>
> https://review.openstack.org/#/c/231935/
>
> Fuel-ostf
>
> https://review.openstack.org/#/c/248096/
>
> Fuel-menu
>
> https://review.openstack.org/#/c/246888/
>
>
> List with all change requests related to the support Centos7:
> https://etherpad.openstack.org/p/fuel_on_centos7
>
> On Tue, Nov 24, 2015 at 4:37 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote:
>>
>> That's good to know, thank you, Vladimir, Dmitry.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Tue, Nov 24, 2015 at 3:10 PM, Vladimir Kozhukalov
>> <vkozhuka...@mirantis.com> wrote:
>>>
>>> In fact, we (I and Dmitry) are on the same page of how to merge these two
>>> features (Centos7 and Docker removal). We agreed that Dmitry's feature is
>>> much more complicated and of higher priority. So, Centos 7 should be merged
>>> first and then I'll rebase my patches (mostly supervisor -> systemd).
>>>
>>>
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Nov 24, 2015 at 1:57 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>>> wrote:
>>>>
>>>> Hey Dmitry,
>>>>
>>>> Thank you for your effort. I believe it's a huge step forward that
>>>> opens number of possibilities.
>>>>
>>>> > Every container runs systemd as PID 1 process instead of
>>>> > supervisord or application / daemon.
>>>>
>>>> Taking into account that we're going to drop Docker containers, I
>>>> think it was unnecessary complication of your work.
>>>>
>>>> Please sync-up with Vladimir Kozhukalov, he's working on getting rid
>>>> of containers.
>>>>
>>>> > Every service inside a container is a systemd unit. Container build
>>>> > procedure was modified, scripts setup.sh and start.sh were introduced
>>>> > to be running during building and configuring phases respectively.
>>>>
>>>> Ditto. :)
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> P.S: I wrote the mail and forgot to press "send" button. It looks like
>>>> Oleg is already pointed out that I wanted to.
>>>>
>>>> On Mon, Nov 23, 2015 at 2:37 PM, Oleg Gelbukh <ogelb...@mirantis.com>
>>>> wrote:
>>>> > Please, take into account the plan to drop the containerization of
>>>> > Fuel
>>>> > services:
>>>> >
>>>> > https://review.openstack.org/#/c/248814/
>>>> >
>>>> > --
>>>> > Best regards,
>>>> > Oleg Gelbukh
>>>> >
>>>> > On Tue, Nov 24, 2015 at 12:25 AM, Dmitry Teselkin
>>>> > <dtesel...@mirantis.com>
>>>> > wrote:
>>>> >>
>>>> >> Hello,
>>>> >>
>>>> >> We've been working for some time on bringing CentOS-7 to master node,
>>>> >> and now is the time to share and discuss the transition plan.
>>>> >>
>>>> >> First of all, what have been changed:
>>>> >> * Master node itself runs on CentOS-7. Since all the containers share
>>>> >>   the same repo as master node they all have been migrated to
>>>> >> CentOS-7
>>>> >>   too. Every container runs systemd as PID 1 process instead of
>>>> >>   supervisord or application / daemon.
>>>> >> * Every service inside a container is a systemd unit. Co