Re: [openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Tue, Feb 21, 2017 at 2:25 PM, Ihor Kalnytskyi <i...@kalnytskyi.com>
wrote:

> Hey fellow fuelers,
>
> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> He's doing thorough review [1], participate in feature developments
> (e.g. Config-DB enhancements, network-manager performance
> improvements) and made an outstanding contribution bug-fixing.
>
> Core reviewers, please reply back with +1/-1.
>
> Thanks,
> Ihor
>
> [1] http://stackalytics.com/?release=ocata=fuel-web
>
> __
> OpenStack Development Mailing List (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-library] Nominate Stanislaw Bogatkin to fuel-library core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Mon, Sep 12, 2016 at 5:01 PM, Alex Schultz <aschu...@redhat.com> wrote:

> +1
>
> On Wed, Sep 7, 2016 at 5:07 PM, Maksim Malchuk <mmalc...@mirantis.com>
> wrote:
> > Hello,
> >
> > I would like to nominate Stanislaw Bogatkin to fuel-library core due to
> his
> > significant contribution to the project [1] and [2]. He is one of the top
> > reviewers and contributors in the project.
> >
> > [1]
> > http://stackalytics.com/?user_id=sbogatkin_type=all;
> release=all=marks=fuel-library
> > [2] http://stackalytics.com/report/contribution/fuel-library/90
> >
> > --
> > Best Regards,
> > Maksim Malchuk,
> > Senior DevOps Engineer,
> > MOS: Product Engineering,
> > 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

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

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Sat, Sep 10, 2016 at 4:49 PM, Sergey Vasilenko <svasile...@mirantis.com>
wrote:

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

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

[Aleksey Kasatkin]

Hi,

-1 to the proposal. We have the ability (and we use it) to add guys to
several core groups. So, AFAIC, Vladimir's pros point #1 is covered. IMO,
pros point #2 looks questionable and not so important. Cons could be worse
(agree with Lukasz).

Thanks,



Aleksey Kasatkin


On Tue, Sep 6, 2016 at 1:19 PM, Sergii Golovatiuk <sgolovat...@mirantis.com>
wrote:

> Hi,
>
> Fuel repositories include several languages/technologies (puppet, python,
> ruby, make ...)  Core engineer nominated for achievements in one project
> may have average skills in another language/technology.
>
> So, I give '-1' the suggestion.
>
> However, we may have one group for python project, one group for puppet
> related projects. So we need to identify languages/technologies first, then
> make another proposal.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Sep 6, 2016 at 11:19 AM, Aleksandr Didenko <adide...@mirantis.com>
> wrote:
>
>> Hi,
>>
>> -1 for the proposal
>>
>> Regards,
>> Alex
>>
>> On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov <astepa...@mirantis.com>
>> wrote:
>>
>>> Guys, I have one serious question: WHO will be global core?
>>> Example:
>>>   I'm core reviewer in 2 repos, but I'm absolutely could not be core
>>> reviewer in puppet!
>>>
>>> On Tue, Sep 6, 2016 at 11:31 AM, Igor Kalnitsky <i...@kalnitsky.org>
>>> wrote:
>>>
>>>> -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 <e...@mirantis.com> 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 <lo...@mirantis.com>
>>>> wrote:
>>>> >>
>>>> >> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov <
>>>> amaksi...@mirantis.com>
>>>> >> wrote:
>>>> >> > +1
>>>> >> > This is a good proposal, I also think we should have single
>>>> fuel-core
>>>> >> > group
>>>> >> > for all repos. In real life core reviewers won't set +2 or merge to
>>>> >> > repos
>>>> >> > with which they are not familiar with.
>>>> >> 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
>>>> >> > <vkozhuka...@mirantis.com> wrote:
>>>> >> >>
>>>> >> >> Dear colleagues,
>>>> >> >>
>>>> >> >> I'd like to suggest to use common fuel-core group for all Fuel
>>>> projects
>>>> >> >> instead of having separate independent 'by-project' core groups
>>>> like
>>>> >> >> 'fuel-astute-core' or 'fuel-agent-core'.
>>>> >> >>
>>>> >> >> Pros:
>>>> >> >> 1) It will be easier to access core members (timezone and holiday
>>>> >> >> tolerance)
>>>> >> >> 2) It will be easier to manage single core group (promote new
>>>> members,
>>>> >> >> remove not active members)
>>>> >> >>
>>>> >> >> Cons:
>>>> >> >> 1) Less of flexibility. Permissions will be the same for all core
>>>> >> >> reviewers in all Fuel projects.
>>>> >> >>
>>>> >> >> What do you think?
>>>> >> >>
>>>> >> >> Vladimir Kozhukalov
>>>> >> >>
>>>> >&g

Re: [openstack-dev] [Fuel]Nominating Vitalii Kulanov for python-fuelclient-core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Mon, Jul 25, 2016 at 7:46 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Vitaly's doing a great job. +2, no doubts!
>
> On Mon, Jul 25, 2016 at 6:27 PM, Tatyana Leontovich
> <tleontov...@mirantis.com> wrote:
> > A huge +1
> >
> > On Mon, Jul 25, 2016 at 4:33 PM, Yegor Kotko <yko...@mirantis.com>
> wrote:
> >>
> >> +1
> >>
> >> On Mon, Jul 25, 2016 at 3:19 PM, Roman Prykhodchenko <m...@romcheg.me>
> >> wrote:
> >>>
> >>> Hi Fuelers,
> >>>
> >>> Vitalii has been providing great code reviews and patches for some
> time.
> >>> His recent commitment to help consolidating both old and new fuel
> clients
> >>> and his bug-squashing activities show his willingness to step up and
> take
> >>> responsibilities within the community. He can often be found in #fuel
> as
> >>> vkulanov.
> >>>
> >>>
> >>>
> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t=mitaka
> >>> http://stackalytics.com/?module=python-fuelclient_id=vitaliy-t
> >>>
> >>>
> >>> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

[Aleksey Kasatkin]

Well, the agreement is reached. I've added Artur to fuel-web-core group.

Let's continue discussion on time management questions if it will
become an issue.

Artur, congratulations!


Aleksey Kasatkin


On Fri, Jun 10, 2016 at 2:18 AM, Evgeniy L <e...@mirantis.com> wrote:

> Hi Dmitry,
>
> It depends, but usually it takes half of working time to do reviews, I'm
> not sure if we can assume 25-30%, also finding a good reviewer usually is
> much harder than a person who can write the code, so it would be much more
> productive to encourage people to spend as much time as they can on making
> the project better and helping other contributors, than restricting them to
> review code for not more than 2.5 hours.
>
> Thanks,
>
> On Thu, Jun 9, 2016 at 5:46 AM, Dmitry Klenov <dkle...@mirantis.com>
> wrote:
>
>> Hi Folks,
>>
>> From technical standpoint I fully support Arthur to become core reviewer.
>> I like thorough reviews that he is making.
>>
>> Although I have some concerns as well. Planned tasks for our team will
>> not allow Arthur to spend more than 25-30% of his time for reviewing. If
>> that is fine - my concerns are resolved.
>>
>> Thanks,
>> Dmitry.
>>
>> On Thu, Jun 9, 2016 at 12:57 PM, Sergey Vasilenko <
>> svasile...@mirantis.com> wrote:
>>
>>> +1
>>>
>>>
>>> /sv
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (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 Artur Svechnikov to the fuel-web-core team

[Aleksey Kasatkin]

Hey Fuelers,

I'd like to nominate Artur Svechnikov to the fuel-web-core team.

Artur is doing thorough reviews [1], he produces high-quality code.
Artur is actively participating in features development (implementation for
Dynamically build bootstrap feature, design and implementation for
HugePages support and of NUMA/CPU pinning support) and in bug-fixing in
Fuel project.

Core reviewers, please reply back with +1/-1.

[1] http://stackalytics.com/report/contribution/fuel-web/90

Best regards,


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

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Thu, Jun 9, 2016 at 9:51 AM, Sergey Vasilenko <svasile...@mirantis.com>
wrote:

> +1
>
> /sv
> On Jun 9, 2016 09:24, "Julia Aranovich" <jkirnos...@mirantis.com> wrote:
>
>> +1
>>
>> On Wed, Jun 8, 2016 at 8:52 PM Bulat Gaifullin <bgaiful...@mirantis.com>
>> wrote:
>>
>>> Hey Fuelers,
>>>
>>> I'd like to nominate Ilya Kutukov for the fuel-web-core team.
>>> Ilya`s doing good reviews with detailed feedback [1],
>>> and has implemented custom graph execution engine for Fuel.
>>> Also Ilya`s implemented new database models for storing deployment tasks
>>> in Fuel.
>>>
>>>
>>> Fuel Cores, please reply back with +1/-1.
>>>
>>> [1] http://stackalytics.com/report/contribution/fuel-web/90
>>>
>>>
>>> Regards,
>>> Bulat Gaifullin
>>> Mirantis Inc.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (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] [Ci] Re-trigger by keyword in comment

[Aleksey Kasatkin]

Matthew,

It's great that we have this test. But why to rerun it for no changes?
It was executed only when a new patch was published for CR or CR was
rebased.
Now it is executed on "fuel:recheck".

Agree, adding a plugin would be helpful.



Aleksey Kasatkin


On Fri, Apr 22, 2016 at 4:19 PM, Matthew Mosesohn <mmoses...@mirantis.com>
wrote:

> Aleksey, actually I want to extend the test group we run there. Many
> changes coming out of nailgun are actually creating BVT failures that
> can only be prevented by such tests. One such extension would be
> adding a plugin to the deployment to ensure that basic plugins are
> still deployable.
>
> I'm ok with tweaking recheck flags, but we should not try to avoid
> using the CI that saves us from regressions.
>
> On Fri, Apr 22, 2016 at 3:43 PM, Aleksey Kasatkin
> <akasat...@mirantis.com> wrote:
> > Hi Dmitry,
> >
> > Thank you for update.
> > Is it intended that master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
> job
> > for code requests to fuel-web runs at every recheck now?
> > Before the change it was executed for new patch/rebase only.
> > Its run takes about 1.5 hour and there is little sense to run it more
> than
> > once for the same patch.
> >
> > Thanks,
> >
> >
> >
> > Aleksey Kasatkin
> >
> >
> > On Fri, Apr 22, 2016 at 10:59 AM, Dmitry Kaiharodsev
> > <dkaiharod...@mirantis.com> wrote:
> >>
> >> Hi to all,
> >>
> >> please be informed that recently we've merged a patch[0]
> >> that allow to re-trigger fuel-ci[1] tests by commenting review with
> >> keywords "fuel: recheck"[2]
> >>
> >> For now actual list of Jenkins jobs with retrigger by "fuel: recheck"[2]
> >> keyword looks like:
> >>
> >> 7.0.verify-python-fuelclient
> >> 8.0.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> >> 8.0.fuel-library.pkgs.ubuntu.smoke_neutron
> >> 8.0.verify-docker-fuel-web-ui
> >> 8.0.verify-fuel-web
> >> 8.0.verify-fuel-web-ui
> >> fuellib_noop_tests
> >> master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision
> >> master.fuel-astute.pkgs.ubuntu.review_astute_patched
> >> master.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> >> master.fuel-library.pkgs.ubuntu.smoke_neutron
> >> master.fuel-ostf.pkgs.ubuntu.gate_ostf_update
> >> master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
> >> master.python-fuelclient.pkgs.ubuntu.review_fuel_client
> >> mitaka.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision
> >> mitaka.fuel-astute.pkgs.ubuntu.review_astute_patched
> >> mitaka.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> >> mitaka.fuel-library.pkgs.ubuntu.smoke_neutron
> >> mitaka.fuel-ostf.pkgs.ubuntu.gate_ostf_update
> >> mitaka.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
> >> mitaka.python-fuelclient.pkgs.ubuntu.review_fuel_client
> >> old.verify-nailgun_performance_tests
> >> verify-fuel-astute
> >> verify-fuel-devops
> >> verify-fuel-docs
> >> verify-fuel-library-bats-tests
> >> verify-fuel-library-puppetfile
> >> verify-fuel-library-python
> >> verify-fuel-library-tasks
> >> verify-fuel-nailgun-agent
> >> verify-fuel-plugins
> >> verify-fuel-qa-docs
> >> verify-fuel-stats
> >> verify-fuel-ui-on-fuel-web
> >> verify-fuel-web-docs
> >> verify-fuel-web-on-fuel-ui
> >> verify-nailgun_performance_tests
> >> verify-puppet-modules.lint
> >> verify-puppet-modules.syntax
> >> verify-puppet-modules.unit
> >> verify-python-fuelclient
> >> verify-python-fuelclient-on-fuel-web
> >> verify-sandbox
> >>
> >>
> >> [0] https://review.fuel-infra.org/#/c/17916/
> >> [1] https://ci.fuel-infra.org/
> >> [2] without quotes
> >> --
> >> Kind Regards,
> >> Dmitry Kaigarodtsev
> >> Mirantis, Inc.
> >>
> >> +38 (093) 522-09-79 (mobile)
> >> +38 (057) 728-4214 (office)
> >> Skype: d1mas85
> >>
> >> 38, Lenin avenue
> >> Kharkov, Ukraine
> >> www.mirantis.com
> >> www.mirantis.ru
> >> dkaiharod...@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] [Ci] Re-trigger by keyword in comment

[Aleksey Kasatkin]

Hi Dmitry,

Thank you for update.
Is it intended that master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
<https://ci.fuel-infra.org/job/master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy/>
job for code requests to fuel-web runs at every recheck now?
Before the change it was executed for new patch/rebase only.
Its run takes about 1.5 hour and there is little sense to run it more than
once for the same patch.

Thanks,



Aleksey Kasatkin


On Fri, Apr 22, 2016 at 10:59 AM, Dmitry Kaiharodsev <
dkaiharod...@mirantis.com> wrote:

> Hi to all,
>
> please be informed that recently we've merged a patch[0]
> that allow to re-trigger fuel-ci[1] tests by commenting review with
> keywords "fuel: recheck"[2]
>
> For now actual list of Jenkins jobs with retrigger by "fuel: recheck"[2]
> keyword looks like:
>
> 7.0.verify-python-fuelclient
> 8.0.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> 8.0.fuel-library.pkgs.ubuntu.smoke_neutron
> 8.0.verify-docker-fuel-web-ui
> 8.0.verify-fuel-web
> 8.0.verify-fuel-web-ui
> fuellib_noop_tests
> master.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision
> master.fuel-astute.pkgs.ubuntu.review_astute_patched
> master.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> master.fuel-library.pkgs.ubuntu.smoke_neutron
> master.fuel-ostf.pkgs.ubuntu.gate_ostf_update
> master.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
> master.python-fuelclient.pkgs.ubuntu.review_fuel_client
> mitaka.fuel-agent.pkgs.ubuntu.review_fuel_agent_one_node_provision
> mitaka.fuel-astute.pkgs.ubuntu.review_astute_patched
> mitaka.fuel-library.pkgs.ubuntu.neutron_vlan_ha
> mitaka.fuel-library.pkgs.ubuntu.smoke_neutron
> mitaka.fuel-ostf.pkgs.ubuntu.gate_ostf_update
> mitaka.fuel-web.pkgs.ubuntu.review_fuel_web_deploy
> mitaka.python-fuelclient.pkgs.ubuntu.review_fuel_client
> old.verify-nailgun_performance_tests
> verify-fuel-astute
> verify-fuel-devops
> verify-fuel-docs
> verify-fuel-library-bats-tests
> verify-fuel-library-puppetfile
> verify-fuel-library-python
> verify-fuel-library-tasks
> verify-fuel-nailgun-agent
> verify-fuel-plugins
> verify-fuel-qa-docs
> verify-fuel-stats
> verify-fuel-ui-on-fuel-web
> verify-fuel-web-docs
> verify-fuel-web-on-fuel-ui
> verify-nailgun_performance_tests
> verify-puppet-modules.lint
> verify-puppet-modules.syntax
> verify-puppet-modules.unit
> verify-python-fuelclient
> verify-python-fuelclient-on-fuel-web
> verify-sandbox
>
>
> [0] https://review.fuel-infra.org/#/c/17916/
> [1] https://ci.fuel-infra.org/
> [2] without quotes
> --
> Kind Regards,
> Dmitry Kaigarodtsev
> Mirantis, Inc.
>
> +38 (093) 522-09-79 (mobile)
> +38 (057) 728-4214 (office)
> Skype: d1mas85
>
> 38, Lenin avenue
> Kharkov, Ukraine
> www.mirantis.com
> www.mirantis.ru
> dkaiharod...@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][plugins] VIP addresses and network templates

[Aleksey Kasatkin]

Hi Simon,

When network template is in use, network roles to endpoints mapping is
specified in section "roles" (in the template). So, "default_mapping" from
network role description is overridden in the network template.
E.g.:

network_assignments:
monitoring:
ep: br-mon
...

network_scheme:
custom:
roles:
influxdb_vip: br-mon
...
...


I hope, this helps.

Regards,



Aleksey Kasatkin


On Wed, Apr 20, 2016 at 12:16 PM, Simon Pasquier <spasqu...@mirantis.com>
wrote:

> Hi,
> I've got a question regarding network templates and VIP. Some of our users
> want to run the StackLight services (eg Elasticsearch/Kibana and
> InfluxDB/Grafana servers) on a dedicated network (lets call it
> 'monitoring'). People use network templates [0] to provision this
> additional network but how can Nailgun allocate the VIP address(es) from
> this 'monitoring' network knowing that today the plugins specify the
> 'management' network [1][2]?
> Thanks for your help,
> Simon
> [0]
> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
> [1]
> https://github.com/openstack/fuel-plugin-influxdb-grafana/blob/8976c4869ea5ec464e5d19b387c1a7309bed33f4/network_roles.yaml#L4
> [2]
> https://github.com/openstack/fuel-plugin-elasticsearch-kibana/blob/25b79aff9a79d106fc74b33535952d28b0093afb/network_roles.yaml#L2
>
> __
> OpenStack Development Mailing List (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] Plans on networking modularisation

[Aleksey Kasatkin]

Hi Ryan,

Thank you. We had a talk with Evgeniy. As a preliminary plan, we will have
meetings with all interested people from Networking team.

Regards,


Aleksey Kasatkin


On Tue, Mar 15, 2016 at 7:46 PM, Ryan Moe <r...@mirantis.com> wrote:

> Hi Aleksey,
>
>
>
>> What is the status of making networking part replaceable? As I know, [0]
>> is in progress. Are there any other activities in progress (about API,
>> serialization for orchestrator, network verification)? Do we have specs on
>> review (I know about this one: [1]) ?
>>
>>
> AFAIK there are no other activities in progress right now.
>
>
>> As I know, [0] is about separate storage service for networking related
>> information (from what I've seen), not about moving all network-related
>> code. Please correct me if it's not true.
>>
>
> You are correct. The intent was to end up with a separate network storage
> service and network manager as a client of this service (where appropriate).
>
>
>>
>> AFAIC, [0] can be combined with moving of network part into extension
>> (API, serialization). So, extension could use this storage. Network
>> verification (net-checker) depends on networking data and it uses the same
>> RPC so it can be more difficult to move its setup and results acquisition
>> from Nailgun into extension.
>> I'm for networking as extension as it was done for "volume manager"
>> already.
>>
>>
> I agree that moving network manager into an extension would be good. I
> think we'll need some discussion around that though. NetworkManager does a
> lot and some of it can be pushed off to a separate service but some will
> always be tied to Nailgun. I'm not sure how or if that will impact moving
> it into an extension.
>
>
>> Please expand this a bit: "Reuse Neutron API with additional
>> plugins/extensions to provide for us a way to also store bonds/nics related
>> information."
>> As I understand, it's rather specific stuff and will cover very small
>> part of the whole task. And as 2.1 is in progress already, 2.3 seems to be
>> rejected..?
>>
>>
> I originally created a simple PoC (2.1) just to test out the idea. The
> Nailgun side of this work done since doesn't have any dependency on that
> PoC. We can freely change directions. Neutron handles a lot of what Nailgun
> cares about (networks, subnets, IP allocation, etc.) so I'm currently
> investigating it as an option.
>
>
>> I'd like to participate in design discussions. Please add me into
>> meetings.
>>
>
> I will make sure you're included. Your input would be greatly appreciated.
>
> Thanks,
> Ryan
>
> __
> OpenStack Development Mailing List (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] network_metadata hash keys on astute.yaml

[Aleksey Kasatkin]

Hi,

I'm agree with Alex, keys should remain immutable. 'node-{uid}' is Okay, we
have a method for this in Nailgun already. It should be a very simple fix
in Nailgun.

Thanks,


Aleksey Kasatkin


On Tue, Mar 15, 2016 at 3:19 PM, Kyrylo Galanov <kgala...@mirantis.com>
wrote:

> Hi,
>
> I would like to remind that we are close to code freeze and bug is still
> there. Moreover, new bug reports continue to be submitted [3].
> Please, do not ignore the discussion.
>
> [3] https://bugs.launchpad.net/fuel/+bug/1557417
>
> On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko <adide...@mirantis.com
> > wrote:
>
>> Hi,
>>
>> some additional info on the problem: if I create some Hiera override for
>> the nodes list and use node key which is hostname bond, then after node
>> rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
>> override will create a "ghost" node in the list and will not change
>> settings I wanted to change. So node keys in that hash should remain
>> immutable.
>>
>> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
>> was working before (and does not require new patches like [0]) and we're
>> too late in the release cycle to change keys to '{uid}'.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/284046/
>>
>> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov <kgala...@mirantis.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Currently nailgun and puppet process network_metadata hash slightly
>>> different.
>>> Nailgun uses short hostname as a hash key for each node, while library
>>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>>> deployment failure.
>>>
>>> During code review[0] it turned out that there are two points of view,
>>> which approach is correct [1].
>>> Both are one-line fixes, however it have been lasting too long with no
>>> result.
>>>
>>> I would like to start a discussion with a hope to close the issue
>>> shortly.
>>>
>>> Best regards.
>>> Kyrylo
>>>
>>> [0] https://review.openstack.org/#/c/284046/
>>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (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] Plans on networking modularisation

[Aleksey Kasatkin]

Hi,

Evgeniy, thank you for summarizing this.

I have questions about action items.

What is the status of making networking part replaceable? As I know, [0] is
in progress. Are there any other activities in progress (about API,
serialization for orchestrator, network verification)? Do we have specs on
review (I know about this one: [1]) ?

As I know, [0] is about separate storage service for networking related
information (from what I've seen), not about moving all network-related
code. Please correct me if it's not true.

AFAIC, [0] can be combined with moving of network part into extension (API,
serialization). So, extension could use this storage. Network verification
(net-checker) depends on networking data and it uses the same RPC so it can
be more difficult to move its setup and results acquisition from Nailgun
into extension.
I'm for networking as extension as it was done for "volume manager" already.

Please expand this a bit: "Reuse Neutron API with additional
plugins/extensions to provide for us a way to also store bonds/nics related
information."
As I understand, it's rather specific stuff and will cover very small part
of the whole task. And as 2.1 is in progress already, 2.3 seems to be
rejected..?

I'd like to participate in design discussions. Please add me into meetings.

Thanks,

[0] https://review.openstack.org/#/q/topic:bp/network-config-refactoring
[1] https://review.openstack.org/#/c/290767/



Aleksey Kasatkin


On Tue, Mar 15, 2016 at 10:17 AM, Evgeniy L <e...@mirantis.com> wrote:

> Hi,
>
> We've been working on networking modularisation, during this activity
> Nailgun is being fixed [0] in order to provide better layer boundary
> between network related code and the rest of the system.
>
> The purpose of this email is:
> 1. To make sure that this activity is known in Fuel team.
> 2. To make sure that we are on the same page.
> 3. To make sure that it's something valuable and most of the Fuel team
> supports it.
>
> Some time ago I sent an email [1] on why we should do modularisation, here
> is this list:
> 1. Reusability of components.
> 1.1. It will lead to more components consumers (users).
> 1.2. Better integration with the community (some community projects may be
> interested in using some parts of Fuel and vice versa).
> 2. Components decoupling will lead to clear interfaces between components.
> 2.1. So it will be easier to replace some component.
> 2.2. It will be easier to split the work between teams and it will help to
> scale teams in a much more efficient way.
>
> High level action items are:
> 1. Make networking part in Nailgun replaceable.
> 2. Make the replacement, currently evaluation of several options is in
> progress:
> 2.1. Implement separate service to store network related
> (ips/networks/bonds/nics) configuration. Code name is Illmatic.
> 2.2. Just make it as an extension.
> 2.3. Reuse Neutron API with additional plugins/extensions to provide for
> us a way to also store bonds/nics related information.
>
> If you have any ideas or questions, don't hesitate to ask them.
>
> Thanks,
>
> [0] https://review.openstack.org/#/q/topic:bp/network-config-refactoring
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [FFE] FF exception request for SR-IOV

[Aleksey Kasatkin]

> And we need to write a new patch for:
https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov

It is on review now: https://review.openstack.org/286704

Complete list of patches on review:
https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov



Aleksey Kasatkin


On Tue, Mar 1, 2016 at 6:27 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:

> Hi,
>
> I'd like to to request a feature freeze exception for "Support for SR-IOV
> for improved networking performance" feature [0].
>
> Part of this feature is already merged [1]. We have the following patches
> in work / on review:
>
> https://review.openstack.org/280782
> https://review.openstack.org/284603
> https://review.openstack.org/286633
>
> And we need to write a new patch for:
> https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov
>
> We need 2 weeks at most after FF to accomplish this.
> Risk of not delivering it after 2 weeks is very low.
>
> Regards,
> Alex
>
> [0] https://blueprints.launchpad.net/fuel/+spec/support-sriov
> [1]
> https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-sriov
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Thu, Feb 25, 2016 at 11:59 PM, Sergey Vasilenko <svasile...@mirantis.com>
wrote:

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

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

[Aleksey Kasatkin]

+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

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

[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 <m...@romcheg.me> wrote:

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

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

[Aleksey Kasatkin]

Good idea, overally.

How about multiple plugins? We don't have any sequence or priorities
between them.
What if one plugin assumes that VIP is present but other one wants to
remove it?


Aleksey Kasatkin


On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <sgolovat...@mirantis.com
> wrote:

> +1 to overriding VIPs
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
>
>> +1 to overriding VIPs
>>
>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <m...@romcheg.me>
>> wrote:
>>
>>> Folks,
>>>
>>> currently merge policy for network roles only allows to add new VIPs to
>>> already existing roles [1]. If a plugin supplies a VIP with a name that
>>> already exists but with different parameters, Nailgun will not allow to do
>>> that. We faced a need to override configuration of several VIPs by
>>> completely removing them from network roles by supplying something like
>>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>>> policy that only handles one cornerstone.
>>>
>>> I’ve talked to ikalnitsky and we realized that this functionality of
>>> merging new VIPs from plugins to an existing network role is actually wrong
>>> and should be replaced by complete overriding. Let’s discuss this
>>> possibility here.
>>>
>>>
>>> References:
>>>
>>> 1.
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>>> 2. http://xsnippet.org/361361/
>>> 3. https://review.openstack.org/#/c/273169/1
>>>
>>>
>>> - 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
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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

[Aleksey Kasatkin]

Roman, please provide more details on how VIPs are overridden. And how do
you deal with multiple plugins.


Aleksey Kasatkin


On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <akasat...@mirantis.com>
wrote:

> Good idea, overally.
>
> How about multiple plugins? We don't have any sequence or priorities
> between them.
> What if one plugin assumes that VIP is present but other one wants to
> remove it?
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> +1 to overriding VIPs
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <vkuk...@mirantis.com>
>> wrote:
>>
>>> +1 to overriding VIPs
>>>
>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <m...@romcheg.me>
>>> wrote:
>>>
>>>> Folks,
>>>>
>>>> currently merge policy for network roles only allows to add new VIPs to
>>>> already existing roles [1]. If a plugin supplies a VIP with a name that
>>>> already exists but with different parameters, Nailgun will not allow to do
>>>> that. We faced a need to override configuration of several VIPs by
>>>> completely removing them from network roles by supplying something like
>>>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>>>> policy that only handles one cornerstone.
>>>>
>>>> I’ve talked to ikalnitsky and we realized that this functionality of
>>>> merging new VIPs from plugins to an existing network role is actually wrong
>>>> and should be replaced by complete overriding. Let’s discuss this
>>>> possibility here.
>>>>
>>>>
>>>> References:
>>>>
>>>> 1.
>>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>>>> 2. http://xsnippet.org/361361/
>>>> 3. https://review.openstack.org/#/c/273169/1
>>>>
>>>>
>>>> - 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com <http://www.mirantis.ru/>
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing 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

[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 <adide...@mirantis.com>
wrote:

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

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Folks, you are welcome to review a spec: https://review.openstack.org/254796


Aleksey Kasatkin


On Fri, Nov 6, 2015 at 6:03 PM, Aleksey Kasatkin <akasat...@mirantis.com>
wrote:

> Mike, Vladimir,
>
> Yes,
> 1. We need to add IPs on-the-fly (need to add POST functionality) ,
> otherwise it will be VIP-like way (change network roles in plugin or
> release).
> 2. We should allow to leave fields 'network_role', 'node_roles', 'namespace'
> empty. So, validation should be changed.
>
> So, answer here
>
>> Q. Any allocated IP could be accessible via these handlers, so now we can
>> restrict user to access VIPs only
>> and answer with some error to other ip_addrs ids.
>>
> should be "Any allocated IP is accessible via these handlers", so URLs can
> be changed to
> /clusters//network_configuration/ips/
> /clusters//network_configuration/ips//
> Nodes IPs maybe the different story though.
>
> Alex,
>
> 'node_roles' determines in what node group to allocate IP. So, it will be
> group with controller nodes for our base VIPs
> (they all have node_roles=['controller'] which is default setting).
> It can be some other node group for nodes with different role. E.g. ceph
> nodes use some ceph/vip network role and VIP is defined
> for this network role (with 'network_role'='ceph/vip' and 
> 'node_roles'=['ceph/osd']).
> This VIP will be allocated
> in the network that 'ceph/vip' is mapped to and in the node group where
> ceph nodes are located. ceph nodes cannot be located
> in more than one node group then (as VIP cannot migrate between node groups
> now).
>
>
>
> Aleksey Kasatkin
>
>
> On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
>
>> +1 to Mike
>>
>> It would be awesome to get an API handler that allows one to actually add
>> an ip address to IP_addrs table. As well as an IP range to ip_ranges table.
>>
>> On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov <mscherba...@mirantis.com
>> > wrote:
>>
>>> Is there a way to make it more generic, not "VIP" specific? Let's say I
>>> want to reserve address(-es) for something for whatever reason, and then I
>>> want to use them by some tricky way.
>>> More specifically, can we reserve IP address(-es) with some codename,
>>> and use it later?
>>> 12.12.12.12 - my-shared-ip
>>> 240.0.0.2 - my-multicast
>>> and then use them in puppet / whatever deployment code by $my-shared-ip,
>>> $my-multicast?
>>>
>>> Thanks,
>>>
>>> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin <akasat...@mirantis.com>
>>> wrote:
>>>
>>>> Folks,
>>>>
>>>> Here is a resume of our recent discussion:
>>>>
>>>> 1. Add new URLs for processing VIPs:
>>>>
>>>> /clusters//network_configuration/vips/ (GET)
>>>> /clusters//network_configuration/vips// (GET, PUT)
>>>>
>>>> where  is the id in ip_addrs table.
>>>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>>>> address) for one VIP by its id.
>>>> More possibilities can be added later.
>>>>
>>>> Q. Any allocated IP could be accessible via these handlers, so now we
>>>> can restrict user to access VIPs only
>>>> and answer with some error to other ip_addrs ids.
>>>>
>>>> 2. Add current VIP meta into ip_addrs table.
>>>>
>>>> Create new field in ip_addrs table for placing VIP metadata there.
>>>> Current set of ip_addrs fields:
>>>> id (int),
>>>> network (FK),
>>>> node (FK),
>>>> ip_addr (string),
>>>> vip_type (string),
>>>> network_data (relation),
>>>> node_data (relation)
>>>>
>>>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>>>
>>>> 3. Allocate VIPs on cluster creation and seek VIPs at all network
>>>> changes.
>>>>
>>>> So, VIPs will be checked (via network roles descriptions) and
>>>> re-allocated in ip_addrs table
>>>> at these points:
>>>> a. create cluster
>>>> b. modify networks configuration
>>>> c. modify one network
>>>> d. modify network template
>>>> e. change nodes set for cluster
>>>> f. change node roles set on nodes
>>>> g. modify cluster attributes (change set of plugins)
>>>> h. modify release
>>>>
>>>> 4. Add 'manual' field 

Re: [openstack-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?

[Aleksey Kasatkin]

+ Konstantin


Aleksey Kasatkin


On Wed, Dec 23, 2015 at 7:38 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:

> Hi,
>
> just finished deployment of multirack env with ceph and external LB (not a
> standard multi-rack deployment scheme, actually, but still):
>
> http://paste.openstack.org/show/482610/
>
> As you can see it works just fine in multirack.
>
> Also, we're running 'deploy_ceph_ha_nodegroups' system test as a part of
> 'thread_7' group in our swarm tests, so ceph in multirack is covered with
> automated tests as well.
>
> Regards,
> Alex
>
> On Wed, Dec 23, 2015 at 5:29 PM, Roman Sokolkov <rsokol...@mirantis.com>
> wrote:
>
>> + Konstantin and Alex
>>
>> Can someone give a quick highlight on that question?
>>
>> On Tue, Dec 22, 2015 at 8:17 PM, Roman Sokolkov <rsokol...@mirantis.com>
>> wrote:
>>
>>> Folks,
>>>
>>> multirack is going to be a part of MOS 8.0.
>>>
>>> But i can not find any info about Ceph?
>>>
>>> Technically Ceph supports Multiple L3 networks [1].
>>>
>>> [1] -
>>> http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings
>>>
>>> --
>>> Roman Sokolkov,
>>> Deployment Engineer,
>>> Mirantis, Inc.
>>> Skype rsokolkov,
>>> rsokol...@mirantis.com
>>>
>>
>>
>>
>> --
>> Roman Sokolkov,
>> Deployment Engineer,
>> Mirantis, Inc.
>> Skype rsokolkov,
>> rsokol...@mirantis.com
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Aleksey Kasatkin]

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

[Aleksey Kasatkin]

+1

Aleksey Kasatkin


On Wed, Dec 23, 2015 at 5:28 PM, Aleksandr Didenko <adide...@mirantis.com>
wrote:

> +1
>
> On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy <
> asledzins...@mirantis.com> wrote:
>
>> +1
>>
>> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
>> tleontov...@mirantis.com> 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] Removal of support for nova-network

[Aleksey Kasatkin]

Corresponding ticket:

https://bugs.launchpad.net/fuel/+bug/1528613 (Prohibit creation of
Nova-Network enabled 8.0 environments)


Aleksey Kasatkin


On Tue, Dec 22, 2015 at 4:22 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:

> I agree – I don’t think we can change the user’s ability to manage old
> releases.  This work should be about preventing the selection of
> nova-network for new environments on 8.0 release and later – we should
> restrict this via all methods of interaction, including UI, CLI and API if
> possible.
>
>
>
> *From:* Oleg Gelbukh [mailto:ogelb...@mirantis.com]
> *Sent:* Tuesday, December 22, 2015 3:09 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Fuel] Removal of support for nova-network
>
>
>
> Sergii,
>
>
>
> Nailgun will still have data of clusters with old releases, should they be
> in the database backup. And it still has to be able to manage them.
>
>
>
> --
>
> Best regards,
>
> Oleg Gelbukh
>
>
>
> On Tue, Dec 22, 2015 at 11:58 AM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
> Hi,
>
>
>
> There won't be upgrade to 8.0. User will be able to backup and load data
> to a new master node. nova-network has been deprecated for 2 releases so we
> can remove it. If we remove it we can remove tests from acceptance testing
> as well as from auto-tests so it should remove tech debt so will release
> our QA/CI resources to focus on other tests.
>
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
>
>
> On Tue, Dec 22, 2015 at 12:28 AM, Evgeniy L <e...@mirantis.com> wrote:
>
> Hi,
>
>
>
> We mustn't touch Nailgun's logic, otherwise after upgrade user won't be
> able
>
> to manage her/his old nova Cluster. So lets just remove it from UI.
>
> Also as far as I know we should provide a way to manage old clusters not
>
> for a release, but for a couple of years.
>
>
>
> Thanks,
>
>
>
> On Tue, Dec 22, 2015 at 10:40 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>
> 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
> <akasat...@mirantis.com> 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
> > <sgolovat...@mirantis.com> 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 <sgreg...@mirantis.com>
> >> 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
> >>>
> >>>
> >>>
&g

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Aleksey Kasatkin]

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 <sgolovat...@mirantis.com
> 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 <sgreg...@mirantis.com>
> 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
>> <http://www.mirantis.com/>
>>
>> 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

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

[Aleksey Kasatkin]

+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

Re: [openstack-dev] [Fuel] Nominating Roman Prykhodchenko to python-fuelclient cores

[Aleksey Kasatkin]

+1.
No doubts. )


Aleksey Kasatkin


On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov <dpyz...@mirantis.com> wrote:

> Guys,
>
> I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is
> the main contributor and maintainer of this repo. And he did a great job
> making changes toward OpenStack recommendations. Cores, please reply with
> your +1/-1.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Remove nova-network as a deployment option in Fuel?

[Aleksey Kasatkin]

It can be selected but we have no tests for deployment which are run on
periodical basis. So, we do not have any recent status.
Also, serializer in Nailgun for Nova-Network is now not in use (it is not
tested how serialization will work in 8.0).


Aleksey Kasatkin


On Tue, Dec 1, 2015 at 9:36 AM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:

> Aleksey, can you clarify it? Why it can't be deployed? According to what I
> see at our fakeUI install [1], wizard allows to choose nova-network only in
> case if you choose vcenter.
>
> Do we support Neutron for vCenter already? If so - we could safely remove
> nova-network altogether.
>
> [1] http://demo.fuel-infra.org:8000/
>
> On Mon, Nov 30, 2015 at 4:27 AM Aleksey Kasatkin <akasat...@mirantis.com>
> wrote:
>
>> This remains unclear.
>> Now, for 8.0, the Environment with Nova-Network can be created but cannot
>> be deployed (and its creation is tested in UI integration tests).
>> AFAIC, we should either remove the ability of creation of environments
>> with Nova-Network in 8.0 or return it back into working state.
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Fri, Oct 23, 2015 at 3:42 PM, Sheena Gregson <sgreg...@mirantis.com>
>> wrote:
>>
>>> As a reminder: there are no individual networking options that can be
>>> used with both vCenter and KVM/QEMU hypervisors once we deprecate
>>> nova-network.
>>>
>>>
>>>
>>> The code for vCenter as a stand-alone deployment may be there, but the
>>> code for the component registry (
>>> https://blueprints.launchpad.net/fuel/+spec/component-registry) is
>>> still not complete.  The component registry is required for a multi-HV
>>> environment, because it provides compatibility information for Networking
>>> and HVs.  In theory, landing this feature will enable us to configure DVS +
>>> vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment.
>>>
>>>
>>>
>>> While Andriy Popyvich has made considerable progress on this story, I
>>> personally feel very strongly against deprecating nova-network until we
>>> have confirmed that we can support *all current use cases* with the
>>> available code base.
>>>
>>>
>>>
>>> Are we willing to lose the multi-HV functionality if something prevents
>>> the component registry work from landing in its entirety before the next
>>> release?
>>>
>>>
>>>
>>> *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
>>> *Sent:* Friday, October 23, 2015 6:30 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a
>>> deployment option in Fuel?
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> As far as I know neutron code for VCenter is ready. Guys are still
>>> testing it. Keep patience... There will be announce soon.
>>>
>>>
>>> --
>>> 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
>>
> --
> 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] Remove nova-network as a deployment option in Fuel?

[Aleksey Kasatkin]

This remains unclear.
Now, for 8.0, the Environment with Nova-Network can be created but cannot
be deployed (and its creation is tested in UI integration tests).
AFAIC, we should either remove the ability of creation of environments with
Nova-Network in 8.0 or return it back into working state.


Aleksey Kasatkin


On Fri, Oct 23, 2015 at 3:42 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:

> As a reminder: there are no individual networking options that can be used
> with both vCenter and KVM/QEMU hypervisors once we deprecate nova-network.
>
>
>
> The code for vCenter as a stand-alone deployment may be there, but the
> code for the component registry (
> https://blueprints.launchpad.net/fuel/+spec/component-registry) is still
> not complete.  The component registry is required for a multi-HV
> environment, because it provides compatibility information for Networking
> and HVs.  In theory, landing this feature will enable us to configure DVS +
> vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment.
>
>
>
> While Andriy Popyvich has made considerable progress on this story, I
> personally feel very strongly against deprecating nova-network until we
> have confirmed that we can support *all current use cases* with the
> available code base.
>
>
>
> Are we willing to lose the multi-HV functionality if something prevents
> the component registry work from landing in its entirety before the next
> release?
>
>
>
> *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
> *Sent:* Friday, October 23, 2015 6:30 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a deployment
> option in Fuel?
>
>
>
> Hi,
>
>
>
> As far as I know neutron code for VCenter is ready. Guys are still testing
> it. Keep patience... There will be announce soon.
>
>
> --
> 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] Number of IP addresses in a public network

[Aleksey Kasatkin]

We have more generic ticket: https://bugs.launchpad.net/fuel/+bug/1354803
and corresponding CR: https://review.openstack.org/#/c/245941/

Aleksey Kasatkin


On Fri, Nov 20, 2015 at 11:24 AM, Aleksey Kasatkin <akasat...@mirantis.com>
wrote:

> It's not about Public networks only. There can be the same problem with
> other networks as well.
> It's required to check all the networks (across all node groups).
> But it is done just for Public network now (and VIPs for plugins are not
> taken into account).
>
>
> Aleksey Kasatkin
>
>
> On Fri, Nov 20, 2015 at 12:04 AM, Andrew Woodward <xar...@gmail.com>
> wrote:
>
>> The high value of the bug here reflects that the error message is wrong.
>> From a UX side we could maybe even justify this as Critical. The error
>> message must reflect the correct quantity of addresses required.
>>
>>
>> On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko <m...@romcheg.me>
>> wrote:
>>
>>> Folks, we should resurrect this thread and find a consensus.
>>>
>>> 1 вер. 2015 р. о 15:00 Andrey Danin <ada...@mirantis.com> написав(ла):
>>>
>>>
>>> +1 to Igor.
>>>
>>> It's definitely not a High bug. The biggest problem I see here is a
>>> confusing error message with a wrong number of required IPs. AFAIU we
>>> cannot fix it easily now so let's postpone it to 8.0 but change a message
>>> itself [0] in 7.0.
>>>
>>> We managed to create an error that returns '7', when there are 8
>> available, but 9 are required, at some level we knew that we came up short
>> or we'd just have some lower level error caught here.
>>
>>>
>>> [0]
>>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>>>
>>> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> My 5 cents on it.
>>>>
>>>> I don't think it's really a High or Critical bug for 7.0. If there's
>>>> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
>>>> actually Ok, it may fail by different reason without starting actual
>>>> deployment (sending message to Astute).
>>>>
>>>> But I agree it's kinda strange that we don't check IPs during network
>>>> verification step. The good fix in my opinion is to move this check
>>>> into network checker (perhaps keep it here either), but that
>>>> definitely shouldn't be done in 7.0.
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>>
>>>> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko <m...@romcheg.me>
>>>> wrote:
>>>> > Hi folks!
>>>> >
>>>> > Recently a problem that network check does not tell whether there’s
>>>> enough IP addresses in a public network [1] was reported. That check is
>>>> performed by CheckBeforeDeployment task, but there is two problems that
>>>> happen because this verification is done that late:
>>>> >
>>>> >  - A deployment fails, if there’s not enough addresses in specified
>>>> ranges
>>>> >  - If a user wants to get network configuration they will get an error
>>>> >
>>>> > The solution for this problems seems to be easy and a straightforward
>>>> patch [2] was proposed. However, there is a hidden problem which is that
>>>> patch does not address which is that installed plugins may reserve VIPs for
>>>> their needs. The issue is that they do it just before deployment and so
>>>> it’s not possible to get those reservations when a user wants to check
>>>> their network set up.
>>>> >
>>>> > The important issue we have to address here is that network
>>>> configuration generator will fail, if specified ranges don’t fit all VIPs.
>>>> There were several proposals to fix that, I’d like to highlight two of 
>>>> them:
>>>> >
>>>> >  a) Allow VIPs to not have an IP address assigned, if network config
>>>> generator works for API output.
>>>> >  That will prevent GET requests from failure, but since IP
>>>> addresses for VIPs are required, generator will have to fail, if it
>>>> generates a configuration for the orchestrator.
>>>> >  b) Add a release note that users have to calculate IP addresses
>>>> manually and put sane ranges i

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

[Aleksey Kasatkin]

It's not about Public networks only. There can be the same problem with
other networks as well.
It's required to check all the networks (across all node groups).
But it is done just for Public network now (and VIPs for plugins are not
taken into account).


Aleksey Kasatkin


On Fri, Nov 20, 2015 at 12:04 AM, Andrew Woodward <xar...@gmail.com> wrote:

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

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Mike, Vladimir,

Yes,
1. We need to add IPs on-the-fly (need to add POST functionality) ,
otherwise it will be VIP-like way (change network roles in plugin or
release).
2. We should allow to leave fields 'network_role', 'node_roles', 'namespace'
empty. So, validation should be changed.

So, answer here

> Q. Any allocated IP could be accessible via these handlers, so now we can
> restrict user to access VIPs only
> and answer with some error to other ip_addrs ids.
>
should be "Any allocated IP is accessible via these handlers", so URLs can
be changed to
/clusters//network_configuration/ips/
/clusters//network_configuration/ips//
Nodes IPs maybe the different story though.

Alex,

'node_roles' determines in what node group to allocate IP. So, it will be
group with controller nodes for our base VIPs
(they all have node_roles=['controller'] which is default setting).
It can be some other node group for nodes with different role. E.g. ceph
nodes use some ceph/vip network role and VIP is defined
for this network role (with 'network_role'='ceph/vip' and
'node_roles'=['ceph/osd']).
This VIP will be allocated
in the network that 'ceph/vip' is mapped to and in the node group where
ceph nodes are located. ceph nodes cannot be located
in more than one node group then (as VIP cannot migrate between node groups
now).



Aleksey Kasatkin


On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> +1 to Mike
>
> It would be awesome to get an API handler that allows one to actually add
> an ip address to IP_addrs table. As well as an IP range to ip_ranges table.
>
> On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov <mscherba...@mirantis.com>
> wrote:
>
>> Is there a way to make it more generic, not "VIP" specific? Let's say I
>> want to reserve address(-es) for something for whatever reason, and then I
>> want to use them by some tricky way.
>> More specifically, can we reserve IP address(-es) with some codename, and
>> use it later?
>> 12.12.12.12 - my-shared-ip
>> 240.0.0.2 - my-multicast
>> and then use them in puppet / whatever deployment code by $my-shared-ip,
>> $my-multicast?
>>
>> Thanks,
>>
>> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin <akasat...@mirantis.com>
>> wrote:
>>
>>> Folks,
>>>
>>> Here is a resume of our recent discussion:
>>>
>>> 1. Add new URLs for processing VIPs:
>>>
>>> /clusters//network_configuration/vips/ (GET)
>>> /clusters//network_configuration/vips// (GET, PUT)
>>>
>>> where  is the id in ip_addrs table.
>>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>>> address) for one VIP by its id.
>>> More possibilities can be added later.
>>>
>>> Q. Any allocated IP could be accessible via these handlers, so now we
>>> can restrict user to access VIPs only
>>> and answer with some error to other ip_addrs ids.
>>>
>>> 2. Add current VIP meta into ip_addrs table.
>>>
>>> Create new field in ip_addrs table for placing VIP metadata there.
>>> Current set of ip_addrs fields:
>>> id (int),
>>> network (FK),
>>> node (FK),
>>> ip_addr (string),
>>> vip_type (string),
>>> network_data (relation),
>>> node_data (relation)
>>>
>>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>>
>>> 3. Allocate VIPs on cluster creation and seek VIPs at all network
>>> changes.
>>>
>>> So, VIPs will be checked (via network roles descriptions) and
>>> re-allocated in ip_addrs table
>>> at these points:
>>> a. create cluster
>>> b. modify networks configuration
>>> c. modify one network
>>> d. modify network template
>>> e. change nodes set for cluster
>>> f. change node roles set on nodes
>>> g. modify cluster attributes (change set of plugins)
>>> h. modify release
>>>
>>> 4. Add 'manual' field into VIP meta to indicate whether it is
>>> auto-allocated or not.
>>>
>>> So, whole VIP description may look like:
>>> {
>>> 'name': 'management'
>>> 'network_role': 'mgmt/vip',
>>> 'namespace': 'haproxy',
>>> 'node_roles': ['controller'],
>>>     'alias': 'management_vip',
>>> 'manual': True,
>>> }
>>>
>>> Example of current VIP description:
>>>
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>>>
>>> Nailgun will re

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Igor,

> For VIP allocation we should use POST request. It's ok to use PUT for
setting (changing) IP address.

My proposal is about setting IP addresses for VIPs only (auto and manual).
No any other allocations.
Do you propose to use POST for first-time IP allocation and PUT for IP
re-allocation?
Or use POST for adding entries to some new 'vips' table (so that all VIPs
descriptions
will be added there from network roles)?

> We don't store network_role, namespace and node_roles within VIPs.
> They are belonged to network roles. So how are you going to retrieve
> them? Did you plan to make some changes to our data model? You know,
> it's not a good idea to make connections between network roles and
> VIPs each time your make a GET request to list them.

It's our current format we use in API when VIPs are being retrieved.
Do you propose to use different one for address allocation?

> Should we return VIPs that aren't allocated, and if so - why? If they
> would be just, you know, fetched from network roles - that's a bad
> design. Each VIP should have an explicit entry in VIPs database table.

I propose to return VIPs even w/o IP addresses to show user what VIPs he has
so he can assign IP addresses to them. Yes, I supposed that the information
will be retrieved from network roles as it is done now. Do you propose to
create
separate table for VIPs or extend ip_addrs table to store VIPs information?

> We definitely should handle `null` this way, but I think from API POV
> it would be more clearer just do not pass `ipaddr` value if user wants
> it to be auto allocated. I mean, let's keep `null` as implementation
> details ans force API users just do not pass this key if they don't
> want to.

Oh, I didn't write it here, I thought about keeping IP addresses as is when
corresponding key is skipped by the user.

>The thing is that there's no way to *warn* users through API. You
> could either reject or accept request. So all we can do is to
> introduce some `force` flag, and if it's passed - ignore overlapping.

It is now done for network verification that it can pass with warning
message.
But I like your proposal better.

> overlaps with the network of current environment which does not
> match the network role of the VIP?

So, when IP address of the VIP matches some IP range that corresponds
to the network which is different from the one that network role bound to
the VIP has.
E.g. IP address matches the 'public' network but VIP is bound to
'management/vip' role
which is mapped to 'management' network.


Thanks,



Aleksey Kasatkin


On Mon, Nov 2, 2015 at 7:06 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Hey Aleksey,
>
> I agree that we need a separate API call for VIP allocation, thought I
> don't agree on some points you have proposed. See my comments below.
>
> > use PUT to change VIPs addresses (set them manually or request
> > to allocate them automatically)
>
> PUT requests SHOULD NOT be used for VIP allocation, by RESTful API
> notation the PUT request should be used for changing (editing)
> entities, not for creating new ones. For VIP allocation we should use
> POST request. It's ok to use PUT for setting (changing) IP address.
>
> > vips: [
> > {
> > 'network_role': 'management',
> > 'namespace': 'haproxy',
> > 'ipaddr': '10.10.10.10',
> > 'node_roles': ['controller']
> > },...
> > ]
>
> There I have two comments:
>
> * We don't need the "vips" word in API output - let's return a JSON
> list with VIPs and that's it.
> * We don't store network_role, namespace and node_roles within VIPs.
> They are belonged to network roles. So how are you going to retrieve
> them? Did you plan to make some changes to our data model? You know,
> it's not a good idea to make connections between network roles and
> VIPs each time your make a GET request to list them.
>
> > When it is set to None, IP address will be allocated automatically
>
> We definitely should handle `null` this way, but I think from API POV
> it would be more clearer just do not pass `ipaddr` value if user wants
> it to be auto allocated. I mean, let's keep `null` as implementation
> details ans force API users just do not pass this key if they don't
> want to.
>
> > When the user runs GET request for the first time, all 'ipaddr'
> > fields are equal to None.
>
> Should we return VIPs that aren't allocated, and if so - why? If they
> would be just, you know, fetched from network roles - that's a bad
> design. Each VIP should have an explicit entry in VIPs database table.
>
> > There is a question, what to do when the given address overlaps
> > with the network from another environment? My opinion that those
> > should pass with a warn

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Folks,

Here is a resume of our recent discussion:

1. Add new URLs for processing VIPs:

/clusters//network_configuration/vips/ (GET)
/clusters//network_configuration/vips// (GET, PUT)

where  is the id in ip_addrs table.
So, user can get all VIPS, get one VIP by id, change parameters (IP
address) for one VIP by its id.
More possibilities can be added later.

Q. Any allocated IP could be accessible via these handlers, so now we can
restrict user to access VIPs only
and answer with some error to other ip_addrs ids.

2. Add current VIP meta into ip_addrs table.

Create new field in ip_addrs table for placing VIP metadata there.
Current set of ip_addrs fields:
id (int),
network (FK),
node (FK),
ip_addr (string),
vip_type (string),
network_data (relation),
node_data (relation)

Q. We could replace vip_type (it contains VIP name now) with vip_info.

3. Allocate VIPs on cluster creation and seek VIPs at all network changes.

So, VIPs will be checked (via network roles descriptions) and re-allocated
in ip_addrs table
at these points:
a. create cluster
b. modify networks configuration
c. modify one network
d. modify network template
e. change nodes set for cluster
f. change node roles set on nodes
g. modify cluster attributes (change set of plugins)
h. modify release

4. Add 'manual' field into VIP meta to indicate whether it is
auto-allocated or not.

So, whole VIP description may look like:
{
'name': 'management'
'network_role': 'mgmt/vip',
'namespace': 'haproxy',
'node_roles': ['controller'],
'alias': 'management_vip',
'manual': True,
}

Example of current VIP description:
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207

Nailgun will re-allocate VIP address if 'manual' == False.

5. Q. what to do when the given address overlaps with the network from
another
environment? overlaps with the network of current environment which does
not match the
network role of the VIP?

Use '--force' parameter to change it. PUT will fail otherwise.


Guys, please review this and share your comments here,

Thanks,



Aleksey Kasatkin


On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin <akasat...@mirantis.com>
wrote:

> Igor,
>
> > For VIP allocation we should use POST request. It's ok to use PUT for
> setting (changing) IP address.
>
> My proposal is about setting IP addresses for VIPs only (auto and manual).
> No any other allocations.
> Do you propose to use POST for first-time IP allocation and PUT for IP
> re-allocation?
> Or use POST for adding entries to some new 'vips' table (so that all VIPs
> descriptions
> will be added there from network roles)?
>
> > We don't store network_role, namespace and node_roles within VIPs.
> > They are belonged to network roles. So how are you going to retrieve
> > them? Did you plan to make some changes to our data model? You know,
> > it's not a good idea to make connections between network roles and
> > VIPs each time your make a GET request to list them.
>
> It's our current format we use in API when VIPs are being retrieved.
> Do you propose to use different one for address allocation?
>
> > Should we return VIPs that aren't allocated, and if so - why? If they
> > would be just, you know, fetched from network roles - that's a bad
> > design. Each VIP should have an explicit entry in VIPs database table.
>
> I propose to return VIPs even w/o IP addresses to show user what VIPs he
> has
> so he can assign IP addresses to them. Yes, I supposed that the
> information
> will be retrieved from network roles as it is done now. Do you propose to
> create
> separate table for VIPs or extend ip_addrs table to store VIPs information?
>
> > We definitely should handle `null` this way, but I think from API POV
> > it would be more clearer just do not pass `ipaddr` value if user wants
> > it to be auto allocated. I mean, let's keep `null` as implementation
> > details ans force API users just do not pass this key if they don't
> > want to.
>
> Oh, I didn't write it here, I thought about keeping IP addresses as is
> when
> corresponding key is skipped by the user.
>
> >The thing is that there's no way to *warn* users through API. You
> > could either reject or accept request. So all we can do is to
> > introduce some `force` flag, and if it's passed - ignore overlapping.
>
> It is now done for network verification that it can pass with warning
> message.
> But I like your proposal better.
>
> > overlaps with the network of current environment which does not
> > match the network role of the VIP?
>
> So, when IP address of the VIP matches some IP range that corresponds
> to the network which is different from the one that network role bound to
> the VIP ha

[openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Hi folks,

I'm working on the following story [1][2]:
API must allow VIP to be manually set to ANY valid IP address. If the IP on
update API is a member of any network in this environment then the address
should be put in the assignments table so that it can not be used in any
other
automatic assignment. (This allows the user to override if the automatic
allocation doesn't match their needs or in the case that they want to use
external LB).

[1] https://bugs.launchpad.net/fuel/+bug/1482399
[2] https://review.openstack.org/230943

So, I have the following proposal for now:
Add new url (e.g. /clusters//network_configuration/vips/ ), use
GET
to query current VIPs info, use PUT to change VIPs addresses (set them
manually
or request to allocate them automatically).
Now VIPs have the following format in API requests data:
vips: [
{
'network_role': 'management',
'namespace': 'haproxy',
'ipaddr': '10.10.10.10',
'node_roles': ['controller']
},...
]
So, 'ipaddr' field can be set to any (almost any) user-defined value or to
None (null in YAML).
When it is set to None, IP address will be allocated automatically. When
the user runs GET
request for the first time, all 'ipaddr' fields are equal to None. So, user
can set some (or all)
of them to desired values and run PUT. When the GET is run after PUT, all
addresses will be
filled with values. User can reset some of them to None or change to other
IP when required.
So, addresses will be re-allocated on the next PUT requests.
If address given by user overlaps with some of the allocated IPs, PUT
request will be rejected.
There is a question, what to do when the given address overlaps with the
network from another
environment? overlaps with the network of current environment which does
not match the
network role of the VIP?
My opinion that those should pass with a warning message.

Please share your proposals and comments on this,

Thanks,


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

Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Aleksey Kasatkin]

Sergii,

1. We only have auto-doc for developers which should be changed
automatically.
2. We do not have proper API versioning. We didn't decide yet how to
resolve it. Let's discuss versioning in "[Fuel] Changing APIs and API
versioning" thread.


Aleksey Kasatkin


On Wed, Oct 21, 2015 at 5:26 PM, Vitaly Kramskikh <vkramsk...@mirantis.com>
wrote:

> Sergii,
>
> Let's move this discussion to the thread "[Fuel] Changing APIs and API
> versioning". We need to have this mechanism regardless of our decision on
> API versioning.
>
> 2015-10-21 20:31 GMT+07:00 Sergii Golovatiuk <sgolovat...@mirantis.com>:
>
>> Vitaliy,
>>
>> Why do merge API changes without:
>>
>> 1. Fixing documentation?
>> 2. bumping API version?
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Wed, Oct 21, 2015 at 3:08 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> It's yet another time we broke fuelclient by merging a change
>>> <https://review.openstack.org/#/c/232021/> in fuel-web repo. Since we
>>> are considering moving Fuel UI to a separate repo, and we need to run UI
>>> functional tests against changes in nailgun anyway, I think we should start
>>> to change our CI so it could run tests from another repo against changes in
>>> another repo.
>>>
>>> Can it be done?
>>>
>>> --
>>> 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] Assigning VIPs on network config serialization

[Aleksey Kasatkin]

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

AFAIC, no. We should check whether there is enough IPs for nodes /
VIPs with current network configuration.

I'd propose to add a handler for allocation of VIPs if VIPs can be useful
before deployment.
I'm not sure what are the cases.



Aleksey Kasatkin


On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko <m...@romcheg.me> wrote:

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

Re: [openstack-dev] [Fuel][Plugins][Ironic] Deploy Ironic with fuel ?

[Aleksey Kasatkin]

+ Pavlo, Andrey.


Aleksey Kasatkin


On Mon, Oct 19, 2015 at 6:45 AM, <loic.nico...@orange.com> wrote:

> Hello,
>
>
>
> I’m currently searching for information about Ironic Fuel plugin :
> https://github.com/openstack/fuel-plugin-ironic I don’t find any
> documentation on it.
>
>
>
> I’ve tried to install and deploy an Openstack environment with Fuel 7.0
> and Ironic plugin but it failed. After adding ironic role to a node Fuel UI
> crashed, due to a missing network “baremetal” . When creating a network
> group
>
>
>
> fuel network-group --create --node-group 1 --name \
>
> "baremetal" --cidr 192.168.3.0/24
>
> UI works again, but I got some errors in the deployment, during network
> configuration. So I think I have to configure a network template, did
> someone already do this for this plugin ?
>
>
>
> Regards,
>
>
>
> Loic
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (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] Assigning VIPs on network config serialization

[Aleksey Kasatkin]

Hi!

I mostly agree with Igor, GET request should not produce changes (i.e.
allocate VIPs).

> VIP allocation should be performed when we run deployment.

I want to give an explanation here. We have a ticket for 8.0 to give an
ability to set arbitrary addresses for VIPs. So, at least some of VIPs can
be set via API calls. And auto-allocation of addresses for VIPs should be
done just before deployment. The only concern here, whether we need a VIP
for net-checker. We could allocate VIPs on net-checker request then also
(it is PUT request).

AFAIC, we also need to provide an ability to run CheckBeforeDeployment task
separately (only within ApplyChanges for now). It will help the user to
diagnose different problems. It seems to be a subject for another
discussion/ticket though.

Thanks,




Aleksey Kasatkin


On Mon, Oct 19, 2015 at 11:28 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

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

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

[Aleksey Kasatkin]

+1 to Sebastian. And, AFAIK, there is no user docs (or about no docs) on
CLI v2. Even for 7.0 new features were documented using CLI v1.



Aleksey Kasatkin


On Fri, Oct 16, 2015 at 3:38 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> +1 to Sebastian.
>
> On Wed, Oct 14, 2015 at 12:13 PM, Sebastian Kalinowski
> <skalinow...@mirantis.com> wrote:
> > Roman, this was already discussed in [1].
> > The conclusion was that we will implement new features in both places so
> > user will not have to
> > use "old" fuelclient to do some things and the "new" to others.
> > There were no progress with moving old commands to new CLI and I didn't
> seen
> > plans to do so.
> > IMHO without a detailed plan on migrating old commands to new client and
> > without a person (or people)
> > that will drive this task we *cannot* freeze old fuelclient as new one is
> > still not fully usable.
> >
> > Best,
> > Sebastian
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html
> >
> >
> > 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko <m...@romcheg.me>:
> >>
> >> Fuelers,
> >>
> >> as you know a big effort has been put into making Fuel Client’s CLI
> better
> >> and as a result we got a new fuel2 utility with a new set of commands
> and
> >> options. Some folks still put great effort to move everything that’s
> left in
> >> the old CLI to the new CLI.
> >>
> >> Every new thing added to the old CLI moves the point where we can
> finally
> >> remove it to the future. My proposal is to do a hard code freeze for
> the old
> >> CLI and only add new stuff to the new one.
> >>
> >>
> >> - romcheg
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (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] Core Reviewers groups restructure

[Aleksey Kasatkin]

Hi,

Just a remark: python-fuelclient is missing here.


Aleksey Kasatkin


On Sun, Sep 20, 2015 at 3:56 PM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:

> Hi all,
> as of my larger proposal on improvements to code review workflow [1], we
> need to have cores for repositories, not for the whole Fuel. It is the path
> we are taking for a while, and new core reviewers added to specific repos
> only. Now we need to complete this work.
>
> My proposal is:
>
>1. Get rid of one common fuel-core [2] group, members of which can
>merge code anywhere in Fuel. Some members of this group may cover a couple
>of repositories, but can't really be cores in all repos.
>2. Extend existing groups, such as fuel-library [3], with members from
>fuel-core who are keeping up with large number of reviews / merges. This
>data can be queried at Stackalytics.
>3. Establish a new group "fuel-infra", and ensure that it's included
>into any other core group. This is for maintenance purposes, it is expected
>to be used only in exceptional cases. Fuel Infra team will have to decide
>whom to include into this group.
>4. Ensure that fuel-plugin-* repos will not be affected by removal of
>fuel-core group.
>
> #2 needs specific details. Stackalytics can show active cores easily, we
> can look at people with *:
> http://stackalytics.com/report/contribution/fuel-web/180. This is for
> fuel-web, change the link for other repos accordingly. If people are added
> specifically to the particular group, leaving as is (some of them are no
> longer active. But let's clean them up separately from this group
> restructure process).
>
>- fuel-library-core [3] group will have following members: Bogdan D.,
>Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko.
>- fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin,
>Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak
>- fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li
>- fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K.
>- fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky, Nastya
>Urlapova
>- fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny
>Konstantinov, Olga Gusarenko
>- fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry
>Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky
>- fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov
>- fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey
>Sledzinsky, Dmitry Shulyak
>- fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin
>- fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya
>Urlapova
>- fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly
>Kramskikh
>- fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey
>Kasatkin (this project seems to be dead, let's consider to rip it off)
>- fuel-specs-core: there is no such a group at the moment. I propose
>to create one with following members, based on stackalytics data [16]:
>Vitaly Kramskikh, Bogdan Dobrelia, Evgeny Li, Sergii Golovatyuk, Vladimir
>Kuklin, Igor Kalnitsky, Alexey Kasatkin, Roman Vyalov, Dmitry Borodaenko,
>Mike Scherbakov, Dmitry Pyzhov. We would need to reconsider who can merge
>after Fuel PTL/Component Leads elections
>- fuel-octane-core: needs to be created. Members: Yury Taraday, Oleg
>Gelbukh, Ilya Kharin
>- fuel-mirror-core: needs to be created. Sergey Kulanov, Vitaly
>Parakhin
>- fuel-upgrade-core: needs to be created. Sebastian Kalinowski, Alex
>Schultz, Evgeny Li, Igor Kalnitsky
>- fuel-provision: repo seems to be outdated, needs to be removed.
>
> I suggest to make changes in groups first, and then separately address
> specific issues like removing someone from cores (not doing enough reviews
> anymore or too many positive reviews, let's say > 95%).
>
> I hope I don't miss anyone / anything. Please check carefully.
> Comments / objections?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> [2] https://review.openstack.org/#/admin/groups/209,members
> [3] https://review.openstack.org/#/admin/groups/658,members
> [4] https://review.openstack.org/#/admin/groups/664,members
> [5] https://review.openstack.org/#/admin/groups/655,members
> [6] https://review.openstack.org/#/admin/groups/646,members
> [7] https://review.openstack.org/#/admin/groups/656,members
> [8] https://review.openstack.org/#/admin/groups/657,members
> [9] https://review.openstack.org/#/admin/groups/659,members
> [10] https://review.openstack.org/#/admin/groups/1000,members
> [11] https://review.openstack

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

[Aleksey Kasatkin]

 We don't promise use Junja (or whatever) template language for this
 feature.
 If some jinja features allowed for parsing Network template -- it's a bug.
 We should check it and fix it.
 Only value substitutions should allow in the network templates.


Yes, we just use jinja for values substitution. We could replace it with
anything else suitable here.
I don't see any reason to stick to jinja anyhow.

That is not correct, every template has it's own syntax, so people have to
 care about
 specific implementation i.e. Jinja or ERB, and there will be confusion
 when somebody will
 try to use ERB specific features, and she/he will fail because you hide
 Jinja under ERB
 syntax.


Format of template should be defined in docs finally. It is defined in spec
and there is explanation in slides for Demo.
It is not about jinja or ERB. It is just a token for substitution of
values. There is no jinja nor ERB features granted within template language.



Aleksey Kasatkin


On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko svasile...@mirantis.com
wrote:


 On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L e...@mirantis.com wrote:

 Hi Alexander, I don't agree with your statements

  [1] - I just uses % and % to substitute values.

 It's what templating is about, you have some text preprocessor to
 substitute values.


 Network templates feature don't mean any  text preprocessor actions.
 Only value substitutions


  That is not ERB style template language.

 ERB uses the same syntax, hence it Is ERB style.


 ... hence it looks like ERB. not more.
 Not only ruby used for programming. Non only EBD -- is template language.
 ;)


  [2] - We are not using Jinja templating (it is just yaml file, not
 html template), we are using Jinja placeholder substitution.

 We *are using* jinja templating (I don't understand why you mention here
 html),
 with all it's features and here is the proof [1].


 We don't promise use Junja (or whatever) template language for this
 feature.
 If some jinja features allowed for parsing Network template -- it's a bug.
 We should check it and fix it.
 Only value substitutions should allow in the network templates.


  [3] - Templates are for people who do not care about Jinja/ERB (maybe
 some familiar with Puppet/Chef), so no confusion.

 That is not correct, every template has it's own syntax, so people have
 to care about
 specific implementation i.e. Jinja or ERB, and there will be confusion
 when somebody will
 try to use ERB specific features, and she/he will fail because you hide
 Jinja under ERB
 syntax.


 I, partially, agree with you. But please honored to following facts:
 * In the deployers world used Jinja and ERB syntax.
 * ERB used more often, because Ansible (I don't know another popular
 deployers tools with Jinja templating) is to young.
 * Plenty of syntax features is a really hell.

 In the Network templates we don't suppose anything other than a simple
 substitution variable values.
 All logic of template processing implementing on Nailgun side. Now on the
 template parsing, later -- on the network manipulation class.
 Allowance of mix template language and Nailgun logic may lead to heavy
 diagnostic issues.
 Meantime I don't see any cases, where required something more, than
 substitution.



 /sv

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


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

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

[Aleksey Kasatkin]

AFAIU, string.Template doesn't help.

This seems to be helpful:

import re
def interp(string, params):
  for item in re.findall(r'#\{([^}]*)\}', string):
string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
  return string


Evgeniy, do you know some better options for this?



Aleksey Kasatkin


On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko svasile...@mirantis.com
wrote:

 If we need only substitution, probably it's better to use standard
 templating
 in python [1], there is a way to redefine tokens, so you will be able to
 use
 % % syntax if you want to.

 [1] https://docs.python.org/2.6/library/string.html#template-strings
 https://docs.python.org/dev/library/string.html#template-strings
 [2] http://pymotw.com/2/string/#advanced-templates


 I think it's a better solution for this issue.

 /sv

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


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

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

[Aleksey Kasatkin]

Evgeniy, do we need to remove jinja before July 30th ?


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 6:40 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:

 AFAIU, string.Template doesn't help.

 This seems to be helpful:

 import re
 def interp(string, params):
   for item in re.findall(r'#\{([^}]*)\}', string):
 string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
   return string


 Evgeniy, do you know some better options for this?



 Aleksey Kasatkin


 On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko svasile...@mirantis.com
  wrote:

 If we need only substitution, probably it's better to use standard
 templating
 in python [1], there is a way to redefine tokens, so you will be able to
 use
 % % syntax if you want to.

 [1] https://docs.python.org/2.6/library/string.html#template-strings
 https://docs.python.org/dev/library/string.html#template-strings
 [2] http://pymotw.com/2/string/#advanced-templates


 I think it's a better solution for this issue.

 /sv

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



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

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

[Aleksey Kasatkin]

Okey, will do fix for validation first.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L e...@mirantis.com wrote:

 Aleksey, here is working version [1].

  Evgeniy, do we need to remove jinja before July 30th ?

 With this issue feature can leave, and it won't have huge user impact.
 At the same time by design we didn't want to have anything except
 substitution, hence it's probably as Sergey mentioned is a bug.
 So looks like it can be fixed after 30th of July, and should not be
 considered as a blocker. Validation is much more important, so lets
 fix it first.

 [1] http://paste.openstack.org/show/406104/


 On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko svasile...@mirantis.com
  wrote:


 On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin akasat...@mirantis.com
  wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


 I think -- not.
 It just a bug, not a key-point of feature.


 /sv

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



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


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

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

[Aleksey Kasatkin]

Evgeniy, thank you for solution proposal.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:39 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:

 Okey, will do fix for validation first.


 Aleksey Kasatkin


 On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L e...@mirantis.com wrote:

 Aleksey, here is working version [1].

  Evgeniy, do we need to remove jinja before July 30th ?

 With this issue feature can leave, and it won't have huge user impact.
 At the same time by design we didn't want to have anything except
 substitution, hence it's probably as Sergey mentioned is a bug.
 So looks like it can be fixed after 30th of July, and should not be
 considered as a blocker. Validation is much more important, so lets
 fix it first.

 [1] http://paste.openstack.org/show/406104/


 On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko 
 svasile...@mirantis.com wrote:


 On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin 
 akasat...@mirantis.com wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


 I think -- not.
 It just a bug, not a key-point of feature.


 /sv


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



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



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

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

[Aleksey Kasatkin]

It's not clear though.
The date for landing of all the patches was set 28th (tomorrow) but it took
into account only patch to CLI actually  as other 2 from the initial letter
were merged on 23th.
These two more things (validation + tokens) could barely be completed
tomorrow.
AFAIC, at least validation cannot be completed tomorrow. We can test tokens
today.
For some basic validation - the is a chance, but no certaincy.


Aleksey Kasatkin


On Mon, Jul 27, 2015 at 1:00 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:

 Evgeniy,

  3. Change tokens in template language

 I'm not sure what do you mean here. Could you please clarify? Perhaps
 I missed something.

 Thanks,
 Igor

 On Mon, Jul 27, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote:
  So, to summarise, +1 from me, we accept the changes which are required
  for the feature as feature freeze exceptions:
 
  1. Fuel client changes [1]
  2. Validation [2]
  3. Change tokens in template language
 
  Sebastian, Igor, correct?
 
  [1] https://review.openstack.org/#/c/204321/
  [2] https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Sat, Jul 25, 2015 at 1:25 AM, Andrew Woodward xar...@gmail.com
 wrote:
 
  Igor,
 
  https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the
 FFE
  if you think it's a feature. Networking is the most complicated and
  frustrating thing the user can work with. If we cant provide usable
 feedback
  from bad data in the template then the feature is useless. I could argue
  that its a critical UX defect.
 
 
  On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote:
 
  Aleksey,
 
  Yes, my point is those parts should be also included in the scope of
 FFE.
  Regarding to template format, it's easy to fix and after release you
 will
  not
  be able to change it, or you can change it, but you will have to
 support
  both
  format, not to brake backward compatibility. So I would prefer to see
 it
  fixed
  in 7.0.
 
  Thanks,
 
  On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin
  akasat...@mirantis.com wrote:
 
  I agree, guys, we need at least some basic validation for template
 when
  it is being loaded.
  Ivan Kliuk started to work on this task.
  And we agreed to test other types of delimiters (it is regarding ERB
  style template) but we have some more important issues.
  Evgeniy, is your meaning to include those to FFE ?
 
 
  Aleksey Kasatkin
 
 
  On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski
  skalinow...@mirantis.com wrote:
 
  I agree here with Evgeniy. Even if it's not a trivial change, we
 cannot
  leave a new API in such shape.
 
  2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:
 
  Hi Igor,
 
  I don't agree with you, some basic validation is essential part of
  any handler and our API, currently it's easy to get meaningless 500
  error
  (which is unhandled exception) from the backend or get the error
 that
  there
  is something wrong with the template only after you press deploy
  button.
  It's a bad UX and contradicts to our attempts to develop good api.
 
  Thanks,
 
  On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky
  ikalnit...@mirantis.com wrote:
 
  Greetings,
 
  The issue [1] looks like a feature to me. I'd move it to next
  release.
  Let's focus on what's important right now - stability.
 
  Thanks,
  Igor
 
  [1]: https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com
 wrote:
   Hi,
  
   Since the feature is essential, and changes are small, we can
   accept it as
   a,
   feature freeze exceptions.
  
   But as far as I know there is a very important ticket [1] which
 was
   created
   in
   order to get patches merged faster, also I still have concerns
   regarding to
   ERB style template % if3 % which is in fact Jinja. So it's
 not
   only
   about
   fixes in the client.
  
   [1] https://bugs.launchpad.net/fuel/+bug/1476779
  
   On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov
   mscherba...@mirantis.com
   wrote:
  
   Looks like the only CLI part left:
   https://review.openstack.org/#/c/204321/, and you guys did a
 great
   job
   finishing the other two.
  
   Looks like we'd need to give FF exception, as this is essential
   feature.
   It's glad that we merged all other thousands lines of code. This
   is the most
   complex feature, and seems like the only small thing is left.
  
   I'd like to hear feedback from Nailgun cores  fuel client SMEs.
   For me,
   it seems it is lower risk, and patch is relatively small. How
 long
   would it
   take to complete it? If it takes a couple of days, then it is
   fine. If it is
   going to take week or two, then we will have to have it as a
 risk
   for HCF
   deadline. Spending resources on features now, not on bugs, means
   less
   quality or slip of the release.
  
   On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin
   akasat...@mirantis.com
   wrote:
  
   Team,
  
   I would like to request an exception from the Feature Freeze
 for
   Templates

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

[Aleksey Kasatkin]

Evgeniy, I need some response in
https://bugs.launchpad.net/fuel/+bug/1476779
AFAIC, it can be 30th (Thursday) for basic validation of template itself
(regardless of present nodes and their node roles) but including known node
roles/network roles for particular environment.

Aleksey Kasatkin


On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L e...@mirantis.com wrote:

 Igor,

 Currently network template uses ERB [1] style template language,
 but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
 the user, with ERB which is in fact jinja and doesn't have any ERB
 features.

 [1]
 https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/network_template.json#L58
 [2]
 https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/objects/node.py#L854-L855
 [3]
 https://review.openstack.org/#/c/197145/42/nailgun/nailgun/fixtures/network_template.json

 On Mon, Jul 27, 2015 at 12:00 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 Evgeniy,

  3. Change tokens in template language

 I'm not sure what do you mean here. Could you please clarify? Perhaps
 I missed something.

 Thanks,
 Igor

 On Mon, Jul 27, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote:
  So, to summarise, +1 from me, we accept the changes which are required
  for the feature as feature freeze exceptions:
 
  1. Fuel client changes [1]
  2. Validation [2]
  3. Change tokens in template language
 
  Sebastian, Igor, correct?
 
  [1] https://review.openstack.org/#/c/204321/
  [2] https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Sat, Jul 25, 2015 at 1:25 AM, Andrew Woodward xar...@gmail.com
 wrote:
 
  Igor,
 
  https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the
 FFE
  if you think it's a feature. Networking is the most complicated and
  frustrating thing the user can work with. If we cant provide usable
 feedback
  from bad data in the template then the feature is useless. I could
 argue
  that its a critical UX defect.
 
 
  On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote:
 
  Aleksey,
 
  Yes, my point is those parts should be also included in the scope of
 FFE.
  Regarding to template format, it's easy to fix and after release you
 will
  not
  be able to change it, or you can change it, but you will have to
 support
  both
  format, not to brake backward compatibility. So I would prefer to see
 it
  fixed
  in 7.0.
 
  Thanks,
 
  On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin
  akasat...@mirantis.com wrote:
 
  I agree, guys, we need at least some basic validation for template
 when
  it is being loaded.
  Ivan Kliuk started to work on this task.
  And we agreed to test other types of delimiters (it is regarding ERB
  style template) but we have some more important issues.
  Evgeniy, is your meaning to include those to FFE ?
 
 
  Aleksey Kasatkin
 
 
  On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski
  skalinow...@mirantis.com wrote:
 
  I agree here with Evgeniy. Even if it's not a trivial change, we
 cannot
  leave a new API in such shape.
 
  2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:
 
  Hi Igor,
 
  I don't agree with you, some basic validation is essential part of
  any handler and our API, currently it's easy to get meaningless 500
  error
  (which is unhandled exception) from the backend or get the error
 that
  there
  is something wrong with the template only after you press deploy
  button.
  It's a bad UX and contradicts to our attempts to develop good api.
 
  Thanks,
 
  On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky
  ikalnit...@mirantis.com wrote:
 
  Greetings,
 
  The issue [1] looks like a feature to me. I'd move it to next
  release.
  Let's focus on what's important right now - stability.
 
  Thanks,
  Igor
 
  [1]: https://bugs.launchpad.net/fuel/+bug/1476779
 
  On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com
 wrote:
   Hi,
  
   Since the feature is essential, and changes are small, we can
   accept it as
   a,
   feature freeze exceptions.
  
   But as far as I know there is a very important ticket [1] which
 was
   created
   in
   order to get patches merged faster, also I still have concerns
   regarding to
   ERB style template % if3 % which is in fact Jinja. So it's
 not
   only
   about
   fixes in the client.
  
   [1] https://bugs.launchpad.net/fuel/+bug/1476779
  
   On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov
   mscherba...@mirantis.com
   wrote:
  
   Looks like the only CLI part left:
   https://review.openstack.org/#/c/204321/, and you guys did a
 great
   job
   finishing the other two.
  
   Looks like we'd need to give FF exception, as this is essential
   feature.
   It's glad that we merged all other thousands lines of code.
 This
   is the most
   complex feature, and seems like the only small thing is left.
  
   I'd like to hear feedback from Nailgun cores  fuel client
 SMEs.
   For me,
   it seems it is lower risk, and patch is relatively small. How
 long
   would

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

[Aleksey Kasatkin]

Yes, it is the only CR left (https://review.openstack.org/#/c/204321/).
It is tested manually, is on review and should be merged today or the next
workday.


Aleksey Kasatkin


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

 Looks like the only CLI part left:
 https://review.openstack.org/#/c/204321/, and you guys did a great job
 finishing the other two.

 Looks like we'd need to give FF exception, as this is essential feature.
 It's glad that we merged all other thousands lines of code. This is the
 most complex feature, and seems like the only small thing is left.

 I'd like to hear feedback from Nailgun cores  fuel client SMEs. For me,
 it seems it is lower risk, and patch is relatively small. How long would it
 take to complete it? If it takes a couple of days, then it is fine. If it
 is going to take week or two, then we will have to have it as a risk for
 HCF deadline. Spending resources on features now, not on bugs, means less
 quality or slip of the release.

 On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com
 wrote:

 Team,

 I would like to request an exception from the Feature Freeze for
 Templates for Networking feature [1].

 Exception is required for two CRs to python-fuelclient: [2],[3] and one
 CR to fuel-web (Nailgun): [4].
 These CRs are for adding ability to create/remove networks via API [4]
 and for supporting new API functionality via CLI.
 These patchsets are for adding new templates-related functionality and
 they do not change existing functionality.
 Patchsets [3],[4] are in deep review and they will hopefully be merged on
 Thursday.

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

 Thanks in advance.

 [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking
 [2] https://review.openstack.org/#/c/204321/
 [3] https://review.openstack.org/#/c/203602/
 [4] https://review.openstack.org/#/c/201217/

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

 --
 Mike Scherbakov
 #mihgen

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


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

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

[Aleksey Kasatkin]

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


Aleksey Kasatkin


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

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

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

 Hi Igor,

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

 Thanks,

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

 Greetings,

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

 Thanks,
 Igor

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

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


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



 __
 OpenStack Development Mailing List (not for usage questions

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

[Aleksey Kasatkin]

+1 for an exception. Do we have time estimate though?


Aleksey Kasatkin


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

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

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

 Hi,

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

 Thanks,

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

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

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

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

 Thanks,

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

 Hi,

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

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

 Thanks,

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

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

 Team,

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


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

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

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

 Thanks in advance.

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

 --
 Best regards,
 Oleg Gelbukh


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



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

 --
 Mike Scherbakov
 #mihgen


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



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



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


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

[Aleksey Kasatkin]

Team,

I would like to request an exception from the Feature Freeze for Templates
for Networking feature [1].

Exception is required for two CRs to python-fuelclient: [2],[3] and one CR
to fuel-web (Nailgun): [4].
These CRs are for adding ability to create/remove networks via API [4] and
for supporting new API functionality via CLI.
These patchsets are for adding new templates-related functionality and they
do not change existing functionality.
Patchsets [3],[4] are in deep review and they will hopefully be merged on
Thursday.

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

Thanks in advance.

[1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking
[2] https://review.openstack.org/#/c/204321/
[3] https://review.openstack.org/#/c/203602/
[4] https://review.openstack.org/#/c/201217/

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

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

[Aleksey Kasatkin]

Thank you Roman for driving this!

Full list of nodes statuses is:

NODE_STATUSES = Enum(
'ready',
'discover',
'provisioning',
'provisioned',
'deploying',
'error',
'removing',
)

We could combine 'provisioning', 'provisioned', 'deploying' into one maybe
as cluster has only 'deployment' status for all of that now. It seems to be
enough for cluster management.

CLUSTER_STATUSES = Enum(
'new',
'deployment',
'stopped',
'operational',
'error',
'remove',
'update',
'update_error'
)

[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/consts.py



Aleksey Kasatkin


On Wed, May 27, 2015 at 4:00 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:

 Excellent, nice to know that we're on the same page about this.

 Thank you!

 --
 Best regards,
 Oleg Gelbukh

 On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:

 Oleg,

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

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

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


 - romcheg


 27 трав. 2015 о 08:19 Oleg Gelbukh ogelb...@mirantis.com написав(ла):

 Roman,

 This looks like a great solution to me, and I like your proposal very
 much. The status of cluster derived directly from statuses of nodes is
 exactly what I was thinking about.

 I have to notes to the proposal, and I can copy them to etherpad if you
 think they deserve it:

 1) status name 'operational' seem a bit unclear to me, as it sounds more
 like something Monitoring should report: it implies that the actual
 OpenStack environment is operational, which might or might not be a case,
 and Fuel has no way to tell. I would really prefer if that status name was
 'Deployed' or something along those lines.

 2) I'm not sure if we need to keep the complex status of the cluster
 explicitly in 'cluster' table in the format you suggest. This information
 can be taken directly from 'nodes' table in Nailgun DB. For example,
 getting it in the second form you propose is as simple as:

 nailgun= SELECT status,count(status) FROM nodes GROUP BY status;
 discover|1
 ready|5

 What do you think about making it a method rather then an element of data
 model? Or that's exactly the complexity you want to get rid of?

 --
 Best regards,
 Oleg Gelbukh


 On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:

 Oleg,

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


 References:

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


 - romcheg

 22 трав. 2015 о 22:32 Oleg Gelbukh ogelb...@mirantis.com написав(ла):

 Roman,

 I'm totally for fixing Nailgun. However, the status of environment is
 not simply function of statuses of nodes in it. Ideally, it should depend
 on whether appropriate number of nodes of certain roles are in 'ready'
 status. For the meantime, it would be enough if environment was set to
 'operational' when all nodes in it become 'ready', no matter how they were
 deployed (i.e. via Web UI or CLI).

 --
 Best regards,
 Oleg Gelbukh

 On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me
 wrote:

 Hi folks!

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

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

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


 - romcheg



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

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

[Aleksey Kasatkin]

AFAIC, there are several problems (in API) here:
1. We cannot stop/reset particular nodes.
2. Cluster status doesn't address changes which were done via CLI.
3. Cluster status in its current form is not enough to manage cluster (i.e.
to determine actions what can be applied to cluster at the moment). It
doesn't reflect the fact that some nodes can be in 'provisioned' state,
some are in 'provisioning', 'deploying', 'ready' statuses.

First two seem clear enough. We could add ability to stop/reset particular
nodes and reflect CLI-driven changes in the cluster status.
To address the last point my proposal was (bug/1449086/comments/7
https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086/comments/7) to break
status into several binary states, i.e. binaries: 'new', 'deployment',
'ready', etc., each of which is set to true when cluster has at least one
node in corresponding status (I united 'provisioning', 'provisioned' and
'deploying' into one as it is done now).

Now it looks more reasonable to me to keep the original status as is and
add bitwise one mentioned above (to address states of different nodes)
because 'error' state is determinative for cluster (when cluster is in
'error' state it is no matter that some nodes are in 'ready' state).
So,
cluster is in 'new' state when all nodes are in 'discover' state,
it is in 'operational' state when all nodes are in 'ready' state,
cluster is in 'deployment' state when not all of its nodes are in 'discover'
or 'ready' state but there are no nodes in 'error' and 'removing' states.
New bitwise status is actual in 'deployment' state of cluster. It gives to
UI/CLI sufficient data to determine what actions can be applied to cluster
at the moment.

I've combined some of the states combinations into the table:

'new' flag

'deployment' flag

'ready' flag

description, actions allowed

false

false

false

There are no nodes in cluster or all nodes are in 'error'/'removing' state.
Cluster is in 'new'/'error'/'remove' state here so we don't care about
these flags.

false

true

false

All nodes are under provisioning/deployment. Deployment can be stopped.

true

true

false

Part of nodes is in 'discover' state, remaining part is under
provisioning/deployment. Deployment can be started for the first part
or/and stopped for the second part of nodes.

true

false

true

Part of nodes is in 'discover' state, remaining part is in 'ready' state.
Deployment can be started for the first part and second part can be reset.

true

true

true

We have some nodes in every of the states: 'discover',
provisioning/deployment, 'ready'. So, we can allow different actions for
nodes in different states.

false

true

true

Part of nodes is under provisioning/deployment, remaining part is in
'ready' state. Deployment can be stopped for the first part and second part
can be reset.
I didn't show another 2 combinations here as they aren't related to
'deployment'
state of cluster (as well as the first one in the table).

Also, we should be careful with the order of nodes deployment/reset. I'm
not sure whether it is written in our docs that cluster may be
non-functional if user tries to deploy nodes in the wrong order (e.g.
computes first). We could show some warnings about that. Same applies to
selective reset if we will implement it.



Aleksey Kasatkin


On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me wrote:

 Hi folks!

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

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

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


 - romcheg


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


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

Re: [openstack-dev] [Fuel] Several nominations for fuel project cores

[Aleksey Kasatkin]

1/ +1
2/ +1
3/ +1


Aleksey Kasatkin


On Tue, Apr 14, 2015 at 12:26 PM, Tatyana Leontovich 
tleontov...@mirantis.com wrote:


 3/ +1

 On Tue, Apr 14, 2015 at 11:49 AM, Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:

 +1 for separating.

 Let's follow the formal well established process.

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

 On Tue, Apr 14, 2015 at 10:32 AM, Igor Kalnitsky ikalnit...@mirantis.com
  wrote:

 Dmitry,

 1/ +1

 2/ +1

 3/ +1

 P.S: Dmitry, please send one mail per nomination next time. It's much
 easier to vote for each candidate in separate threads. =)

 Thanks,
 Igor

 On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov dpyz...@mirantis.com
 wrote:
  Hi,
 
  1) I want to nominate Vladimir Sharshov to fuel-astute core. We hardly
 need
  more core reviewers here. At the moment Vladimir is one of the main
  contributors and reviewers in astute.
 
  2) I want to nominate Alexander Kislitsky to fuel-stats core. He is
 the lead
  of this feature and one of the main authors in this repo.
 
  3) I want to nominate Dmitry Shulyak to fuel-web and fuel-ostf cores.
 He is
  one of the main contributors and reviewers in both repos.
 
  Core reviewers, please reply with +1/-1 for each nomination.
 
 
 __
  OpenStack Development Mailing List (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] Nominate Andrey Skedzinskiy for fuel-qa(devops) core

[Aleksey Kasatkin]

+1


Aleksey Kasatkin


On Tue, Apr 14, 2015 at 1:20 PM, Anastasia Urlapova aurlap...@mirantis.com
wrote:

 Andrey,
 congratulations on your new role!


 Nastya.

 On Tue, Apr 14, 2015 at 12:28 PM, Yegor Kotko yko...@mirantis.com wrote:

 +1

 On Tue, Apr 14, 2015 at 11:27 AM, Tatyana Leontovich 
 tleontov...@mirantis.com wrote:

 +1

 On Tue, Apr 14, 2015 at 10:41 AM, Yuriy Shamray isham...@mirantis.com
 wrote:

 +1.

 On Mon, Apr 13, 2015 at 10:15 PM, Igor Kalnitsky 
 ikalnit...@mirantis.com wrote:

 +1.

 On Mon, Apr 13, 2015 at 4:09 PM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
  Strong +1
 
  Nastya forgot to mention Andey's participation in Ubuntu 14.04
 feature.
  With Andrey's help the feature went smooth and easy ;)
 
 
  --
  Best regards,
  Sergii Golovatiuk,
  Skype #golserge
  IRC #holser
 
  On Mon, Apr 13, 2015 at 12:37 PM, Vladimir Kuklin 
 vkuk...@mirantis.com
  wrote:
 
  +1
 
  On Mon, Apr 13, 2015 at 11:37 AM, Alexander Kislitsky
  akislit...@mirantis.com wrote:
 
  Andrew shows great attention to the details. +1 for him.
 
  On Mon, Apr 13, 2015 at 11:22 AM, Anastasia Urlapova
  aurlap...@mirantis.com wrote:
 
  Guys,
  I would like to nominate Andrey Skedzinskiy[1] for
  fuel-qa[2]/fuel-devops[3] core team.
 
  Andrey is one of the strongest reviewers, under his watchful eye
 are
  such features as:
  - updrade/rollback master node
  - collect usage information
  - OS patching
  - UI tests
  and others
 
  Please vote for Andrey!
 
 
  Nastya.
 
  [1]
 http://stackalytics.com/?project_type=stackforgeuser_id=asledzinskiy
  [2]https://github.com/stackforge/fuel-qa
  [3]https://github.com/stackforge/fuel-devops
 
 
 
 __
  OpenStack Development Mailing List (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
 
 
 
 
  --
  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
 
 
 
 
 __
  OpenStack Development Mailing 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,
 Shamray Yuriy
 QA/DevOps, Mirantis, Inc.
 Skype: ss-yuriy
 +38 (098) 400 48 41
 38 Lenina ave., Kharkov, Ukraine
 www.mirantis.com http://www.mirantis.ru/





 __
 OpenStack Development Mailing List (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] tracking bugs superseded by blueprints

[Aleksey Kasatkin]

I think it is better to keep such bugs open. Please see
https://blueprints.launchpad.net/fuel/+spec/granular-network-functions .
There are some related bugs here. One is fixed, another one is in progress,
two are closed. If bug is strictly coherent with blueprint (like
https://bugs.launchpad.net/fuel/+bug/1355764 for this BP) is can be closed
almost without doubt. But some of them can be solved separately somehow or
have workarounds. Sometimes scope of BP can be changed (e.g. split to
several BPs) or its timeline is changed so bugs should not be lost without
care.



Aleksey Kasatkin


On Tue, Feb 24, 2015 at 12:01 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 Bogdan,
 I think we should keep bugs open and not supersed them by blueprint. I
 see following reasons for it.

 Often, we can find workaround in order to fix the bug. Even if bug
 naturally seems to be falling into some blueprint's scope. Then problem is
 that when you close the bug, you don't even try to think about workaround -
 and project gets shipped with some serious gaps from release to release.

 Another issue is that you lose real technical requirements for blueprints.
 If you keep bugs open and associated with blueprint, you will pass by bugs
 a few times before you deliver blueprint's functionality, and finally close
 bugs if code covers bug's case. At least, I'd like it to be so.

 Finally, QA and users will keep opening duplicates, as no one will be
 happy with won't fix. You can vote for bug (by affecting it), and you
 can't for blueprint in LP, unfortunately. This just keeps door open for
 getting feedback.

 I don't really see any cons of moving bugs into Won't fix state instead.

 Examples of bugs which I would certainly avoid putting into Won't fix:
 https://bugs.launchpad.net/bugs/1398817 - disable computes by default
 during scale up
 https://bugs.launchpad.net/fuel/+bug/1422856 - separate /var  /var/log
 on master node

 Thanks,

 On Wed, Feb 18, 2015 at 8:46 PM, Andrew Woodward xar...@gmail.com wrote:

 Bogdan,

 Yes I think tracking the bugs like this would be beneficial. We should
 also link them from the BP so that the imperilmenter can track them. It
 adds related blueprints in the bottom of the right column under the
 subscribers so we probably should also edit the description so that the
 data is easy to see

 On Wed, Feb 18, 2015 at 8:12 AM, Bogdan Dobrelya bdobre...@mirantis.com
 wrote:

 Hello.
 There is inconsistency in the triage process for Fuel bugs superseded by
 blueprints.
 The current approach is to set won't fix status for such bugs.
 But there are some cases we should clarify [0], [1].

 I vote to not track superseded bugs separately and keep them as won't
 fix but update the status back to confirmed in case of regression
 discovered. And if we want to backport an improvement tracked by a
 blueprint (just for an exceptional case) let's assign milestones for
 related bugs.

 If we want to change the triage rules, let's announce that so the people
 won't get confused.

 [0] https://bugs.launchpad.net/fuel/+bug/1383741
 [1] https://bugs.launchpad.net/fuel/+bug/1422856

 --
 Best regards,
 Bogdan Dobrelya,
 Skype #bogdando_at_yahoo.com http://bogdando_at_yahoo.com
 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




 --
 Andrew
 Mirantis
 Fuel community ambassador
 Ceph community

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




 --
 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] [UI] Sorting and filtering of node list

[Aleksey Kasatkin]

Oleg, The problem with IP addresses (for all networks but admin-pxe) is
that they are not available until deployment is started or
/clusters/(?Pcluster_id\d+)/orchestrator/deployment/defaults/ is called.
Nailgun just doesn't allocate them in advance. It was discussed some time
before (
https://blueprints.launchpad.net/fuel/+spec/assign-ips-on-nodes-addition )
but not planned yet. There is no problem with admin-pxe addresses though.

I agree that filtering is better be done in backend but it seems that it
will not be done recently. AFAIC, it will not be 6.1.
We didn't even decide what to do with API versioning yet.


Aleksey Kasatkin


On Thu, Feb 19, 2015 at 12:05 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:

 I think all these operations for nodes (grouping, sorting, filtering) can
 be done on the backend, but we can do it completely on the UI side and
 shouldn't wait for backend implementation. We can switch to it after it
 becomes available.

 2015-02-17 19:44 GMT+07:00 Sergey Vasilenko svasile...@mirantis.com:

 +1, sorting is should be...

 Paginating may be too, but not activated by default.


 /sv



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




 --
 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][client] Keeping Nailgun's log after running tests

[Aleksey Kasatkin]

+1 for this option. I use log while creating new tests sometimes.

Aleksey Kasatkin


On Mon, Jan 19, 2015 at 3:37 PM, Roman Prykhodchenko m...@romcheg.me wrote:

 Hi folks,

 at the moment run_test.sh script removes Nailgun's log file after running.
 The question is whether it is necessary to add an option for keeping it.


 - romcheg

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


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

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Aleksey Kasatkin]

+1, It will be very helpful to warn user.

Not all configurations (which can be set via UI/CLI w/o yaml editing) are
supported by network checker. It should be taken into account.

And we could recommend to run the check when user-defined configuration is
uploaded but warn that
given configuration might be not supported by network checker.

Agree, this should be done on backend.


Aleksey Kasatkin


On Thu, Jan 15, 2015 at 10:54 PM, Lukasz Oles lo...@mirantis.com wrote:

 Big +1, it would save me a lot of debugging time :)

 On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Folks,
 
  I want to discuss possibility to add network verification status field
 for
  environments. There are 2 reasons for this:
 
  1) One of the most frequent reasons of deployment failure is wrong
 network
  configuration. In the current UI network verification is completely
 optional
  and sometimes users are even unaware that this feature exists. We can
 warn
  the user before the start of deployment if network check failed of wasn't
  performed.
 
  2) Currently network verification status is partially tracked by status
 of
  the last network verification task. Sometimes its results become stale,
 and
  the UI removes the task. There are a few cases when the UI does this,
 like
  changing network settings, adding a new node, etc (you can grep
  removeFinishedNetworkTasks to see all the cases). This definitely
 should
  be done on backend.
 
  What is your opinion on this?
 
  --
  Vitaly Kramskikh,
  Software 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
 



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

Re: [openstack-dev] [Fuel] Logs format on UI (High/6.0)

[Aleksey Kasatkin]

+1 to show as is. We don't get benefits from parsing now (like filtering
by value of particular parameter, date/time intervals). It only adds
complexity.



Aleksey Kasatkin


On Mon, Dec 15, 2014 at 1:40 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:

 Also +1 here.
 In huge envs we already have problems with parsing performance. In long
 long term we need to think about other log management solution


  On 12 Dec 2014, at 23:17, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:
 
  +1 to stop parsing logs on UI and show them as is. I think it's more
  than enough for all users.
 
  On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov dpyz...@mirantis.com
 wrote:
  We have a high priority bug in 6.0:
  https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.
 
  Our openstack services use to send logs in strange format with extra
 copy of
  timestamp and loglevel:
  == ./neutron-metadata-agent.log ==
  2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349
 INFO
  neutron.common.config [-] Logging enabled!
 
  And we have a workaround for this. We hide extra timestamp and use
 second
  loglevel.
 
  In Juno some of services have updated oslo.logging and now send logs in
  simple format:
  == ./nova-api.log ==
  2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from
  /etc/nova/api-paste.ini
 
  In order to keep backward compatibility and deal with both formats we
 have a
  dirty workaround for our workaround:
  https://review.openstack.org/#/c/141450/
 
  As I see, our best choice here is to throw away all workarounds and show
  logs on UI as is. If service sends duplicated data - we should show
  duplicated data.
 
  Long term fix here is to update oslo.logging in all packages. We can do
 it
  in 6.1.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@mirantis.com







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

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

Re: [openstack-dev] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

[Aleksey Kasatkin]

+1

Aleksey Kasatkin


Hi everyone!

 I would like to propose Igor Kalnitsky as a core reviewer on the
 Fuel-web team. Igor has been working on openstack patching,
 nailgun, fuel upgrade and provided a lot of good reviews [1]. In
 addition he's also very active in IRC and mailing list.

 Can the other core team members please reply with your votes
 if you agree or disagree.

 Thanks!


 [1]

 http://stackalytics.com/?project_type=stackforgerelease=junomodule=fuel-web

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

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Aleksey Kasatkin]

Agree for Bogdan and Sergii

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

[openstack-dev] Networks Generating In Fuel

[Aleksey Kasatkin]

Hi!

Request to assign vips is here:
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L376

Most requests to assign other ips are here:
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/objects/node.py#L679-684

You can track assign_ips() and assign_vip() usage to see all calls to them.


Aleksey Kasatkin




 -- Forwarded message --
 From: zh...@certusnet.com.cn zh...@certusnet.com.cn
 Date: Fri, Aug 1, 2014 at 10:36 AM
 Subject: [openstack-dev] Networks Generating In Fuel
 To: openstack-dev openstack-dev@lists.openstack.org


 Hi! I'm now developing in Fuel and I want to add a virtual ip address to
 the NIC of br-ex with the same ip range of public address. So I want to
 know where IPs of node's such as br-ex, br-storage are generated. Can you
 tell me ?



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

[openstack-dev] [Fuel] API changes due to networking objects refactoring

[Aleksey Kasatkin]

Hi all,

We recently implemented
https://blueprints.launchpad.net/fuel/+spec/nailgun-rearrange-network-parameters(
https://review.openstack.org/#/c/81002/).
It helped to make networking-related objects in Nailgun, their
relationships and manipulation logic more consistent.

Please pay attention to changes in API for networking configuration which
were made. These changes are shown in samples in this blueprint.
Structure of networking parameters was changed for handlers:
/api/clusters/#/network_configuration/nova_network/
/api/clusters/#/network_configuration/neutron/.
Other stuff remains the same.


Regards,

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