[openstack-dev] [Performance] No meeting today

[Dina Belova]

Folks,

sadly I have to cancel today's Performance Team meeting. The next one will
be held next week on Tuesday (at usual time
<https://wiki.openstack.org/wiki/Meetings/Performance#Agenda_for_next_meeting>
).

Sorry for inconvenience.

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085
*Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Performance] No Performance Team meeting today

[Dina Belova]

Folks,

due to the internal training big part of Mirantis won't be able to attend
the meeting. Let's skip this for today.

Sorry for inconvenience.

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

OK, folks, new time chosen: 15:30 UTC (30 minutes earlier than usually, it
looks like most of the people are ok with it).

Starting with tomorrow (Tuesday, Aug 30th) we're running this time :)

Cheers,
Dina

On Mon, Aug 22, 2016 at 12:09 PM, Dina Belova  wrote:

> Ok, let's keep current (16:00 UTC) time slot for tomorrow meeting, until
> we'll find a better option.
>
> Cheers,
> Dina
>
> On Mon, Aug 22, 2016 at 9:05 AM, Augie Mena III  wrote:
>
>> Hi Dina/Adrien,
>>
>> Not a great slot here in Austin (that would be noon).  Would prefer a
>> 30-minute slot at 15:30 UTC or 18:00 UTC, but I realize it's hard to find
>> one to accommodate everyone.
>>
>> Thanks.
>>
>> Regards,
>> Augie
>>
>>
>>
>>
>>
>> From:Dina Belova 
>> To:lebre.adr...@free.fr, Joshua Harlow ,
>> Augie Mena III/Austin/IBM@IBMUS
>> Cc:OpenStack Development Mailing List <
>> openstack-dev@lists.openstack.org>, openstack-operators <
>> openstack-operat...@lists.openstack.org>
>> Date:08/22/2016 10:51 AM
>> Subject:Re: [Performance][Meeting time] Possible meeting time
>> change: feedback appreciated
>> --
>>
>>
>>
>> Adrien,
>>
>> this looks good to me. Let's see what Joshua and Augie will think about
>> it.
>>
>> Cheers,
>> Dina
>>
>> On Mon, Aug 22, 2016 at 7:44 AM, <*lebre.adr...@free.fr*
>> > wrote:
>> Hi Dina,
>>
>> 17:30 UTC means 19:30 in France (Summer time).
>> Considering that the meeting lasts in average 30/45 min, it would be
>> great if we could find a trade off a bit sooner. What's about 17:00 UTC ?
>>
>> Thanks,
>> Adrien
>>
>> - Mail original -
>> > De: "Dina Belova" <*dbel...@mirantis.com* >
>> > À: "OpenStack Development Mailing List" <
>> *openstack-dev@lists.openstack.org* >,
>> "openstack-operators"
>> > <*openstack-operat...@lists.openstack.org*
>> >
>> > Envoyé: Jeudi 18 Août 2016 21:35:48
>> > Objet: [Performance][Meeting time] Possible meeting time change:
>> feedback appreciated
>> >
>> >
>> > Hey, OpenStackers!
>> >
>> >
>> > recently I've got lots comments about current time our Performance
>> > Team meetings are held on. Right now we're having them 16:00 UTC on
>> > Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
>> > time slot is not that much comfortable for some of the US folks due
>> > to internal daily meetings.
>> >
>> >
>> > The question is: can we move our weekly meeting to 17:30 UTC (10:30
>> > PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
>> > collect more feedback.
>> >
>> >
>> > Please leave your comments.
>> >
>> >
>> > Cheers,
>> > Dina
>> >
>> >
>> > --
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Dina Belova Senior Software Engineer
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Mirantis, Inc.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 525 Almanor Avenue, 4th Floor
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Sunnyvale, CA 94085 Phone: 650-772-8418
>> > Email: *dbel...@mirantis.com* 
>> > *www.mirantis.com* <http://www.mirantis.com/>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> *Dina Belova*
>> *Senior Software Engineer*
>> Mirantis, Inc.
>> 525 Almanor Avenue, 4th Floor
>> Sunnyvale, CA 94085
>>
>> *Phone: 650-772-8418 <650-772-8418>Email: **dbel...@mirantis.com*
>> 
>> *www.mirantis.com* <http://www.mirantis.com/>
>> <https://www.mirantis.com/>
>>
>>
>>
>
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418>Email: dbel...@mirantis.com
> *
> www.mirantis.com
> <https://www.mirantis.com/>
>



-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Matt,

originally this started as an experiment - try to collect information about
OpenStack scalability and performance and publish it to the community - and
we started this experiment under Rally (OpenStack Benchmarking) umbrella,
that's having its documentation space under docs.openstack.org/developer/*
section. If this experiment will be met OK by OpenStack community (and more
specifically, by OpenStack documentation team), I believe eventually it can
be moved under more appropriate documentation space.

Cheers,
Dina

On Mon, Aug 22, 2016 at 4:59 AM, Matt Kassawara 
wrote:

> Why isn't this content in the openstack-manuals repository?
>
> On Sun, Aug 21, 2016 at 4:38 PM, Kaustubh Kelkar  > wrote:
>
>> I might have missed it entirely, but I wasn't able to find virtual
>> resources used by the instances. IMO, it'd be great if one could see
>> instance flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
>> ratios from host's perspective.
>>
>>
>> Thanks,
>> Kaustubh
>> --
>> *From:* Dina Belova 
>> *Sent:* Friday, August 19, 2016 12:37 PM
>> *To:* OpenStack Development Mailing List; openstack-operators
>> *Subject:* [Openstack-operators] [Performance][Documentation] Please
>> take a look on OpenStack perofmance-docs
>>
>> Folks,
>>
>> During previous weeks we merged lots of OpenStack performance-related
>> test plans and test results to the performance-docs
>> <http://docs.openstack.org/developer/performance-docs/> and your
>> feedback (as usually) is very appreciated. I hope you can find something
>> interesting for you here and share your opinion on what's going on
>> regarding our performance researches.
>>
>>
>> Thanks in advance!
>>
>> Cheers,
>> Dina
>>
>> --
>> *Dina Belova*
>> *Senior Software Engineer*
>> Mirantis, Inc.
>> 525 Almanor Avenue, 4th Floor
>> Sunnyvale, CA 94085
>>
>> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
>> *
>> www.mirantis.com
>> <https://www.mirantis.com/>
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>


-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Kaustubh,

thanks for the comment. Usually if testing scenario require VM booting, its
flavor is set in the Rally scenario configuration (e.g. here
<http://docs.openstack.org/developer/performance-docs/test_plans/control_plane/plan.html#example-of-rally-scenario-configuration>
or
here
<http://docs.openstack.org/developer/performance-docs/test_results/reliability/index.html#reboot-random-controller>),
but I will check where this information is missed right now. AFAIK default
OpenStack flavors were used for testing purposes (tiny, small, medium) with
no customizations. As for overcommit ratios, this information needs to be
added, thank you for noticing.

Cheers,
Dina

On Sun, Aug 21, 2016 at 3:38 PM, Kaustubh Kelkar 
wrote:

> I might have missed it entirely, but I wasn't able to find virtual
> resources used by the instances. IMO, it'd be great if one could see
> instance flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
> ratios from host's perspective.
>
>
> Thanks,
> Kaustubh
> --
> *From:* Dina Belova 
> *Sent:* Friday, August 19, 2016 12:37 PM
> *To:* OpenStack Development Mailing List; openstack-operators
> *Subject:* [Openstack-operators] [Performance][Documentation] Please take
> a look on OpenStack perofmance-docs
>
> Folks,
>
> During previous weeks we merged lots of OpenStack performance-related test
> plans and test results to the performance-docs
> <http://docs.openstack.org/developer/performance-docs/> and your feedback
> (as usually) is very appreciated. I hope you can find something interesting
> for you here and share your opinion on what's going on regarding our
> performance researches.
>
>
> Thanks in advance!
>
> Cheers,
> Dina
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
> *
> www.mirantis.com
> <https://www.mirantis.com/>
>



-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Ok, let's keep current (16:00 UTC) time slot for tomorrow meeting, until
we'll find a better option.

Cheers,
Dina

On Mon, Aug 22, 2016 at 9:05 AM, Augie Mena III  wrote:

> Hi Dina/Adrien,
>
> Not a great slot here in Austin (that would be noon).  Would prefer a
> 30-minute slot at 15:30 UTC or 18:00 UTC, but I realize it's hard to find
> one to accommodate everyone.
>
> Thanks.
>
> Regards,
> Augie
>
>
>
>
>
> From:Dina Belova 
> To:lebre.adr...@free.fr, Joshua Harlow ,
> Augie Mena III/Austin/IBM@IBMUS
> Cc:OpenStack Development Mailing List  openstack.org>, openstack-operators  openstack.org>
> Date:08/22/2016 10:51 AM
> Subject:Re: [Performance][Meeting time] Possible meeting time
> change: feedback appreciated
> --
>
>
>
> Adrien,
>
> this looks good to me. Let's see what Joshua and Augie will think about it.
>
> Cheers,
> Dina
>
> On Mon, Aug 22, 2016 at 7:44 AM, <*lebre.adr...@free.fr*
> > wrote:
> Hi Dina,
>
> 17:30 UTC means 19:30 in France (Summer time).
> Considering that the meeting lasts in average 30/45 min, it would be great
> if we could find a trade off a bit sooner. What's about 17:00 UTC ?
>
> Thanks,
> Adrien
>
> - Mail original -
> > De: "Dina Belova" <*dbel...@mirantis.com* >
> > À: "OpenStack Development Mailing List" <
> *openstack-dev@lists.openstack.org* >,
> "openstack-operators"
> > <*openstack-operat...@lists.openstack.org*
> >
> > Envoyé: Jeudi 18 Août 2016 21:35:48
> > Objet: [Performance][Meeting time] Possible meeting time change:
> feedback appreciated
> >
> >
> > Hey, OpenStackers!
> >
> >
> > recently I've got lots comments about current time our Performance
> > Team meetings are held on. Right now we're having them 16:00 UTC on
> > Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
> > time slot is not that much comfortable for some of the US folks due
> > to internal daily meetings.
> >
> >
> > The question is: can we move our weekly meeting to 17:30 UTC (10:30
> > PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
> > collect more feedback.
> >
> >
> > Please leave your comments.
> >
> >
> > Cheers,
> > Dina
> >
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dina Belova Senior Software Engineer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Mirantis, Inc.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 525 Almanor Avenue, 4th Floor
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sunnyvale, CA 94085 Phone: 650-772-8418
> > Email: *dbel...@mirantis.com* 
> > *www.mirantis.com* <http://www.mirantis.com/>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418>Email: **dbel...@mirantis.com*
> 
> *www.mirantis.com* <http://www.mirantis.com/>
> <https://www.mirantis.com/>
>
>
>


-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Adrien,

this looks good to me. Let's see what Joshua and Augie will think about it.

Cheers,
Dina

On Mon, Aug 22, 2016 at 7:44 AM,  wrote:

> Hi Dina,
>
> 17:30 UTC means 19:30 in France (Summer time).
> Considering that the meeting lasts in average 30/45 min, it would be great
> if we could find a trade off a bit sooner. What's about 17:00 UTC ?
>
> Thanks,
> Adrien
>
> - Mail original -
> > De: "Dina Belova" 
> > À: "OpenStack Development Mailing List"  openstack.org>, "openstack-operators"
> > 
> > Envoyé: Jeudi 18 Août 2016 21:35:48
> > Objet: [Performance][Meeting time] Possible meeting time change:
> feedback appreciated
> >
> >
> > Hey, OpenStackers!
> >
> >
> > recently I've got lots comments about current time our Performance
> > Team meetings are held on. Right now we're having them 16:00 UTC on
> > Tuesdays (9:00 PST) (#openstack-performance IRC channel) and this
> > time slot is not that much comfortable for some of the US folks due
> > to internal daily meetings.
> >
> >
> > The question is: can we move our weekly meeting to 17:30 UTC (10:30
> > PST)? It's late a bit for folks from Moscow (20:30), so I'd like to
> > collect more feedback.
> >
> >
> > Please leave your comments.
> >
> >
> > Cheers,
> > Dina
> >
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dina Belova Senior Software Engineer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Mirantis, Inc.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 525 Almanor Avenue, 4th Floor
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sunnyvale, CA 94085 Phone: 650-772-8418
> > Email: dbel...@mirantis.com
> > www.mirantis.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>



-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Folks,

During previous weeks we merged lots of OpenStack performance-related test
plans and test results to the performance-docs
<http://docs.openstack.org/developer/performance-docs/> and your feedback
(as usually) is very appreciated. I hope you can find something interesting
for you here and share your opinion on what's going on regarding our
performance researches.

Thanks in advance!

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Hey, OpenStackers!

recently I've got lots comments about current time our Performance Team
meetings are held on. Right now we're having them 16:00 UTC on Tuesdays
(9:00 PST) (#openstack-performance IRC channel) and this time slot is not
that much comfortable for some of the US folks due to internal daily
meetings.

The question is: can we move our weekly meeting to 17:30 UTC (10:30 PST)?
It's late a bit for folks from Moscow (20:30), so I'd like to collect more
feedback.

Please leave your comments.

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Performance] Team meeting canceled for today. Next meeting: July 19th

[Dina Belova]

Folks,

accidentally I have no opportunity to chair today meeting due to feeling
sick, and as discussed  on last Tuesday there is no chance I'll be
available on July 12th. Let's assume our next meeting will be on Tuesday,
July 19th at 16:00 UTC.

Sorry for inconvenience!

Cheers,
Dina
__
OpenStack Development Mailing List (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] [Performance] No IRC meeting today

[Dina Belova]

Folks,

today we should have the Performance working group IRC meeting, but I have
to announce that I won't be able to attend it today as well as several more
folks. Therefore let's decline this event for today and make it happen next
week due to the usual schedule.

I'm really sorry for the inconvenience.

Cheers,
Dina
__
OpenStack Development Mailing List (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] [Performance] IRC meetings starting today after a break

[Dina Belova]

Folks,

just a reminder - today we'll start our periodical Performance Team
meetings after a post-summit break we had. *#openstack-performance channel
and 16:00 UTC* as usually :)

See you!

-- Dina
__
OpenStack Development Mailing 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] [Neutron] L3 HA testing on scale

[Dina Belova]

Folks,

change https://review.openstack.org/#/c/310419/ proposed to
performance-docs. Thanks Ann, soon it'll appear on
http://docs.openstack.org/developer/performance-docs/#

Cheers,
Dina

On Wed, Apr 20, 2016 at 10:56 PM, Edgar Magana 
wrote:

> Indeed it will be a terrific contribution.
>
> Edgar
>
>
> On Apr 20, 2016, at 4:10 AM, Dina Belova  wrote:
>
> Folks,
>
> I think Ann's report is super cool and 100% worth publishing on OpenStack
> performance-docs <http://docs.openstack.org/developer/performance-docs/#>.
> This is really good information to share community-wide.
>
> Ann, please think if you would like to contribute to performance
> documentation.
>
> Cheers,
> Dina
>
> On Wed, Apr 20, 2016 at 12:34 PM, Anna Kamyshnikova <
> akamyshnik...@mirantis.com> wrote:
>
>> Unfortunately, I won't attend summit in Austin, that is why I decided to
>> present these results in the mailing list instead.
>>
>> On Tue, Apr 19, 2016 at 7:29 PM, Edgar Magana 
>> wrote:
>>
>>> Is there any session presenting these results during the Summit? It will
>>> be awesome to have a session on this. I could extend the invite to the Ops
>>> Meet-up. We have a section on lighting talks where the team will be very
>>> intesreted in learning from your testing.
>>>
>>> Edgar
>>>
>>> From: Anna Kamyshnikova 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> Date: Tuesday, April 19, 2016 at 5:30 AM
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Neutron] L3 HA testing on scale
>>>
>>> >I would definitely like to see how these results are effected by
>>> >https://review.openstack.org/#/c/305774/ but understandably 49
>>> >physical nodes are hard to come by.
>>>
>>> Yes, I'm planning to check how situation will change with all recent
>>> fixes, but I will be able to do this in May or later.
>>>
>>> >About testing on scale it’s not so problematic because of the Cloud For
>>> All project.
>>> >Here [1] you can request for a multi node cluster which you can use to
>>> >perform tests. Exact requirements are specified on that website.
>>>
>>> [1] http://osic.org
>>>
>>> Thanks for pointing this!
>>>
>>> >It's a great report, thanks for sharing that! Do you plan to run similar
>>> >scale tests on other scenarios e.g. dvr?
>>>
>>> Thanks! I have testing L3 HA + DVR in plans.
>>>
>>> P. S.
>>>
>>> I've updated environment description in report with some details.
>>>
>>> On Tue, Apr 19, 2016 at 12:52 PM, Rossella Sblendido <
>>> rsblend...@suse.com> wrote:
>>>
>>>>
>>>>
>>>> On 04/18/2016 04:15 PM, Anna Kamyshnikova wrote:
>>>> > Hi guys!
>>>> >
>>>> > As a developer I use Devstack or multinode OpenStack installation (4-5
>>>> > nodes) for work, but these are "abstract" environments, where you are
>>>> > not able to perform some scenarios as your machine is not powerful
>>>> > enough. But it is really important to understand the issues that real
>>>> > deployments have.
>>>> >
>>>> > Recently I've performed testing of L3 HA on the scale environment 49
>>>> > nodes (3 controllers, 46 computes) Fuel 8.0. On this environment I ran
>>>> > shaker and rally tests and also performed some
>>>> > manual destructive scenarios. I think that this is very important to
>>>> > share these results. Ideally, I think that we should collect
>>>> statistics
>>>> > for different configurations each release to compare and check it to
>>>> > make sure that we are heading the right way.
>>>> >
>>>> > The results of shaker and rally tests [1]. I put detailed report in
>>>> > google doc [2]. I would appreciate all comments on these results.
>>>>
>>>> It's a great report, thanks for sharing that! Do you plan to run similar
>>>> scale tests on other scenarios e.g. dvr?
>>>>
>>>> Rossella
>>>>
>>>> >
>>>> > [1] - http://akamyshnikova.github.io/neutron-benchmark-results/
>>>> > [2]
>>>> > -
&g

[openstack-dev] [Performance] Austin Performance Team working group session - please comment

[Dina Belova]

Folks,

we're going to have Performance Working Group session during the upcoming
summit - here is the event description
.
Our team was kicked off during Mitaka Summit, so that was our first cycle
:) Please attend the session to learn what we have done and what plans do
we have for Newton.

*Etherpad link:* https://etherpad.openstack.org/p/newton-performance-team

We'll be using this ^^ etherpad during the session, feel free to comment,
add your suggestions of what do you think will be important to be tested
during Newton and what issues seem to be vital to investigate and fix.

See you in Austin :)

Cheers,
Dina
__
OpenStack Development Mailing 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] [Neutron] L3 HA testing on scale

[Dina Belova]

Folks,

I think Ann's report is super cool and 100% worth publishing on OpenStack
performance-docs <http://docs.openstack.org/developer/performance-docs/#>.
This is really good information to share community-wide.

Ann, please think if you would like to contribute to performance
documentation.

Cheers,
Dina

On Wed, Apr 20, 2016 at 12:34 PM, Anna Kamyshnikova <
akamyshnik...@mirantis.com> wrote:

> Unfortunately, I won't attend summit in Austin, that is why I decided to
> present these results in the mailing list instead.
>
> On Tue, Apr 19, 2016 at 7:29 PM, Edgar Magana 
> wrote:
>
>> Is there any session presenting these results during the Summit? It will
>> be awesome to have a session on this. I could extend the invite to the Ops
>> Meet-up. We have a section on lighting talks where the team will be very
>> intesreted in learning from your testing.
>>
>> Edgar
>>
>> From: Anna Kamyshnikova 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, April 19, 2016 at 5:30 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron] L3 HA testing on scale
>>
>> >I would definitely like to see how these results are effected by
>> >https://review.openstack.org/#/c/305774/ but understandably 49
>> >physical nodes are hard to come by.
>>
>> Yes, I'm planning to check how situation will change with all recent
>> fixes, but I will be able to do this in May or later.
>>
>> >About testing on scale it’s not so problematic because of the Cloud For
>> All project.
>> >Here [1] you can request for a multi node cluster which you can use to
>> >perform tests. Exact requirements are specified on that website.
>>
>> [1] http://osic.org
>>
>> Thanks for pointing this!
>>
>> >It's a great report, thanks for sharing that! Do you plan to run similar
>> >scale tests on other scenarios e.g. dvr?
>>
>> Thanks! I have testing L3 HA + DVR in plans.
>>
>> P. S.
>>
>> I've updated environment description in report with some details.
>>
>> On Tue, Apr 19, 2016 at 12:52 PM, Rossella Sblendido > > wrote:
>>
>>>
>>>
>>> On 04/18/2016 04:15 PM, Anna Kamyshnikova wrote:
>>> > Hi guys!
>>> >
>>> > As a developer I use Devstack or multinode OpenStack installation (4-5
>>> > nodes) for work, but these are "abstract" environments, where you are
>>> > not able to perform some scenarios as your machine is not powerful
>>> > enough. But it is really important to understand the issues that real
>>> > deployments have.
>>> >
>>> > Recently I've performed testing of L3 HA on the scale environment 49
>>> > nodes (3 controllers, 46 computes) Fuel 8.0. On this environment I ran
>>> > shaker and rally tests and also performed some
>>> > manual destructive scenarios. I think that this is very important to
>>> > share these results. Ideally, I think that we should collect statistics
>>> > for different configurations each release to compare and check it to
>>> > make sure that we are heading the right way.
>>> >
>>> > The results of shaker and rally tests [1]. I put detailed report in
>>> > google doc [2]. I would appreciate all comments on these results.
>>>
>>> It's a great report, thanks for sharing that! Do you plan to run similar
>>> scale tests on other scenarios e.g. dvr?
>>>
>>> Rossella
>>>
>>> >
>>> > [1] - http://akamyshnikova.github.io/neutron-benchmark-results/
>>> > [2]
>>> > -
>>> https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing
>>> >
>>> > Regards,
>>> > Ann Kamyshnikova
>>> > 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 Li

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

[Dina Belova]

Thank you Morgan for quick fixes proposed!

On Tue, Apr 12, 2016 at 6:19 PM, Morgan Fainberg 
wrote:

> Sorry Missed the copy/paste of links:
>
> https://bugs.launchpad.net/keystone/+bug/1567403 [0]
> https://bugs.launchpad.net/keystone/+bug/1567413 [1]
>
> [0]
> https://review.openstack.org/#/q/I4857cfe1e62d54c3c89a0206ffc895c4cf681ce5,n,z
> [1] https://review.openstack.org/#/c/304688/
>
> --Morgan
>
> On Tue, Apr 12, 2016 at 8:16 AM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>> Fixes have been proposed for both of these bugs.
>>
>> Cheers,
>> --Morgan
>>
>> On Tue, Apr 12, 2016 at 12:38 AM, Dina Belova 
>> wrote:
>>
>>> Matt,
>>>
>>> Thanks for sharing the information about your benchmark. Indeed we need
>>> to follow up on this topic (I'll attend the summit). Let's try to collect
>>> as much information as possible prior Austin to have more facts to operate.
>>> I'll try to figure out why local context cache did not work at least on my
>>> environment, and, due to the results, most probably it did not act as
>>> supposed during your benchmarking as well.
>>>
>>> Cheers,
>>> Dina
>>>
>>> On Mon, Apr 11, 2016 at 10:57 PM, Matt Fischer 
>>> wrote:
>>>
>>>> On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova 
>>>> wrote:
>>>>
>>>>> Hey, openstackers!
>>>>>
>>>>> Recently I was trying to profile Keystone (OpenStack Liberty vs
>>>>> Mitaka) using this set of changes
>>>>> <https://review.openstack.org/#/q/topic:osprofiler-support-in-keystone+status:open>
>>>>>  (that's
>>>>> currently on review - some final steps are required there to finish the
>>>>> work) and OSprofiler.
>>>>>
>>>>> Some preliminary results (all in one OpenStack node) can be found here
>>>>> <http://docs.openstack.org/developer/performance-docs/test_results/keystone/all-in-one/index.html>
>>>>>  (raw
>>>>> OSprofiler reports are not yet merged to some place and can be found
>>>>> here <https://review.openstack.org/#/c/299514/>). The full plan
>>>>> <http://docs.openstack.org/developer/performance-docs/test_plans/keystone/plan.html#keystone-performance>
>>>>>  of
>>>>> what's going to be tested  can be found in the docs as well. In short I
>>>>> wanted to take a look how does Keystone changed its DB/Cache usage from
>>>>> Liberty to Mitaka, keeping in mind that there were several changes
>>>>> introduced:
>>>>>
>>>>>- federation support was added (and made DB scheme a bit more
>>>>>complex)
>>>>>- Keystone moved to oslo.cache usage
>>>>>- local context cache was introduced during Mitaka
>>>>>
>>>>> First of all - *good job on making Keystone less DB-extensive in case
>>>>> of cache turned on*! If Keystone caching is turned on, number of DB
>>>>> queries done to Keystone DB in Mitaka is averagely twice less than in
>>>>> Liberty, comparing the same requests and topologies. Thanks Keystone
>>>>> community to make it happen :)
>>>>>
>>>>> Although, I faced *two strange issues* during my experiments, and I'm
>>>>> kindly asking you, folks, to help me here:
>>>>>
>>>>>- I've created #1567403
>>>>><https://bugs.launchpad.net/keystone/+bug/1567403> bug to share
>>>>>information - when I turned caching on, local context cache should 
>>>>> cache
>>>>>identical per API requests function calls not to ping Memcache too 
>>>>> often.
>>>>>Although I faced such calls, Keystone still used Memcache to gather 
>>>>> this
>>>>>information. May someone take a look on this and help me figure out 
>>>>> what am
>>>>>I observing? At the first sight local context cache should work ok, 
>>>>> but for
>>>>>some reason I do not see it's being used.
>>>>>- One more filed bug - #1567413
>>>>><https://bugs.launchpad.net/keystone/+bug/1567413> - is about a
>>>>>bit opposite situation :) When I turned cache off explicitly in the
>>>>>keystone.conf file, I still observed some of the values being fetc

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

[Dina Belova]

Matt,

Thanks for sharing the information about your benchmark. Indeed we need to
follow up on this topic (I'll attend the summit). Let's try to collect as
much information as possible prior Austin to have more facts to operate.
I'll try to figure out why local context cache did not work at least on my
environment, and, due to the results, most probably it did not act as
supposed during your benchmarking as well.

Cheers,
Dina

On Mon, Apr 11, 2016 at 10:57 PM, Matt Fischer  wrote:

> On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova  wrote:
>
>> Hey, openstackers!
>>
>> Recently I was trying to profile Keystone (OpenStack Liberty vs Mitaka)
>> using this set of changes
>> <https://review.openstack.org/#/q/topic:osprofiler-support-in-keystone+status:open>
>>  (that's
>> currently on review - some final steps are required there to finish the
>> work) and OSprofiler.
>>
>> Some preliminary results (all in one OpenStack node) can be found here
>> <http://docs.openstack.org/developer/performance-docs/test_results/keystone/all-in-one/index.html>
>>  (raw
>> OSprofiler reports are not yet merged to some place and can be found here
>> <https://review.openstack.org/#/c/299514/>). The full plan
>> <http://docs.openstack.org/developer/performance-docs/test_plans/keystone/plan.html#keystone-performance>
>>  of
>> what's going to be tested  can be found in the docs as well. In short I
>> wanted to take a look how does Keystone changed its DB/Cache usage from
>> Liberty to Mitaka, keeping in mind that there were several changes
>> introduced:
>>
>>- federation support was added (and made DB scheme a bit more complex)
>>- Keystone moved to oslo.cache usage
>>- local context cache was introduced during Mitaka
>>
>> First of all - *good job on making Keystone less DB-extensive in case of
>> cache turned on*! If Keystone caching is turned on, number of DB queries
>> done to Keystone DB in Mitaka is averagely twice less than in Liberty,
>> comparing the same requests and topologies. Thanks Keystone community to
>> make it happen :)
>>
>> Although, I faced *two strange issues* during my experiments, and I'm
>> kindly asking you, folks, to help me here:
>>
>>- I've created #1567403
>><https://bugs.launchpad.net/keystone/+bug/1567403> bug to share
>>information - when I turned caching on, local context cache should cache
>>identical per API requests function calls not to ping Memcache too often.
>>Although I faced such calls, Keystone still used Memcache to gather this
>>information. May someone take a look on this and help me figure out what 
>> am
>>I observing? At the first sight local context cache should work ok, but 
>> for
>>some reason I do not see it's being used.
>>- One more filed bug - #1567413
>><https://bugs.launchpad.net/keystone/+bug/1567413> - is about a bit
>>opposite situation :) When I turned cache off explicitly in the
>>keystone.conf file, I still observed some of the values being fetched from
>>Memcache... Your help is very appreciated!
>>
>> Thanks in advance and sorry for a long email :)
>>
>> Cheers,
>> Dina
>>
>>
> Dina,
>
> Thanks for starting this conversation. I had some weird perf results
> comparing L to an RC release of Mitaka, but I was holding them until
> someone else confirmed what I saw. I'm testing token creation and
> validation. From what I saw, token validation slowed down in Mitaka. After
> doing my benchmark runs, the traffic to memcache was 8x in Mitaka from what
> it was in Liberty. That implies more caching but 8x is a lot and even
> memcache references are not free.
>
> I know some of the Keystone folks are looking into this so it will be good
> to follow-up on it. Maybe we could talk about this at the summit?
>
>
>
> __
> OpenStack Development Mailing 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,

Dina Belova

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

[openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

[Dina Belova]

Hey, openstackers!

Recently I was trying to profile Keystone (OpenStack Liberty vs Mitaka)
using this set of changes

(that's
currently on review - some final steps are required there to finish the
work) and OSprofiler.

Some preliminary results (all in one OpenStack node) can be found here

(raw
OSprofiler reports are not yet merged to some place and can be found here
). The full plan

of
what's going to be tested  can be found in the docs as well. In short I
wanted to take a look how does Keystone changed its DB/Cache usage from
Liberty to Mitaka, keeping in mind that there were several changes
introduced:

   - federation support was added (and made DB scheme a bit more complex)
   - Keystone moved to oslo.cache usage
   - local context cache was introduced during Mitaka

First of all - *good job on making Keystone less DB-extensive in case of
cache turned on*! If Keystone caching is turned on, number of DB queries
done to Keystone DB in Mitaka is averagely twice less than in Liberty,
comparing the same requests and topologies. Thanks Keystone community to
make it happen :)

Although, I faced *two strange issues* during my experiments, and I'm
kindly asking you, folks, to help me here:

   - I've created #1567403
    bug to share
   information - when I turned caching on, local context cache should cache
   identical per API requests function calls not to ping Memcache too often.
   Although I faced such calls, Keystone still used Memcache to gather this
   information. May someone take a look on this and help me figure out what am
   I observing? At the first sight local context cache should work ok, but for
   some reason I do not see it's being used.
   - One more filed bug - #1567413
    - is about a bit
   opposite situation :) When I turned cache off explicitly in the
   keystone.conf file, I still observed some of the values being fetched from
   Memcache... Your help is very appreciated!

Thanks in advance and sorry for a long email :)

Cheers,
Dina
__
OpenStack Development Mailing 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] [Performance] Let's have next meeting on March 15th

[Dina Belova]

Just a reminder: we won't have a meeting today!

Happy Women's Day!

Cheers,
Dina

On Tue, Mar 1, 2016 at 7:54 PM, Dina Belova  wrote:

> Folks,
>
> due to the schedule our next meeting
> <https://wiki.openstack.org/wiki/Meetings/Performance> is going to happen
> on March 8th, that's International Women's Day (non-working day in Russia,
> for instance). So let's have our next meeting scheduled for March 15th.
>
> Cheers,
> Dina
>



-- 

Best regards,

Dina Belova

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

[openstack-dev] [Performance] Let's have next meeting on March 15th

[Dina Belova]

Folks,

due to the schedule our next meeting
 is going to happen
on March 8th, that's International Women's Day (non-working day in Russia,
for instance). So let's have our next meeting scheduled for March 15th.

Cheers,
Dina
__
OpenStack Development Mailing 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] [Performance][Holidays] IRC meeting schedule

[Dina Belova]

Ok, so let's assume everyone is ok with the proposed schedule :)

*Dear Performance Team folks, do not have more meetings this year and have
the first meeting on Jan 12, 2016
<https://wiki.openstack.org/wiki/Meetings/Performance#Agenda_for_next_meeting>.*

Thanks everyone for short for our team, but productive year! See you in
2016 :)

Cheers,
Dina

On Wed, Dec 16, 2015 at 11:18 PM, Dina Belova  wrote:

> Folks,
>
> we had an IRC meeting yesterday, and holidays schedule was one of the
> topics covered. Although, the final decision was not made, so let's
> finalise everything here :)
>
> There are few options for 2015 and 2016 now:
> 1) Let's *do not have more meetings this year or let's meet last time on
> Dec 22nd*
> 3) Should we have first 2016 meeting on *Jan 5th or Jan 12*
>
> Due to the opinions proposed on the meeting, *I'll suggest to finish
> meetings for this year and have the first meeting on Jan 12, 2016* (due
> to the fact that Christmas holidays almost started already, and in Russia
> there will be no X-mas holidays, but we'll have about a week after NY).
>
> Any pros / cons?
>
> Cheers,
> Dina
>



-- 

Best regards,

Dina Belova

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

[openstack-dev] [Performance][Holidays] IRC meeting schedule

[Dina Belova]

Folks,

we had an IRC meeting yesterday, and holidays schedule was one of the
topics covered. Although, the final decision was not made, so let's
finalise everything here :)

There are few options for 2015 and 2016 now:
1) Let's *do not have more meetings this year or let's meet last time on
Dec 22nd*
3) Should we have first 2016 meeting on *Jan 5th or Jan 12*

Due to the opinions proposed on the meeting, *I'll suggest to finish
meetings for this year and have the first meeting on Jan 12, 2016* (due to
the fact that Christmas holidays almost started already, and in Russia
there will be no X-mas holidays, but we'll have about a week after NY).

Any pros / cons?

Cheers,
Dina
__
OpenStack Development Mailing 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] [Openstack-operators] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Dina Belova]

Sylvain,

in fact we just used the same practice LDT team is having - they do have
their meeting on openstack-operators channel, for instance. We were
choosing the time slot available for different people from different
company, due to the Doodle vote it was chosen 15:00 UTC Tuesdays (and as
you can see it's pretty busy slot on the official channels). And although
we're moving the meeting +1 hour, it's still busy because it's comfortable
time for almost all US and European folks at the same time. Therefore we're
just continuing to use Large Deployment Team's practice, as its sub team in
fact.

Although, if there will be a wish from contributors to move to some
official channel, we can do that as well.

You should also provide a YAML file here
> http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/


Thanks for the link ^^, will do.

Cheers,
Dina

On Mon, Dec 7, 2015 at 2:19 PM, Sylvain Bauza  wrote:

>
>
> Le 07/12/2015 11:27, Dina Belova a écrit :
>
> Ok, so due to the responses I propose to finalise this decision and move
> the meeting to *16:00 UTC (Tuesdays)*.
> So tomorrow please join me *on #openstack-performance at 16:00 UTC.*
>
>
> Why are you not using the meeting channels?
> You should also provide a YAML file here
> http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/
>
> -Sylvain
>
> Cheers, Dina
>
> P.S.
> Ryan, I'm suggesting you to come as usually at 15:00, I'll be online -
> let's prepare possible questions you're interested in to be covered during
> the meeting time. I'll be happy to make everything possible for you to
> participate at least in this way..
>
> On Sat, Dec 5, 2015 at 2:12 AM, Clint Byrum  wrote:
>
>> Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
>> > Dear performance folks,
>> >
>> > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
>> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>)
>> to
>> > 16:00 UTC (also Tuesdays
>> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>)
>> to
>> > make them more comfortable for US guys.
>> >
>> > Please leave your +1 / -1 here in the email thread.
>> >
>> > Btw +1 from me :)
>>
>> +1, this makes it actually possible for me to participate. :)
>>
>> ______
>> OpenStack Development Mailing 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,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
> ___
> OpenStack-operators mailing 
> listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>


-- 

Best regards,

Dina Belova

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

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Dina Belova]

Ok, so due to the responses I propose to finalise this decision and move
the meeting to *16:00 UTC (Tuesdays)*.
So tomorrow please join me *on #openstack-performance at 16:00 UTC.*

Cheers, Dina

P.S.
Ryan, I'm suggesting you to come as usually at 15:00, I'll be online -
let's prepare possible questions you're interested in to be covered during
the meeting time. I'll be happy to make everything possible for you to
participate at least in this way..

On Sat, Dec 5, 2015 at 2:12 AM, Clint Byrum  wrote:

> Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> > Dear performance folks,
> >
> > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> > 16:00 UTC (also Tuesdays
> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> > make them more comfortable for US guys.
> >
> > Please leave your +1 / -1 here in the email thread.
> >
> > Btw +1 from me :)
>
> +1, this makes it actually possible for me to participate. :)
>
> __
> OpenStack Development Mailing 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,

Dina Belova

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

[openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Dina Belova]

Dear performance folks,

There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
) to
16:00 UTC (also Tuesdays
) to
make them more comfortable for US guys.

Please leave your +1 / -1 here in the email thread.

Btw +1 from me :)

Cheers,
Dina
__
OpenStack Development Mailing 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] [Performance] Filling performance team working items list and taking part in their resolving

[Dina Belova]

Matt,

I guess it's good solution. Thanks for doing that!

Cheers,
Dina

On Mon, Nov 30, 2015 at 6:30 PM, Matt Riedemann 
wrote:

>
>
> On 11/27/2015 3:54 AM, Dina Belova wrote:
>
>> Hey OpenStack devs and operators!
>>
>> Folks, I would like to share list of working items Performance Team is
>> currently having in the backlog -
>> https://etherpad.openstack.org/p/perf-zoom-zoom [Work Items to grab]
>> section. I'm really encouraging you to fill it with concrete pieces of
>> work you think will be useful and take part in the
>> development/investigation by assigning some of them to yourself and
>> working on them :)
>>
>> Cheers,
>> Dina
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> One of the work items was to enable the nova metadata service in a large
> ops job. There are two voting large ops jobs in nova, one runs with
> nova-network and the other runs with neutron. Besides those differences,
> I'm not sure if there is any other difference in the jobs. So I guess we'd
> just need to pick which one runs the nova-api-metadata service rather than
> using config drive. The only other job I know of that runs that is the
> postgres job and that runs nova-network, so I'd say we turn on n-api-meta
> in the neutron large ops job.
>
> Are there any issues with that?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing 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,

Dina Belova

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

[openstack-dev] [Performance] Filling performance team working items list and taking part in their resolving

[Dina Belova]

Hey OpenStack devs and operators!

Folks, I would like to share list of working items Performance Team is
currently having in the backlog -
https://etherpad.openstack.org/p/perf-zoom-zoom [Work Items to grab]
section. I'm really encouraging you to fill it with concrete pieces of work
you think will be useful and take part in the development/investigation by
assigning some of them to yourself and working on them :)

Cheers,
Dina
__
OpenStack Development Mailing 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] [Openstack-operators] Mirantis Fuel Multi-Region

[Dina Belova]

+ openstack-dev mailing list to bring more Fuel audience.

On Tue, Nov 17, 2015 at 12:44 PM, Federico Michele Facca <
federico.fa...@create-net.org> wrote:

> Hi,
> as said, you need to do manual changes to your deployed nodes.
> then you will have to:
> - synch your galera cluster across the two dc
> - configure properly the load balancers
> - configure the memcached configuration
> - register the services of the second region on the new shared keystone
>
> Br,
> Federico
>
> PS: I think that you can change the region name in the YAML file using
> fuel cli (
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#cli-usage),
> but that won't help much honestly, being the trivial of the steps above.
>
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.fa...@create-net.org
> T @chicco785
> W  www.create-net.org
>
> On Tue, Nov 17, 2015 at 10:29 AM, Eren Türkay  wrote:
>
>> On 17-11-2015 10:40, Federico Michele Facca wrote:
>> > Hi Eren,
>>
>> Hello Federico
>>
>> > afaik, with the new plugin architecture, in fuel 7/8 it should be easy
>> to
>> > create a plugin for achieve your goal.
>> > in case of manual job, depending on your cloud architecture there are
>> different
>> > options, the main ones are:
>> > - you keep a single keystone in a datacenter and register the new region
>> > services in there.
>>
>> Yes, that's what I am aiming for. I need a single keystone and multiple
>> endpoints. However, as far as I understand, multi-dc isn't supported yet
>> on
>> Mirantis (nor the region name change). Do you know the actual/example
>> implementation for multi-dc with new plugin architecture? Here are my
>> findings
>> regarding to the issue. It seems deploying multi-site with fuel is really
>> hard
>> and not supported.
>>
>> https://answers.launchpad.net/fuel/+question/267127
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076298.html
>>
>>
>> --
>> Eren Türkay, System Administrator
>> https://skyatlas.com/ | +90 850 885 0357
>>
>> Yildiz Teknik Universitesi Davutpasa Kampusu
>> Teknopark Bolgesi, D2 Blok No:107
>> Esenler, Istanbul Pk.34220
>>
>>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

Best regards,

Dina Belova

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

[openstack-dev] [Performance] Please add your discussion items to the next meeting agenda

[Dina Belova]

Folks,

Last time we had Performance team meeting, we ha did a bit messy due to the
lack of time spent by team members to fill the meeting agenda. Let's fix it
this time! :)

Please add your items to the agenda
https://wiki.openstack.org/wiki/Meetings/Performance#Agenda_for_next_meeting
(I intentionally keep it empty right now to discuss points interesting to
*you*) and let's go through them next time :)


Cheers,
Dina
__
OpenStack Development Mailing 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] [Openstack-operators] Performance Team summit session results

[Dina Belova]

Mark,

yes, sorry for not mentioning it here. it's 3PM - 4PM UTC time zone.

Cheers,
Dina

On Tue, Nov 10, 2015 at 2:51 AM, Mark Wagner  wrote:

>
> For clarification, this is 3-4 PM (15:00 - 16:00) UTC, correct ?.
>
> -mark
>
> - Original Message -
> > From: "Dina Belova" 
> > To: "Matt Riedemann" 
> > Cc: "OpenStack Development Mailing List" <
> openstack-dev@lists.openstack.org>,
> openstack-operat...@lists.openstack.org
> > Sent: Monday, November 9, 2015 4:30:55 AM
> > Subject: Re: [Openstack-operators] [openstack-dev] Performance Team
> summit session results
> >
> > Folks,
> >
> > due to the doodle <http://doodle.com/poll/wv6qt8eqtc3mdkuz#table> 3:00 -
> > 4:00 UTC Tuesdays (starting from tomorrow) is ok for all voted people.
> > Although for the US folks with PST time zone it'll be very early due to
> the
> > time zone change happened for US on November, 1st. Still hope seeing you
> > there on *#openstack-performance* channel :)
> >
> > I've created primary wiki pages for the team
> > <https://wiki.openstack.org/wiki/Performance_Team> and its meetings
> > <https://wiki.openstack.org/wiki/Meetings/Performance> - please feel
> free
> > to add more items to the agenda.
> >
> > See you tomorrow :)
> >
> > Cheers,
> > Dina
> >
> >
> > On Mon, Nov 9, 2015 at 5:38 PM, Dina Belova 
> wrote:
> >
> > > Matt,
> > >
> > > thank you so much for covering [1], [2] and [3] points - I'll ping
> folks
> > > who've written these lines directly and will try to find out the
> answers.
> > >
> > > Cheers,
> > > Dina
> > >
> > > On Fri, Oct 30, 2015 at 1:42 AM, Matt Riedemann <
> > > mrie...@linux.vnet.ibm.com> wrote:
> > >
> > >>
> > >>
> > >> On 10/29/2015 10:55 AM, Matt Riedemann wrote:
> > >>
> > >>>
> > >>>
> > >>> On 10/29/2015 9:30 AM, Dina Belova wrote:
> > >>>
> > >>>> Hey folks!
> > >>>>
> > >>>> On Tuesday we had great summit session about performance team
> kick-off
> > >>>> and yesterday it was a great LDT session as well and I’m really
> glad to
> > >>>> see how much does the OpenStack performance topic is important for
> all
> > >>>> of us. 40 minutes session surely was not enough to analyse
> everyone’s
> > >>>> feedback and bottlenecks people usually see, so I’ll try to finalise
> > >>>> what have been discussed and the next steps in this email.
> > >>>>
> > >>>> Performance team kick-off session
> > >>>> (
> > >>>>
> https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off
> > >>>> )
> > >>>>
> > >>>> can be shortly described with the following points:
> > >>>>
> > >>>>   * IBM, Intel, HP, Mirantis, Rackspace, Red Hat, Yahoo! and others
> were
> > >>>> taking part in the session
> > >>>>   * Various tools are used right now for OpenStack benchmarking and
> > >>>> profiling right now:
> > >>>>   o Rally (IBM, HP, Mirantis, Yahoo!)
> > >>>>   o Shaker (Mirantis, merging its functionality to Rally right
> now)
> > >>>>   o Gatling (Rackspace)
> > >>>>   o Zipkin (Yahoo!)
> > >>>>   o JMeter (Yandex)
> > >>>>   o and others…
> > >>>>   * Various issues have been seen during the OpenStack cloud
> operating
> > >>>> (full list can be found here -
> > >>>> https://etherpad.openstack.org/p/openstack-performance-issues).
> > >>>> Most
> > >>>> mentioned issues were the following:
> > >>>>   o performance of DB-related layers (DB itself and oslo.db) -
> it is
> > >>>> about 7 abstraction DB layers in Nova; performance of Nova
> > >>>> conductor was mentioned several times
> > >>>>   o performance of MQ-related layers (MQ itself and
> oslo.messaging)
> > >>>>   * Different companies are using different standards for
> performance
> > >>>> benchmarking (both control plane and data plane testing)
> > >>>>   * The 

Re: [openstack-dev] [tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

[Dina Belova]

Boris,

I believe finishing work related to OSprofiler development is crucial for
the teams like Performance Team kicked off during the Tokyo summit. I'll
raise question is people are interested in taking part in its development
tomorrow on IRC meeting
<https://wiki.openstack.org/wiki/Meetings/Performance>.

Thanks for writing this email and summarising for that needs to be done.

Cheers,
Dina

On Mon, Nov 9, 2015 at 7:57 PM, Boris Pavlovic  wrote:

> Hi stackers,
>
> Intro
> ---
>
> It's not a big secret that OpenStack is huge and complicated ecosystem of
> different
> services that are working together to implement OpenStack API.
>
> For example booting VM is going through many projects and services:
> nova-api, nova-scheduler, nova-compute, glance-api, glance-registry,
> keystone, cinder-api, neutron-api... and many others.
>
> The question is how to understand what part of the request takes the most
> of the time and should be improved. It's especially interested to get such
> data under the load.
>
> To make it simple, I wrote OSProfiler which is tiny library that should be
> added to all OpenStack
> projects to create cross project/service tracer/profiler.
>
> Demo (trace of CLI command: nova boot) can be found here:
> http://boris-42.github.io/ngk.html
>
> This library is very simple. For those who wants to know how it works and
> how it's integrated with OpenStack take a look here:
> https://github.com/openstack/osprofiler/blob/master/README.rst
>
> What is the current status?
> ---
>
> Good news:
> - OSprofiler is mostly done
> - OSprofiler is integrated with Cinder, Glance, Trove & Ceilometer
>
> Bad news:
> - OSprofiler is not integrated in a lot of important projects: Keystone,
> Nova, Neutron
> - OSprofiler can use only Ceilometer + oslo.messaging as a backend
> - OSprofiler stores part of arguments in api-paste.ini part in
> project.conf which is terrible thing
> - There is no DSVM job that check that changes in OSprofiler don't break
> the projects that are using it
> - It's hard to enable OSprofiler in DevStack
>
> Good news:
> I spend some time and made 4 specs that should address most of issues:
> https://github.com/openstack/osprofiler/tree/master/doc/specs
>
> Let's make it happen in Mitaka!
>
> Thoughts?
> By the way somebody would like to join this effort?)
>
> Best regards,
> Boris Pavlovic
>
>
>
> __
> OpenStack Development Mailing 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,

Dina Belova

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

Re: [openstack-dev] [Openstack-operators] Performance Team summit session results

[Dina Belova]

Folks,

due to the doodle <http://doodle.com/poll/wv6qt8eqtc3mdkuz#table> 3:00 -
4:00 UTC Tuesdays (starting from tomorrow) is ok for all voted people.
Although for the US folks with PST time zone it'll be very early due to the
time zone change happened for US on November, 1st. Still hope seeing you
there on *#openstack-performance* channel :)

I've created primary wiki pages for the team
<https://wiki.openstack.org/wiki/Performance_Team> and its meetings
<https://wiki.openstack.org/wiki/Meetings/Performance> - please feel free
to add more items to the agenda.

See you tomorrow :)

Cheers,
Dina


On Mon, Nov 9, 2015 at 5:38 PM, Dina Belova  wrote:

> Matt,
>
> thank you so much for covering [1], [2] and [3] points - I'll ping folks
> who've written these lines directly and will try to find out the answers.
>
> Cheers,
> Dina
>
> On Fri, Oct 30, 2015 at 1:42 AM, Matt Riedemann <
> mrie...@linux.vnet.ibm.com> wrote:
>
>>
>>
>> On 10/29/2015 10:55 AM, Matt Riedemann wrote:
>>
>>>
>>>
>>> On 10/29/2015 9:30 AM, Dina Belova wrote:
>>>
>>>> Hey folks!
>>>>
>>>> On Tuesday we had great summit session about performance team kick-off
>>>> and yesterday it was a great LDT session as well and I’m really glad to
>>>> see how much does the OpenStack performance topic is important for all
>>>> of us. 40 minutes session surely was not enough to analyse everyone’s
>>>> feedback and bottlenecks people usually see, so I’ll try to finalise
>>>> what have been discussed and the next steps in this email.
>>>>
>>>> Performance team kick-off session
>>>> (
>>>> https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off
>>>> )
>>>>
>>>> can be shortly described with the following points:
>>>>
>>>>   * IBM, Intel, HP, Mirantis, Rackspace, Red Hat, Yahoo! and others were
>>>> taking part in the session
>>>>   * Various tools are used right now for OpenStack benchmarking and
>>>> profiling right now:
>>>>   o Rally (IBM, HP, Mirantis, Yahoo!)
>>>>   o Shaker (Mirantis, merging its functionality to Rally right now)
>>>>   o Gatling (Rackspace)
>>>>   o Zipkin (Yahoo!)
>>>>   o JMeter (Yandex)
>>>>   o and others…
>>>>   * Various issues have been seen during the OpenStack cloud operating
>>>> (full list can be found here -
>>>> https://etherpad.openstack.org/p/openstack-performance-issues).
>>>> Most
>>>> mentioned issues were the following:
>>>>   o performance of DB-related layers (DB itself and oslo.db) - it is
>>>> about 7 abstraction DB layers in Nova; performance of Nova
>>>> conductor was mentioned several times
>>>>   o performance of MQ-related layers (MQ itself and oslo.messaging)
>>>>   * Different companies are using different standards for performance
>>>> benchmarking (both control plane and data plane testing)
>>>>   * The most wished output from the team due to the comments will be:
>>>>   o agree on the “performance testing standard”, including answers
>>>> on the following questions:
>>>>   + what tools need to be used for OpenStack performance
>>>> benchmarking?
>>>>   + what benchmarking meters need to be covered? what we would
>>>> like to compare?
>>>>   + what scenarios need to be covered?
>>>>   + how can we compare performance of different cloud
>>>> deployments?
>>>>   + what performance deployment patterns can be used for various
>>>> workloads?
>>>>   o share test plans and perform benchmarking tests
>>>>   o create methodologies and documentation about best OpenStack
>>>> deployment and performance testing practices
>>>>
>>>>
>>>> We’re going to cover all these topics further. First of all IRC channel
>>>> for the discussions was created: *#openstack-performance*. We’re going
>>>> to have weekly meeting related to current progress on that channel,
>>>> doodle with the voting can be found here:
>>>> http://doodle.com/poll/wv6qt8eqtc3mdkuz#table
>>>>   (I was brave enough not to include timeslots that were overlapping
>>>> with some of mine really hard-to-move 

Re: [openstack-dev] [Openstack-operators] Performance Team summit session results

[Dina Belova]

Matt,

thank you so much for covering [1], [2] and [3] points - I'll ping folks
who've written these lines directly and will try to find out the answers.

Cheers,
Dina

On Fri, Oct 30, 2015 at 1:42 AM, Matt Riedemann 
wrote:

>
>
> On 10/29/2015 10:55 AM, Matt Riedemann wrote:
>
>>
>>
>> On 10/29/2015 9:30 AM, Dina Belova wrote:
>>
>>> Hey folks!
>>>
>>> On Tuesday we had great summit session about performance team kick-off
>>> and yesterday it was a great LDT session as well and I’m really glad to
>>> see how much does the OpenStack performance topic is important for all
>>> of us. 40 minutes session surely was not enough to analyse everyone’s
>>> feedback and bottlenecks people usually see, so I’ll try to finalise
>>> what have been discussed and the next steps in this email.
>>>
>>> Performance team kick-off session
>>> (
>>> https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off
>>> )
>>>
>>> can be shortly described with the following points:
>>>
>>>   * IBM, Intel, HP, Mirantis, Rackspace, Red Hat, Yahoo! and others were
>>> taking part in the session
>>>   * Various tools are used right now for OpenStack benchmarking and
>>> profiling right now:
>>>   o Rally (IBM, HP, Mirantis, Yahoo!)
>>>   o Shaker (Mirantis, merging its functionality to Rally right now)
>>>   o Gatling (Rackspace)
>>>   o Zipkin (Yahoo!)
>>>   o JMeter (Yandex)
>>>   o and others…
>>>   * Various issues have been seen during the OpenStack cloud operating
>>> (full list can be found here -
>>> https://etherpad.openstack.org/p/openstack-performance-issues). Most
>>> mentioned issues were the following:
>>>   o performance of DB-related layers (DB itself and oslo.db) - it is
>>> about 7 abstraction DB layers in Nova; performance of Nova
>>> conductor was mentioned several times
>>>   o performance of MQ-related layers (MQ itself and oslo.messaging)
>>>   * Different companies are using different standards for performance
>>> benchmarking (both control plane and data plane testing)
>>>   * The most wished output from the team due to the comments will be:
>>>   o agree on the “performance testing standard”, including answers
>>> on the following questions:
>>>   + what tools need to be used for OpenStack performance
>>> benchmarking?
>>>   + what benchmarking meters need to be covered? what we would
>>> like to compare?
>>>   + what scenarios need to be covered?
>>>   + how can we compare performance of different cloud
>>> deployments?
>>>   + what performance deployment patterns can be used for various
>>> workloads?
>>>   o share test plans and perform benchmarking tests
>>>   o create methodologies and documentation about best OpenStack
>>> deployment and performance testing practices
>>>
>>>
>>> We’re going to cover all these topics further. First of all IRC channel
>>> for the discussions was created: *#openstack-performance*. We’re going
>>> to have weekly meeting related to current progress on that channel,
>>> doodle with the voting can be found here:
>>> http://doodle.com/poll/wv6qt8eqtc3mdkuz#table
>>>   (I was brave enough not to include timeslots that were overlapping
>>> with some of mine really hard-to-move activities :))
>>>
>>> Let’s have next week as a voting time, and have first IRC meeting in our
>>> channel the week after next. We can start our further discussions with
>>> “performance” and “performance testing” terms definition and
>>> benchmarking tools analysis.
>>>
>>> Cheers,
>>> Dina
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing 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 for writing this up, it's great to see people getting together
>> and sharing info on performance issues and trying to pinpoint the big
>> ones.
>>
>> I poked through the performance issues etherpad and was wondering how
>&g

[openstack-dev] Performance Team summit session results

[Dina Belova]

Hey folks!

On Tuesday we had great summit session about performance team kick-off and
yesterday it was a great LDT session as well and I’m really glad to see how
much does the OpenStack performance topic is important for all of us. 40
minutes session surely was not enough to analyse everyone’s feedback and
bottlenecks people usually see, so I’ll try to finalise what have been
discussed and the next steps in this email.

Performance team kick-off session (
https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off)
can be shortly described with the following points:


   - IBM, Intel, HP, Mirantis, Rackspace, Red Hat, Yahoo! and others were
   taking part in the session
   - Various tools are used right now for OpenStack benchmarking and
   profiling right now:
   - Rally (IBM, HP, Mirantis, Yahoo!)
  - Shaker (Mirantis, merging its functionality to Rally right now)
  - Gatling (Rackspace)
  - Zipkin (Yahoo!)
  - JMeter (Yandex)
  - and others…
   - Various issues have been seen during the OpenStack cloud operating
   (full list can be found here -
   https://etherpad.openstack.org/p/openstack-performance-issues). Most
   mentioned issues were the following:
   - performance of DB-related layers (DB itself and oslo.db) - it is about
  7 abstraction DB layers in Nova; performance of Nova conductor was
  mentioned several times
  - performance of MQ-related layers (MQ itself and oslo.messaging)
   - Different companies are using different standards for performance
   benchmarking (both control plane and data plane testing)
   - The most wished output from the team due to the comments will be:
   - agree on the “performance testing standard”, including answers on the
  following questions:
 - what tools need to be used for OpenStack performance
 benchmarking?
 - what benchmarking meters need to be covered? what we would like
 to compare?
 - what scenarios need to be covered?
 - how can we compare performance of different cloud deployments?
 - what performance deployment patterns can be used for various
 workloads?
  - share test plans and perform benchmarking tests
  - create methodologies and documentation about best OpenStack
  deployment and performance testing practices


We’re going to cover all these topics further. First of all IRC channel for
the discussions was created: *#openstack-performance*. We’re going to have
weekly meeting related to current progress on that channel, doodle with the
voting can be found here: http://doodle.com/poll/wv6qt8eqtc3mdkuz#table
 (I was brave enough not to include timeslots that were overlapping with
some of mine really hard-to-move activities :))

Let’s have next week as a voting time, and have first IRC meeting in our
channel the week after next. We can start our further discussions with
“performance” and “performance testing” terms definition and benchmarking
tools analysis.

Cheers,
Dina
__
OpenStack Development Mailing 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] [Large Deployments Team][Performance Team] New informal working group suggestion

[Dina Belova]

Sandeep,

sorry for the late response :) I'm hoping to define 'spheres of interest'
and most painful moments using people's experience on Tokyo summit and
we'll find out what needs to be tested most and can be actually done. You
can share your ideas of what needs to be tested and focused on in
https://etherpad.openstack.org/p/openstack-performance-issues etherpad,
this will be a pool of ideas I'm going to use in Tokyo.

I can either create irc channel for the discussions or we can use
#openstack-operators channel as LDT is using it for the communication.
After Tokyo summit I'm planning to set Doodle voting for the time people
will be comfortable with to have periodic meetings :)

Cheers,
Dina

On Fri, Sep 25, 2015 at 1:52 PM, Sandeep Raman 
wrote:

> On Tue, Sep 22, 2015 at 6:27 PM, Dina Belova  wrote:
>
>> Hey, OpenStackers!
>>
>> I'm writing to propose to organise new informal team to work specifically
>> on the OpenStack performance issues. This will be a sub team in already
>> existing Large Deployments Team, and I suppose it will be a good idea to
>> gather people interested in OpenStack performance in one room and identify
>> what issues are worrying contributors, what can be done and share results
>> of performance researches :)
>>
>
> Dina, I'm focused in performance and scale testing [no coding
> background].How can I contribute and what is the expectation from this
> informal team?
>
>>
>> So please volunteer to take part in this initiative. I hope it will be
>> many people interested and we'll be able to use cross-projects session
>> slot <http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and
>> hold a kick-off meeting.
>>
>
> I'm not coming to Tokyo. How could I still be part of discussions if any?
> I also feel it is good to have a IRC channel for perf-scale discussion. Let
> me know your thoughts.
>
>
>> I would like to apologise I'm writing to two mailing lists at the same
>> time, but I want to make sure that all possibly interested people will
>> notice the email.
>>
>> Thanks and see you in Tokyo :)
>>
>> Cheers,
>> Dina
>>
>> --
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Senior 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
>>
>>
>
> __
> OpenStack Development Mailing 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,

Dina Belova

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

Re: [openstack-dev] [Openstack-operators] [Large Deployments Team][Performance Team] New informal working group suggestion

[Dina Belova]

Kris,

I've created a ether pad - we can fill it with data before the summit and
discuss them in Tokyo.
https://etherpad.openstack.org/p/openstack-performance-issues

Cheers,
Dina

On Wed, Sep 23, 2015 at 9:32 PM, Kris G. Lindgren 
wrote:

> Dina,
>
> Do we have a place to put things (etherpad) that we are seeing performance
> issues with?  I know we are seeing issues with CPU load under
> nova-conductor as well as some stuff with the neutron API timing out (seems
> like it never responds to the request (no log entry on the neutron side).
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Matt Van Winkle
> Date: Tuesday, September 22, 2015 at 7:46 AM
> To: Dina Belova, OpenStack Development Mailing List, "
> openstack-operat...@lists.openstack.org"
> Subject: Re: [Openstack-operators] [Large Deployments Team][Performance
> Team] New informal working group suggestion
>
> Thanks, Dina!
>
> For context to the rest of the LDT folks, Dina reached out to me about
> working on this under our umbrella for now.  It made sense until we
> understand if it's a large enough thing to live as its own working group
> because most of us have various performance concerns too.  So, like Public
> Clouds, we'll have to figure out how to integrate this sub group.
>
> I suspect the time slot for Tokyo is already packed, so the work for the
> Performance subgroup may have to be informal or in other sessions, but I'll
> start working with Tom and the folks covering the session for me (since I
> won't be able to make it) on what we might be able to do.  I've also asked
> Dina to join the Oct meeting prior to the Summit so we can further discuss
> the sub team.
>
> Thanks!
> VW
>
> From: Dina Belova 
> Date: Tuesday, September 22, 2015 7:57 AM
> To: OpenStack Development Mailing List ,
> "openstack-operat...@lists.openstack.org" <
> openstack-operat...@lists.openstack.org>
> Subject: [Large Deployments Team][Performance Team] New informal working
> group suggestion
>
> Hey, OpenStackers!
>
> I'm writing to propose to organise new informal team to work specifically
> on the OpenStack performance issues. This will be a sub team in already
> existing Large Deployments Team, and I suppose it will be a good idea to
> gather people interested in OpenStack performance in one room and identify
> what issues are worrying contributors, what can be done and share results
> of performance researches :)
>
> So please volunteer to take part in this initiative. I hope it will be
> many people interested and we'll be able to use cross-projects session
> slot <http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and
> hold a kick-off meeting.
>
> I would like to apologise I'm writing to two mailing lists at the same
> time, but I want to make sure that all possibly interested people will
> notice the email.
>
> Thanks and see you in Tokyo :)
>
> Cheers,
> Dina
>
> --
>
> Best regards,
>
> Dina Belova
>
> Senior Software Engineer
>
> Mirantis Inc.
>
>


-- 

Best regards,

Dina Belova

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

[openstack-dev] [Large Deployments Team][Performance Team] New informal working group suggestion

[Dina Belova]

Hey, OpenStackers!

I'm writing to propose to organise new informal team to work specifically
on the OpenStack performance issues. This will be a sub team in already
existing Large Deployments Team, and I suppose it will be a good idea to
gather people interested in OpenStack performance in one room and identify
what issues are worrying contributors, what can be done and share results
of performance researches :)

So please volunteer to take part in this initiative. I hope it will be many
people interested and we'll be able to use cross-projects session slot
<http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and hold a
kick-off meeting.

I would like to apologise I'm writing to two mailing lists at the same
time, but I want to make sure that all possibly interested people will
notice the email.

Thanks and see you in Tokyo :)

Cheers,
Dina

-- 

Best regards,

Dina Belova

Senior 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

Re: [openstack-dev] [Fuel] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?

[Dina Belova]

Alexei,

actually we do not insist this should b done for the MOS 6.1. That was the
question to the audience if someone is having other idea. All these
discussions have roots in the bug
https://bugs.launchpad.net/fuel/+bug/1447619 - we have found the issue with
RabbitMQ cluster behaviour under the networking load and Bogdan, Alexei
Khivin and Alex Nevenchannyy found that it possibly might be fixed
upgrading the RabbitMQ (trying it now). And actually this RabbitMQ release
contains lots of crucial bug fixes even without mentioned by Bogdan.

For 6.1 the found workaround might be used, section in the docs written,
etc. The question to the company is if that will be enough and what are we
going to do with it in future.

Cheers,
Dina

On Wed, Apr 29, 2015 at 11:24 AM, Alexei Sheplyakov <
asheplya...@mirantis.com> wrote:

> Hi,
>
> Given that
>
> - MOS 6.1 should be released in a few weeks
> - rabbitmq is kind of a heart of OpenStack
>
> upgrading rabbitmq in MOS 6.1 seems to be an extremely bad idea.
>
> There will be always some bugs (both known and unknown), but we can't keep
> updating various
> components forever and should stop at some moment (which is presumably
> called `soft code freeze').
>
> Best regards,
>   Alexei
>
>
> On Wed, Apr 29, 2015 at 11:04 AM, Bogdan Dobrelya 
> wrote:
>
>> Hello.
>>
>> There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]:
>> 1) At least two bugfixes related to the current high-load issue with MQ
>> [1]:
>> - 26404 prevent queue synchronisation from hanging if there is a very
>> short partition just as it starts (since 3.1.0)
>> - 26368 prevent autoheal from hanging when loser shuts down before the
>> winner  learns it is the winner (since 3.1.0)
>> 2) We should as well check how the new 'pause-if-all-down' option works
>> for split brain recovery.
>> 3) We should address the 'force_boot' recommendations from this mail
>> thread [2] to speed up the MQ cluster assemble time.
>>
>> The question is - is it worth it to do this in the 6.1 release scope?
>> I vote to postpone this for the 7.0 dev cycle as the impact of such
>> changes might be unpredictable.
>>
>> [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt
>> [1] https://bugs.launchpad.net/fuel/+bug/1447619
>> [2]
>>
>> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Skype #bogdando_at_yahoo.com
>> Irc #bogdando
>>
>
>


-- 

Best regards,

Dina Belova

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

Re: [openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse

[Dina Belova]

Sam,

It really looks like you're having old *.pyc files locally in this repo
(probably left from other branch testing)... As I understood, you just
cloned clean repo and first tests you've ran were these ones? If no,
removing all *.pyc files will help you, otherwise I have no clear idea why
you might have unit tests failing in the new just cloned repository... Need
to investigate.

Cheers,
Dina

On Wed, Dec 3, 2014 at 12:34 PM, sam song  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi, folks:
>
> I clone the stable/icehouse branch of ceilometer project from github,
> use "tox -r -e py26" to run unit tests on CentOS 6.5 system.
> Unfortunately there are many cases failed. You can find the output in
> test.log, and pip.log is the output of "pip list" in py26 virtualenv.
> All python packages are download from pypi.douban.com in China, which is
> fresh according to http://www.pypi-mirrors.org/.
>
> Any ideas to fix it are appreciated.
> Thanks in advance.
>
> Sam
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUftk7AAoJEPDWvv0r0XeReC4IAKh+cN2JHGsOEd3/VUsdBnMi
> Bxlvjp0uzMB8vs2zOljLntf9XZGjPBoOWZcwArYHL3aLe1A+cHxXqm6Y+i0zLmJ2
> jf0oV4War+MliptaJNE6BH9URBZ4p2WqxL2k6+V9SP+9dkCHjzTIOZ4zO31jbZy3
> P7lfTzQELYAys4CFl3kEV/hm2JIPZXvpVUYGdCEYBc3CVcopCq+wDBChnQx3tIhh
> ao4KXzx/fOHQK2HLSiv+p2y4XNWDIMA8wpGyjn97JL/eF+lckrVIBd3zFlpT+VtE
> nidK+rjzWpSDdObEKdEXh+C0jy0S5uBrSU+5hba0GNRVUbnnXP5jHrsP7HZ6900=
> =mwtP
> -END PGP SIGNATURE-
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Ceilometer] Adding pylint checking of new ceilometer patches

[Dina Belova]

Igor,

Personally this idea looks really nice to me, as this will help to avoid
strange code being merged and not found via reviewing process.

Cheers,
Dina

On Fri, Oct 3, 2014 at 12:40 PM, Igor Degtiarov 
wrote:

> Hi folks!
>
> I try too guess do we need in ceilometer checking new patches for
> critical errors with pylint?
>
> As far as I know Nova and Sahara and others have such check. Actually
> it is not checking of all project but comparing of the number of
> errors without new patch and with it, and if diff is more then 0 then
> patch are not taken.
>
> I have taken as pattern Sahara's solution and proposed a patch for
> ceilometer:
> https://review.openstack.org/#/c/125906/
>
> Cheers,
> Igor Degtiarov
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Ceilometer] MySQL performance and Mongodb backend maturity question

[Dina Belova]

Qiming, yes - for MongoDB, DB2, HBase and SQL-based, all the backends
support events feature for now, this has been merged afair ~month or two
ago.

Cheers
Dina

On Thu, Sep 25, 2014 at 11:45 AM, Qiming Teng 
wrote:

> So MongoDB support to events is ready in tree?
>
> Regards,
>   Qiming
>
> On Thu, Sep 25, 2014 at 10:26:08AM +0300, Igor Degtiarov wrote:
> > Hi, Qiming Teng.
> >
> > Now all backends support events. So you may use MongoDB instead of
> > MySQL, or if you like you may choose HBase.
> >
> > Cheers, Igor.
> > -- Igor
> >
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

[Dina Belova]

Thank you folks, it's a big pleasure and responsibility, and I'm really
happy to join you :)

Thanks!
Dina

On Fri, Sep 19, 2014 at 12:54 PM, Eoghan Glynn  wrote:

>
>
> > Hi,
> >
> > Dina has been doing a great work and has been very helpful during the
> > Juno cycle and her help is very valuable. She's been doing a lot of
> > reviews and has been very active in our community.
> >
> > I'd like to propose that we add Dina Belova to the ceilometer-core
> > group, as I'm convinced it'll help the project.
> >
> > Please, dear ceilometer-core members, reply with your votes!
>
> With seven yeas and zero nays, I think we can call a result in this
> vote.
>
> Welcome to the ceilometer-core team Dina!
>
> Cheers,
> Eoghan
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer]How to collect the real-time data

[Dina Belova]

Jian, hello

What do you actually mean by 'real-time data'? Here in Ceilometer we're
having 'events' feature, for instance - so services like Nova, Cinder, etc.
are notifying Ceilometer about recent changes like 'VM was created', 'IP
was assigned', etc. - this data is more than recent one.

May you provide us with kind of use case or example, whatever do you mean
by 'real-time data'?

Cheers,
Dina

On Tue, Sep 9, 2014 at 3:45 PM, lijian  wrote:

> Hi folks,
> We know the ceilometer collect the data through poster periodically.
> But how to collect the real-time data?  whether plan to implement it
> or not
>
> Thanks!
> Jian Li
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension

[Dina Belova]

Gordon, exactly. Moreover, I think percentage of failings is something
close to the 15-20% of all the runs - sometimes it passes for the change,
and next run on this exactly the same commit will be the failed for some
reason.

Thanks
Dina


On Thu, Aug 21, 2014 at 10:46 PM, gordon chung  wrote:

> is it possible that it's not on all the nodes?
>
> seems like it passed here: https://review.openstack.org/#/c/109207/ but
> another patch at roughly the same time failed
> https://review.openstack.org/#/c/113549/
>
> cheers,
> *gord*
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

[Dina Belova]

Hisashi Osanai, np :)
You're welcome :)


On Thu, Aug 14, 2014 at 5:13 AM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:

>
> On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou  wrote:
> >> Means the py33 needs to execute on stable/icehouse. Here I
> misunderstand something...
> > Not it does not, that line in tox.ini is not use by the gate.
>
> >>> this is a problem in the infrastructure config.
> >> Means execfile function calls on python33 in happybase is a problem. If
> my understanding
> >> is correct, I agree with you and I think this is the direct cause of
> this problem.
> >>
> >> Your idea to solve this is creating a patch for the direct cause, right?
> > My idea to solve this is to create a patch on
> > http://git.openstack.org/cgit/openstack-infra/config/
> > to exclude py33 on the stable/icehouse branch of Ceilometer in the gate.
>
> Sorry to use your time for explanation above again and thanks for it. I'm
> happy to have
> clear understanding your thought.
>
> On Wednesday, August 13, 2014 7:54 PM, Dina Belova wrote:
> > Here it is: https://review.openstack.org/#/c/113842/
> Thank you for providing the fix. I surprised the speed for it. it's really
> fast...
>
> Thanks again!
> Hisashi Osanai
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

[Dina Belova]

Here it is: https://review.openstack.org/#/c/113842/

Thanks,
Dina


On Wed, Aug 13, 2014 at 2:40 PM, Dina Belova  wrote:

> Julien, will do right now.
>
> Thanks
> Dina
>
>
> On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou  wrote:
>
>> On Wed, Aug 13 2014, Osanai, Hisashi wrote:
>>
>> > One idea to solve this problem is:
>> > If the py33 doesn't need to execute on stable/icehouse, just eliminate
>> > the py33.
>>
>> Yes, that IS the solution.
>>
>> But modifying tox.ini is not going be a working implementation of that
>> solution.
>>
>> >> This is not a problem in tox.ini,
>> > Means the py33 needs to execute on stable/icehouse. Here I
>> misunderstand something...
>>
>> Not it does not, that line in tox.ini is not use by the gate.
>>
>> >> this is a problem in the infrastructure config.
>> > Means execfile function calls on python33 in happybase is a problem. If
>> my understanding
>> > is correct, I agree with you and I think this is the direct cause of
>> this problem.
>> >
>> > Your idea to solve this is creating a patch for the direct cause, right?
>>
>> My idea to solve this is to create a patch on
>> http://git.openstack.org/cgit/openstack-infra/config/
>> to exclude py33 on the stable/icehouse branch of Ceilometer in the gate.
>>
>> --
>> Julien Danjou
>> # Free Software hacker
>> # http://julien.danjou.info
>>
>> _______
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

[Dina Belova]

Julien, will do right now.

Thanks
Dina


On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou  wrote:

> On Wed, Aug 13 2014, Osanai, Hisashi wrote:
>
> > One idea to solve this problem is:
> > If the py33 doesn't need to execute on stable/icehouse, just eliminate
> > the py33.
>
> Yes, that IS the solution.
>
> But modifying tox.ini is not going be a working implementation of that
> solution.
>
> >> This is not a problem in tox.ini,
> > Means the py33 needs to execute on stable/icehouse. Here I misunderstand
> something...
>
> Not it does not, that line in tox.ini is not use by the gate.
>
> >> this is a problem in the infrastructure config.
> > Means execfile function calls on python33 in happybase is a problem. If
> my understanding
> > is correct, I agree with you and I think this is the direct cause of
> this problem.
> >
> > Your idea to solve this is creating a patch for the direct cause, right?
>
> My idea to solve this is to create a patch on
> http://git.openstack.org/cgit/openstack-infra/config/
> to exclude py33 on the stable/icehouse branch of Ceilometer in the gate.
>
> --
> Julien Danjou
> # Free Software hacker
> # http://julien.danjou.info
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

[Dina Belova]

Hisashi Osanai, I have really strange feeling about this issue.
It happens only with py33 job for icehouse branch? Because actually happy
base is the same for the master code Jenkins jobs, so it looks like that
exec file issue should appear in master runs as well... Do I understand
everything right?

As I understand Julien, he proposes to run this job only for master (as it
works for now magically for master checks) and skip in for everything
earlier - mostly because it won't work for stable branches anyway - as
there were no fixed ceilometer code itself there.

Thanks,
Dina


On Wed, Aug 13, 2014 at 2:11 PM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:

>
> On Wednesday, August 13, 2014 5:03 PM, Julien Danjou wrote:
> > This is not a problem in tox.ini, this is a problem in the
> > infrastructure config. Removing py33 from the envlist in tox.ini isn't
> > going to fix anything unforunately.
>
> Thank you for your quick response.
>
> I may misunderstand this topic. Let me clarify ...
> My understanding is:
> - the py33 failed because there is a problem that the happybase-0.8 cannot
>   work with python33 env. (execfile function calls on python33 doesn't
> work)
> - the happybase is NOT an OpenStack component.
> - the py33 doesn't need to execute on stable/icehouse
>
> One idea to solve this problem is:
> If the py33 doesn't need to execute on stable/icehouse, just eliminate the
> py33.
>
> > This is not a problem in tox.ini,
> Means the py33 needs to execute on stable/icehouse. Here I misunderstand
> something...
>
> > this is a problem in the infrastructure config.
> Means execfile function calls on python33 in happybase is a problem. If my
> understanding
> is correct, I agree with you and I think this is the direct cause of this
> problem.
>
> Your idea to solve this is creating a patch for the direct cause, right?
>
> Thanks in advance,
> Hisashi Osanai
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

[Dina Belova]

Folks, it looks like mongo packages were retired as a result of this
ticket: https://fedorahosted.org/rel-eng/ticket/5963
Although also it looks like this mistake was quickly reverted here:
http://pkgs.fedoraproject.org/cgit/mongodb.git/commit/?h=el6

Let's wait if it fixed the issue, but it looks like it should be ok for now.

Thanks,
Dina


On Tue, Aug 12, 2014 at 2:23 PM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:

>
> On Tuesday, August 12, 2014 7:05 PM, Dina Belova wrote:
> > that is blocking the Ceilometer gate at all for now.
>
> Thank you for your quick response.
> I understand current situation.
>
> Thanks again!
> Hisashi Osanai
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment

[Dina Belova]

Hisashi Osanai, yes, that is blocking the Ceilometer gate at all for now.

The reason might be in updated centos6 image in the gate, but I have no
opportunity to check it actually.

Infra folks, can you help us?

Thanks,
Dina


On Tue, Aug 12, 2014 at 1:47 PM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:

>
> Hi,
>
> I got an error message when Jenkins executed "tox -epy26" in the following
> fix.
> https://review.openstack.org/#/c/112771/
>
> I think that the reason of the error message is a mongod isn't installed
> in test
> environment. (it works in my test env)
>
> Do you have any idea to solve this?
>
> - setup-test-env.sh
>  16 export PATH=${PATH:+$PATH:}/sbin:/usr/sbin
>  17 if ! which mongod >/dev/null 2>&1
>  18 then
>  19 echo "Could not find mongod command" 1>&2
>  20 exit 1
>  21 fi
>
> - console.log
> 2014-08-12 07:25:03.329 | + tox -epy26
> 2014-08-12 07:25:03.542 | py26 create:
> /home/jenkins/workspace/gate-ceilometer-python26/.tox/py26
> 2014-08-12 07:25:05.255 | py26 installdeps:
> -r/home/jenkins/workspace/gate-ceilometer-python26/requirements.txt,
> -r/home/jenkins/workspace/gate-ceilometer-python26/test-requirements.txt
> 2014-08-12 07:28:01.581 | py26 develop-inst:
> /home/jenkins/workspace/gate-ceilometer-python26
> 2014-08-12 07:28:07.861 | py26 runtests: commands[0] | bash -x
> /home/jenkins/workspace/gate-ceilometer-python26/setup-test-env.sh python
> setup.py testr --slowest --testr-args=
> 2014-08-12 07:28:07.864 | + set -e
> 2014-08-12 07:28:07.865 | ++ mktemp -d CEILO-MONGODB-X
> 2014-08-12 07:28:07.866 | + MONGO_DATA=CEILO-MONGODB-t6f5p
> 2014-08-12 07:28:07.866 | + MONGO_PORT=29000
> 2014-08-12 07:28:07.866 | + trap clean_exit EXIT
> 2014-08-12 07:28:07.867 | + mkfifo CEILO-MONGODB-t6f5p/out
> 2014-08-12 07:28:07.868 | + export
> PATH=/home/jenkins/workspace/gate-ceilometer-python26/.tox/py26/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin
> 2014-08-12 07:28:07.869 | +
> PATH=/home/jenkins/workspace/gate-ceilometer-python26/.tox/py26/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin
> 2014-08-12 07:28:07.869 | + which mongod
> 2014-08-12 07:28:07.870 | + echo 'Could not find mongod command'
> 2014-08-12 07:28:07.870 | Could not find mongod command
> 2014-08-12 07:28:07.871 | + exit 1
> 2014-08-12 07:28:07.871 | + clean_exit
> 2014-08-12 07:28:07.872 | + local error_code=1
> 2014-08-12 07:28:07.872 | + rm -rf CEILO-MONGODB-t6f5p
> 2014-08-12 07:28:07.873 | ++ jobs -p
> 2014-08-12 07:28:07.873 | + kill
> 2014-08-12 07:28:07.874 | kill: usage: kill [-s sigspec | -n signum |
> -sigspec] pid | jobspec ... or kill -l [sigspec]
> 2014-08-12 07:28:07.875 | ERROR: InvocationError: '/bin/bash -x
> /home/jenkins/workspace/gate-ceilometer-python26/setup-test-env.sh python
> setup.py testr --slowest --testr-args='
>
> Best Regards,
> Hisashi Osanai
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [qa] Test Ceilometer polling in tempest

[Dina Belova]

Ildiko, thanks for starting this discussion.

Really, that is quite painful problem for Ceilometer and QA team. As far as
I know, currently there is some kind of tendency of making integration
Tempest tests quicker and less resource consuming - that's quite logical
IMHO. Polling as a way of information collecting from different services
and projects is quite consuming speaking about load on Nova API, etc. -
that's why I completely understand the wish of QA team to get rid of it,
although polling still makes lots work inside Ceilometer, and that's why
integration testing for this feature is really important for me as
Ceilometer contributor - without pollsters testing we have no way to check
its workability.

That's why I'll be really glad if Ildiko's (or whatever other) solution
that will allow polling testing in the gate will be found and accepted.

Problem with described above solution requires some kind of change in what
do we call "environment preparing" for the integration testing - and we
really need QA crew help here. Afair polling deprecation was suggested in
some of the IRC discussions (by only notifications usage), but that's not
the solution that might be just used right now - but we need way of
Ceilometer workability verification right now to continue work on its
improvement.

So any suggestions and comments are welcome here :)

Thanks!
Dina


On Wed, Jul 16, 2014 at 7:06 PM, Ildikó Váncsa 
wrote:

>  Hi Folks,
>
>
>
> We’ve faced with some problems during running Ceilometer integration tests
> on the gate. The main issue is that we cannot test the polling mechanism,
> as if we use a small polling interval, like 1 min, then it puts a high
> pressure on Nova API. If we use a longer interval, like 10 mins, then we
> will not be able to execute any tests successfully, because it would run
> too long.
>
>
>
> The idea, to solve this issue,  is to reconfigure Ceilometer, when the
> polling is tested. Which would mean to change the polling interval from the
> default 10 mins to 1 min at the beginning of the test, restart the service
> and when the test is finished, the polling interval should be changed back
> to 10 mins, which will require one more service restart. The downside of
> this idea is, that it needs service restart today. It is on the list of
> plans to support dynamic re-configuration of Ceilometer, which would mean
> the ability to change the polling interval without restarting the service.
>
>
>
> I know that this idea isn’t ideal from the PoV that the system
> configuration is changed during running the tests, but this is an expected
> scenario even in a production environment. We would change a parameter that
> can be changed by a user any time in a way as users do it too. Later on,
> when we can reconfigure the polling interval without restarting the
> service, this approach will be even simpler.
>
>
>
> This idea would make it possible to test the polling mechanism of
> Ceilometer without any radical change in the ordering of test cases or any
> other things that would be strange in integration tests. We couldn’t find
> any better way to solve the issue of the load on the APIs caused by polling.
>
>
>
> What’s your opinion about this scenario? Do you think it could be a viable
> solution to the above described problem?
>
>
>
> Thanks and Best Regards,
>
> Ildiko
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring

[Dina Belova]

Dims,

No problem with creating the specs, we just want to understand if the
community is OK with our suggestions in general :)
If so, I'll create the appropriate specs and we'll discuss them :)

Thanks
-- Dina


On Tue, Jun 10, 2014 at 3:31 PM, Davanum Srinivas  wrote:

> Dina, Alexey,
>
> Do you mind filing some spec(s) please?
>
> http://markmail.org/message/yqhndsr3zrqcfwq4
> http://markmail.org/message/kpk35uikcnodq3jb
>
> thanks,
> dims
>
> On Tue, Jun 10, 2014 at 7:03 AM, Dina Belova  wrote:
> > Hello, stackers!
> >
> >
> > Oslo.messaging is future of how different OpenStack components
> communicate
> > with each other, and really I’d love to start discussion about how we can
> > make this library even better then it’s now and how can we refactor it
> make
> > more production-ready.
> >
> >
> > As we all remember, oslo.messaging was initially inspired to be created
> as a
> > logical continuation of nova.rpc - as a separated library, with lots of
> > transports supported, etc. That’s why oslo.messaging inherited not only
> > advantages of now did the nova.rpc work (and it were lots of them), but
> also
> > some architectural decisions that currently sometimes lead to the
> > performance issues (we met some of them while Ceilometer performance
> testing
> > [1] during the Icehouse).
> >
> >
> > For instance, simple testing messaging server (with connection pool and
> > eventlet) can process 700 messages per second. The same functionality
> > implemented using plain kombu (without connection pool and eventlet)
>  driver
> > is processing ten times more - 7000-8000 messages per second.
> >
> >
> > So we have the following suggestions about how we may make this process
> > better and quicker (and really I’d love to collect your feedback, folks):
> >
> >
> > 1) Currently we have main loop running in the Executor class, and I guess
> > it’ll be much better to move it to the Server class, as it’ll make
> > relationship between the classes easier and will leave Executor only one
> > task - process the message and that’s it (in blocking or eventlet mode).
> > Moreover, this will make further refactoring much easier.
> >
> > 2) Some of the drivers implementations (such as impl_rabbit and
> impl_qpid,
> > for instance) are full of useless separated classes that in reality
> might be
> > included to other ones. There are already some changes making the whole
> > structure easier [2], and after the 1st issue will be solved Dispatcher
> and
> > Listener also will be able to be refactored.
> >
> > 3) If we’ll separate RPC functionality and messaging functionality it’ll
> > make code base clean and easily reused.
> >
> > 4) Connection pool can be refactored to implement more efficient
> connection
> > reusage.
> >
> >
> > Folks, are you ok with such a plan? Alexey Kornienko already started
> some of
> > this work [2], but really we want to be sure that we chose the correct
> > vector of development here.
> >
> >
> > Thanks!
> >
> >
> > [1]
> >
> https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing
> >
> > [2]
> >
> https://review.openstack.org/#/q/status:open+owner:akornienko+project:openstack/oslo.messaging,n,z
> >
> >
> > Best regards,
> >
> > Dina Belova
> >
> > Software Engineer
> >
> > Mirantis Inc.
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [oslo][messaging] Further improvements and refactoring

[Dina Belova]

Hello, stackers!


Oslo.messaging is future of how different OpenStack components communicate
with each other, and really I’d love to start discussion about how we can
make this library even better then it’s now and how can we refactor it make
more production-ready.


As we all remember, oslo.messaging was initially inspired to be created as
a logical continuation of nova.rpc - as a separated library, with lots of
transports supported, etc. That’s why oslo.messaging inherited not only
advantages of now did the nova.rpc work (and it were lots of them), but
also some architectural decisions that currently sometimes lead to the
performance issues (we met some of them while Ceilometer performance
testing [1] during the Icehouse).


For instance, simple testing messaging server (with connection pool and
eventlet) can process 700 messages per second. The same functionality
implemented using plain kombu (without connection pool and eventlet)
driver is processing ten times more - 7000-8000 messages per second.


So we have the following suggestions about how we may make this process
better and quicker (and really I’d love to collect your feedback, folks):


1) Currently we have main loop running in the Executor class, and I guess
it’ll be much better to move it to the Server class, as it’ll make
relationship between the classes easier and will leave Executor only one
task - process the message and that’s it (in blocking or eventlet mode).
Moreover, this will make further refactoring much easier.

2) Some of the drivers implementations (such as impl_rabbit and impl_qpid,
for instance) are full of useless separated classes that in reality might
be included to other ones. There are already some changes making the whole
structure easier [2], and after the 1st issue will be solved Dispatcher and
Listener also will be able to be refactored.

3) If we’ll separate RPC functionality and messaging functionality it’ll
make code base clean and easily reused.

4) Connection pool can be refactored to implement more efficient connection
reusage.


Folks, are you ok with such a plan? Alexey Kornienko already started some
of this work [2], but really we want to be sure that we chose the correct
vector of development here.


Thanks!


[1]
https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing

[2]
https://review.openstack.org/#/q/status:open+owner:akornienko+project:openstack/oslo.messaging,n,z

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

[Dina Belova]

Folks,

setuptools 4.0.1 and 3.7.1 have been released - these should fix the issue.

-- Dina


On Mon, Jun 2, 2014 at 4:45 PM, Dina Belova  wrote:

> The newest setuptools has been removed from the gate mirror - the latest
> there now is 3.6 - that *might* in the gate.
> We'll see if it'll help. It looks like there is first successful Neutron
> job there :)
>
> -- Dina
>
>
> On Mon, Jun 2, 2014 at 4:36 PM, Eoghan Glynn  wrote:
>
>>
>>
>>
>> > Alex reported the bug against setuptools
>> > (
>> https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation
>> )
>> > if you want to track progress.
>>
>>
>> Thanks Doug,
>>
>> In the meantime, I'm wondering do we have any way of insulating
>> ourselves against breakages like this?
>>
>> (along the lines of a version-cap that we'd apply in the global
>> requirements.txt, for dependencies pulled in that way).
>>
>> Cheers,
>> Eoghan
>>
>>
>> > Doug
>> >
>> > On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova 
>> wrote:
>> > > Folks, o/
>> > >
>> > > I did not find the appropriate discussion in the ML, so decided to
>> start it
>> > > myself - I see that new setuptools release seems to break at least
>> some of
>> > > the OpenStack gates and even more.
>> > >
>> > > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514
>> > >
>> > > It hits Tempest, Ceilometer and Keystoneclient at least due to the
>> > > discussion in the bug.
>> > >
>> > > Some of the variants were discussed in the #openstack-infra channel,
>> but I
>> > > see no solution found.
>> > >
>> > > Do we have idea how to fix it?
>> > >
>> > > Best regards,
>> > >
>> > > Dina Belova
>> > >
>> > > Software Engineer
>> > >
>> > > Mirantis Inc.
>> > >
>> > >
>> > > ___
>> > > 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
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

[Dina Belova]

The newest setuptools has been removed from the gate mirror - the latest
there now is 3.6 - that *might* in the gate.
We'll see if it'll help. It looks like there is first successful Neutron
job there :)

-- Dina


On Mon, Jun 2, 2014 at 4:36 PM, Eoghan Glynn  wrote:

>
>
>
> > Alex reported the bug against setuptools
> > (
> https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation
> )
> > if you want to track progress.
>
>
> Thanks Doug,
>
> In the meantime, I'm wondering do we have any way of insulating
> ourselves against breakages like this?
>
> (along the lines of a version-cap that we'd apply in the global
> requirements.txt, for dependencies pulled in that way).
>
> Cheers,
> Eoghan
>
>
> > Doug
> >
> > On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova 
> wrote:
> > > Folks, o/
> > >
> > > I did not find the appropriate discussion in the ML, so decided to
> start it
> > > myself - I see that new setuptools release seems to break at least
> some of
> > > the OpenStack gates and even more.
> > >
> > > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514
> > >
> > > It hits Tempest, Ceilometer and Keystoneclient at least due to the
> > > discussion in the bug.
> > >
> > > Some of the variants were discussed in the #openstack-infra channel,
> but I
> > > see no solution found.
> > >
> > > Do we have idea how to fix it?
> > >
> > > Best regards,
> > >
> > > Dina Belova
> > >
> > > Software Engineer
> > >
> > > Mirantis Inc.
> > >
> > >
> > > ___
> > > 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
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] New setuptools release seems to break some of the OS projects

[Dina Belova]

Doug, thanks, will track this bug's solution there.


On Mon, Jun 2, 2014 at 4:17 PM, Doug Hellmann 
wrote:

> Alex reported the bug against setuptools
> (
> https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation
> )
> if you want to track progress.
>
> Doug
>
> On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova  wrote:
> > Folks, o/
> >
> > I did not find the appropriate discussion in the ML, so decided to start
> it
> > myself - I see that new setuptools release seems to break at least some
> of
> > the OpenStack gates and even more.
> >
> > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514
> >
> > It hits Tempest, Ceilometer and Keystoneclient at least due to the
> > discussion in the bug.
> >
> > Some of the variants were discussed in the #openstack-infra channel, but
> I
> > see no solution found.
> >
> > Do we have idea how to fix it?
> >
> > Best regards,
> >
> > Dina Belova
> >
> > Software Engineer
> >
> > Mirantis Inc.
> >
> >
> > ___
> > 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
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] New setuptools release seems to break some of the OS projects

[Dina Belova]

Folks, o/

I did not find the appropriate discussion in the ML, so decided to start it
myself - I see that new setuptools release seems to break at least some of
the OpenStack gates and even more.

Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514

It hits Tempest, Ceilometer and Keystoneclient at least due to the
discussion in the bug.

Some of the variants were discussed in the #openstack-infra channel, but I
see no solution found.

Do we have idea how to fix it?

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0

[Dina Belova]

I did not look close to this concrete issue, but in the ceilometer there is
almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885
and fixes were already provided.

Will this help Blazar?

-- Dina


On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza  wrote:

> Hi Keystone developers,
>
> I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches
> are failing due to a new release in Keystone client which seems to
> regress on midleware auth.
>
> Do you have any ideas on if it's quick to fix, or shall I provide a
> patch to openstack/global-requirements.txt to only accept keystoneclient
> < 0.9.0 ?
>
> Thanks,
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Blazar] Weekly meeting Blazar (previously Climate) [Climate]

[Dina Belova]

It's still there, yes.
I'll be there with 50% activity, I guess, so I'd like to ask Pablo to be
chair on this one.


On Fri, May 30, 2014 at 12:44 PM, Sylvain Bauza  wrote:

> Hi,
>
> Due to some important changes with Climate (which is now Blazar) and as
> the team is quite changing, I want to make sure we run the weekly
> meeting today at 3pm UTC.
>
> Thanks,
> -Sylvain
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [climate] Friday Meeting

[Dina Belova]

+1


On Wed, Apr 30, 2014 at 11:41 PM, Sylvain Bauza wrote:

> Hi Dina,
>
> I forgot yesterday to mention it was my last day at Bull, so the end of
> week was off-work until Monday.
> As a corollar, I won't be able to attend Friday meeting.
>
> Let's cancel this meeting and raise topics in mailing-list if needed.
>
> -Sylvain
>
>
> 2014-04-30 19:17 GMT+02:00 Dina Belova :
>
>> Folks, o/
>>
>> I finally got my dates for the US trip, and I have to say, that I won't
>> be able to attend our closest Friday meeting as I'll be flying at this
>> moment)
>>
>> Sylvain, will you be able to hold the meeting?
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>> ___
>> 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
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [climate] Friday Meeting

[Dina Belova]

Folks, o/

I finally got my dates for the US trip, and I have to say, that I won't be
able to attend our closest Friday meeting as I'll be flying at this moment)

Sylvain, will you be able to hold the meeting?

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [ceilometer] cancelling team meeting for May 1st

[Dina Belova]

Okay, thanks! Have a nice holiday then)


On Mon, Apr 28, 2014 at 5:06 PM, Eoghan Glynn  wrote:

>
>
> > Hi Folks,
> >
> > Since our French, Hungarian, Chinese, Russian and Slovenian contributors
> > (geo-diversity WTF!) will all be celebrating International Workers' Day
>
> A dyslexic moment: I meant geo-diversity FTW! :)
>
> > on May 1st, let's skip the weekly meeting.
> >
> > If anything pressing comes up, let's just have an emergent discussion to
> > deal with it on Wednesday.
> >
> > Cheers,
> > Eoghan
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Meeting minutes

[Dina Belova]

I'm ok with these steps))) Abandoning is very simple - just click "Abandon"
button there ;)


On Mon, Apr 28, 2014 at 4:21 PM, Martinez, Christian <
christian.marti...@intel.com> wrote:

>  Great then!
>
> So new steps will be:
>
> · Abandon the https://review.openstack.org/#/c/89837/ (I never
> done that, so I’ll need some help on that)
>
> · Open a bp for v2 support (I can do that)
>
> · Start working on the v2 client (I can also help with that)
>
> · Anything that you guys consider necessary
>
>
>
> Is that OK for you?
>
>
>
> Thanks in advance,
>
> Christian
>
>
>
> *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com]
> *Sent:* Sunday, April 27, 2014 1:56 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Climate] Meeting minutes
>
>
>
> Agree with Dina, we should support V2 here.
>
> Sorry, I had no time for delivering a new client, but as V1 and V2 are
> quite identical, I can take this blueprint.
>
>
>
> -Sylvain
>
>
>
> 2014-04-27 17:44 GMT+02:00 Dina Belova :
>
>  Christian, variant #2 looks good to me)
>
>
>
> On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian <
> christian.marti...@intel.com> wrote:
>
>   Hello,
>
> One comment regarding
> https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud:
>
> One of Dina’s comments on the https://review.openstack.org/#/c/89833/ was
> that it is her intention to not add this functionality into v1 API.
>
> If that’s the case, then the changes I proposed for the climateclient at
> https://review.openstack.org/#/c/89837/ won’t make sense since the client
> only works with v1 API.
>
> I see a couple of options here:
>
> · Give support for v1 and change the client accordantly
>
> · Give support only on v2, and open a bp for climateclient v2
> support.
>
>
>
> Hope I make myself clear.
>
> I’ll be waiting for your feedback J
>
>
>
> Regards,
>
> Christian
>
> *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com]
> *Sent:* Friday, April 25, 2014 1:04 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [Climate] Meeting minutes
>
>
>
> Hi,
>
>
>
> Sorry again about my non-presence for 20 mins, I had an IRC
> client/connection issue.
>
> That impacted much the discussions, feel free to reply to this email with
> any concerns you didn't had time to raise on the meeting, so we could
> continue.
>
>
>
> That said, meeting minutes can be found here :
>
>
>
> (18:00:32) openstack: Minutes:
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html
> (18:00:33) openstack: Minutes (text):
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt
> (18:00:34) openstack: Log:
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html
>
>
>
> Thanks,
>
> -Sylvain
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
> ___
> 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
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Christian, variant #2 looks good to me)


On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian <
christian.marti...@intel.com> wrote:

>  Hello,
>
> One comment regarding
> https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud:
>
> One of Dina’s comments on the https://review.openstack.org/#/c/89833/ was
> that it is her intention to not add this functionality into v1 API.
>
> If that’s the case, then the changes I proposed for the climateclient at
> https://review.openstack.org/#/c/89837/ won’t make sense since the client
> only works with v1 API.
>
> I see a couple of options here:
>
> · Give support for v1 and change the client accordantly
>
> · Give support only on v2, and open a bp for climateclient v2
> support.
>
>
>
> Hope I make myself clear.
>
> I’ll be waiting for your feedback J
>
>
>
> Regards,
>
> Christian
>
> *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com]
> *Sent:* Friday, April 25, 2014 1:04 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [Climate] Meeting minutes
>
>
>
> Hi,
>
>
>
> Sorry again about my non-presence for 20 mins, I had an IRC
> client/connection issue.
>
> That impacted much the discussions, feel free to reply to this email with
> any concerns you didn't had time to raise on the meeting, so we could
> continue.
>
>
>
> That said, meeting minutes can be found here :
>
>
>
> (18:00:32) openstack: Minutes:
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html
> (18:00:33) openstack: Minutes (text):
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt
> (18:00:34) openstack: Log:
> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html
>
>
>
> Thanks,
>
> -Sylvain
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] nominating Pablo Andres Fuente for the Climate core reviewers team

[Dina Belova]

Well, as 3/4 core team members are okay with it, I'll do this)


On Thu, Apr 24, 2014 at 2:14 PM, Sylvain Bauza wrote:

> http://russellbryant.net/openstack-stats/climate-reviewers-90.txt
>
> As per the stats, +1 to this.
>
>
> 2014-04-24 12:10 GMT+02:00 Dina Belova :
>
>> I propose to add Pablo Andreas Fuente (pafuent on the IRC) to Climate
>> core team.
>>
>> He's Python contributor from Intel, and he took great part in Climate
>> development including  design suggestions and great ideas. He has been
>> quite active during the Icehouse and given his skills, interest and
>> background I suppose it'll be great to add him to the team.
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>> ___
>> 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
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] nominating Pablo Andres Fuente for the Climate core reviewers team

[Dina Belova]

I propose to add Pablo Andreas Fuente (pafuent on the IRC) to Climate core
team.

He's Python contributor from Intel, and he took great part in Climate
development including  design suggestions and great ideas. He has been
quite active during the Icehouse and given his skills, interest and
background I suppose it'll be great to add him to the team.

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] No weekly meeting today

[Dina Belova]

Folks, o/

I'm really sorry, but Sylvain and I can't attend today's meeting, that's
why it was decided not to have it.

All Climate related questions and discussions are welcome in our IRC
channel and we might discuss there all things you want to :)

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello, folks!

Our Climate meeting minutes are here :)

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-11-15.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-11-15.00.txt
Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-11-15.00.log.html


Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello stackers!

Here are our meeting minutes:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-04-15.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-04-15.01.txt
Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-04-15.01.log.html

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [climate] Energy efficiency BP

[Dina Belova]

OK, thanks for publishing it!


On Thu, Apr 3, 2014 at 6:51 PM, François Rossigneux <
francois.rossign...@inria.fr> wrote:

> Hello,
>
> I am writing a blueprint about energy efficiency:
> - Reservation aggregation to minimize the number of active physical hosts
> - Standby modes on inactive physical hosts
>
> https://blueprints.launchpad.net/climate/+spec/energy-efficiency
>
> Please feel free to comment it in the Etherpad...
> Francois
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [climate] PTL Candidacy

[Dina Belova]

Howdy, folks!

I'd like to announce my wish to continue being Climate PTL during next Juno
release cycle.

I have been working on Climate initiative since really early stages of its
development and was leading the subteam responsible for the implementation
of core Climate functionality and virtual reservations possibility. I was
chosen as a technical leader for this project about 4 months ago and would
like to continue being the one.

During previous development cycle I was really focused on making Climate
work for both original use cases and improving not only its functionality
but also a technical level, integrating with oslo.messaging and improving
documentation coverage. We had our first release created, and currently I'm
coordinating efforts of all our contributors trying to help them making
Climate better without overlaps and unnecessary actions.

For Juno release cycle I'd love to continue my Climate activities including
code reviews, release management, IRC meeting holding and coordination. As
for Climate itself I'm planning to present it on Atlanta summit and decide
its overall future with OS community, focus on implementing new resources
reservations and new flow for leases creation, not forgetting about energy
efficiency feature and Tempest testing.

My changes history [1] and reviews history [2] might be found below.

[1]
http://stackalytics.com/?release=all&metric=commits&project_type=all&module=climate&company=&user_id=dbelova
[2]
http://stackalytics.com/?release=all&metric=marks&project_type=all&module=climate&company=&user_id=dbelova

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello stackers!

Thanks for taking part in our meeting - meeting minutes are:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.txt
Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.log.html

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello stackers!

Thanks everyone who was attending our meeting :)

Meeting minutes are:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.txt
Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.log.html


Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello stackers!

Thanks everyone who took part in our meeting :)

Meeting minutes are:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.txt
Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.log.html


Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Heat). That said, we think that
> > there is need for having a global ordonancer managing resources and not
> > siloing the resources. Hence that's why we still think there is still a
> > need for a Climate Manager.
>
> What we need to dig in to is *why* do you feel it needs to be global?
>
> I'm trying to understand what you're saying here ... do you mean that
> since we're trying to get to where there's a global scheduler, that it
> makes sense there should be a central point for this, even if the API is
> through the existing compute/networking/storage APIs?
>
> If so, I think that makes sense.  However, until we actually have
> something for scheduling, I think we should look at implementing all of
> this in the services, and perhaps share some code with a Python library.
>  So, I'm thinking along the lines of ...
>
> 1) Take what Climate does today and work to integrate it into Nova,
> using as much of the existing Climate code as makes sense.  Be careful
> about coupling in Nova so that we can easily split out the right code
> into a library once we're ready to work on integration in another project.
>
> 2) In parallel, continue working on decoupling nova-scheduler from the
> rest of Nova, so that we can split it out into its own project.
>
> 3) Once the scheduler is split out, re-visit what part of reservations
> functionality belongs in the new scheduling project and what parts
> should remain in each of the projects responsible for managing resources.
>
> > Once I said that, there are different ways to plug in with the Manager,
> > our proposal is to deliver a REST API and a python client so that there
> > could be still some operator access for managing the resources if
> > needed. The other way would be to only expose an RPC interface like the
> > scheduler does at the moment but as the move to Pecan/WSME is already
> > close to be done (reviews currently in progress), that's still a good
> > opportunity for leveraging the existing bits of code.
>
> Yes, I would want to use as much of the existing code as possible.
>
> As I said above, I just think it's premature to make this its own
> project on its own, unless we're able to look at scheduling more broadly
> as its own project.
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

>
> The biggest concern seemed to be that we weren't sure whether Climate
> makes sense as an independent project or not.  We think it may make more
> sense to integrate what Climate does today into Nova directly.  More
> generally, we think reservations of resources may best belong in the
> APIs responsible for managing those resources, similar to how quota
> management for resources lives in the resource APIs.
> There is some expectation that this type of functionality will extend
> beyond Nova, but for that we could look at creating a shared library of
> code to ease implementing this sort of thing in each API that needs it.


Russel, sure. I guess we'll discuss that more carefully on summit, and I
love see that feature implemented in the best way it should be done. I
think in person discussion will help here much. I'm hoping to collect more
feedback before summit to have multiple view on this problem.

I truly agree with the fact that possibly users should not use a separate
> API for reserving resources, but that would be worth duty for the project
> itself (Nova, Cinder or even Heat). That said, we think that there is need
> for having a global ordonancer managing resources and not siloing the
> resources. Hence that's why we still think there is still a need for a
> Climate Manager.
> Once I said that, there are different ways to plug in with the Manager,
> our proposal is to deliver a REST API and a python client so that there
> could be still some operator access for managing the resources if needed.
> The other way would be to only expose an RPC interface like the scheduler
> does at the moment but as the move to Pecan/WSME is already close to be
> done (reviews currently in progress), that's still a good opportunity for
> leveraging the existing bits of code.


Sylvain, I quite agree with you.

-- Dina


On Wed, Mar 12, 2014 at 8:14 PM, Sylvain Bauza wrote:

> Hi Russell,
> Thanks for replying,
>
>
> 2014-03-12 16:46 GMT+01:00 Russell Bryant :
>
> On 03/12/2014 07:35 AM, Dina Belova wrote:
>> > Thanks TC for spending time on Blazar (ex. Climate, in process of
>> > renaming) discussion!
>> >
>> > It was decided that potentially reservation idea is interesting for OS
>> > and it'll be great to have cross-project session on ongoing Atlanta
>> > Summit and discuss future of reservation/scheduling management in
>> OpenStack.
>> >
>> > Here is link to cross-project session proposal:
>> >
>> > http://summit.openstack.org/cfp/details/45
>> >
>> > Thanks everyone and let's keep working on that idea.
>>
>> Yes, I do think it would be useful to discuss this in person.  However,
>> I don't think that was the most important feedback from the TC meeting.
>>
>> The biggest concern seemed to be that we weren't sure whether Climate
>> makes sense as an independent project or not.  We think it may make more
>> sense to integrate what Climate does today into Nova directly.  More
>> generally, we think reservations of resources may best belong in the
>> APIs responsible for managing those resources, similar to how quota
>> management for resources lives in the resource APIs.
>>
>> There is some expectation that this type of functionality will extend
>> beyond Nova, but for that we could look at creating a shared library of
>> code to ease implementing this sort of thing in each API that needs it.
>>
>
>
> That's really a good question, so maybe I could give some feedback on how
> we deal with the existing use-cases.
> About the possible integration with Nova, that's already something we did
> for the virtual instances use-case, thanks to an API extension responsible
> for checking if a scheduler hint called 'reservation' was spent, and if so,
> take use of the python-climateclient package to send a request to Climate.
>
> I truly agree with the fact that possibly users should not use a separate
> API for reserving resources, but that would be worth duty for the project
> itself (Nova, Cinder or even Heat). That said, we think that there is need
> for having a global ordonancer managing resources and not siloing the
> resources. Hence that's why we still think there is still a need for a
> Climate Manager.
>
> Once I said that, there are different ways to plug in with the Manager,
> our proposal is to deliver a REST API and a python client so that there
> could be still some operator access for managing the resources if needed.
> The other way would be to only expose an RPC interface like the scheduler
> does at the moment but as the move to Pecan/WSME is already close to be
> done (reviews cu

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Thanks TC for spending time on Blazar (ex. Climate, in process of renaming)
discussion!

It was decided that potentially reservation idea is interesting for OS and
it'll be great to have cross-project session on ongoing Atlanta Summit and
discuss future of reservation/scheduling management in OpenStack.

Here is link to cross-project session proposal:

http://summit.openstack.org/cfp/details/45

Thanks everyone and let's keep working on that idea.

Dina


On Fri, Mar 7, 2014 at 12:56 PM, Thierry Carrez wrote:

> Dina Belova wrote:
> > I'd like to request Climate project review for incubation. Here is
> > official incubation application:
> >
> > https://wiki.openstack.org/wiki/Climate/Incubation
>
> After watching this thread a bit, it looks like this is more a
> preemptive "where fo I fit" advice request than a formal incubation
> request.
>
> These are interesting questions, and useful answers to projects. We (the
> TC) may need an avenue for projects to request such feedback without
> necessarily engaging in a formal incubation request...
>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] New name voting results (round #2)

[Dina Belova]

Hello everyone!

I've closed round #2 of new name choosing voting for Climate:

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e2f53ce1b331590f

*Blazar* is the most popular variant, heh :)

1. *Blazar*  (Not defeated in any contest vs. another choice)2. Forecast,
loses to Blazar by 6-53. Prophecy, loses to Forecast by 6-34. Reserva,
loses to Prophecy by 5-45. Cast, loses to Reserva by 7-4
I remind you, that we needed new name because of some PyPi and readthedocs
repos issues + trademark possible issues :)

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Hello, OS folks!

Thanks everyone for taking part in our weekly meeting :)

Meeting minutes are:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.txt

Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.log.html

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Sylvain, I love your idea. As you said, that should be designed, but for
the first sight your proposal looks quite nice.


On Thu, Mar 6, 2014 at 3:11 PM, Sylvain Bauza wrote:

> Hi Thierry,
>
>
> 2014-03-06 11:46 GMT+01:00 Thierry Carrez :
>
> Dina Belova wrote:
>> >> Would Climate also be usable to support functionality like Spot
>> >> Instances ? "Schedule when spot price falls under X" ?
>> >
>> > Really good question. Personally I think that Climate might help
>> > implementing this feature, but probably it's not the main thing that
>> > will work there.
>> >
>> > Here are my concerns about it. Spot instances require way of counting
>> > instance price:
>> > [...]
>>
>> Not necessarily. It's a question of whether Climate would handle only
>> "schedule at" (a given date), or more generally "schedule when" (a
>> certain event happens, with date just being one event type). You can
>> depend on some external system setting spot prices, or any other
>> information, and climate rules that would watch regularly that external
>> information to decide if it's time to run resources or not. I don't
>> think it should be Climate's responsibility to specifically maintain
>> spot price, everyone can come up with their own rules.
>>
>>
>
> I can't agree more on this. The goal of Climate is to provide some formal
> contract agreement in betwen an user and the Reservation service, for
> ensuring that the order will be placed and served correctly (with regards
> to quotas and capacity). Of course, what we call 'user' doesn't formally
> tend to be a 'real' user.
> About spot instances use-case, I don't pretend to design it, but I could
> easily imagine that a call to Nova for booting an instance would place an
> order to Climate with a specific type of contract (what we began to call
> 'best-effort' and which needs to be implemented yet) where notifications
> for acquitting the order would come from Ceilometer (for instance). If no
> notifications come to Climate, the lease would not be honored.
>
> See https://wiki.openstack.org/wiki/Climate#Lease_types_.28concepts.29 for
> best-effort definition of a lease.
>
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Thierry, hello.


> Anne Gentle wrote:

> > It feels like it should be part of a scheduler or reservation program

> > but we don't have one today. We also don't have a workflow, planning, or

> > capacity management program, all of which these use cases could fall
under.

> >

> > (I should know this but) What are the options when a program doesn't

> > exist already? Am I actually struggling with a scope expansion beyond

> > infrastructure definitions? I'd like some more discussion by next week's

> > TC meeting.

>

> When a project files for incubation and covers a new scope, they also

> file for a new program to go with it.


Yes, we've prepared 'Resource Reservation' program - but it seems to me,
that now we should reexamine it due to idea of common program for Gantt and
Climate, and, probably, Mistral (as Anne said >>> We also don't have a
workflow, planning, or capacity management program, all of which these use
cases could fall under.  <<<)


> Dina Belova wrote:

> > I think your idea is really interesting. I mean, that thought "Gantt -

> > where to schedule, Climate - when to schedule" is quite understandable

> > and good looking.

>

> Would Climate also be usable to support functionality like Spot

> Instances ? "Schedule when spot price falls under X" ?


Really good question. Personally I think that Climate might help
implementing this feature, but probably it's not the main thing that will
work there.


Here are my concerns about it. Spot instances require way of counting
instance price:


* that might be done by *online* counting of free capacity. If so, that's
something that might be managed by billing service - price counting due to
current load. In this case I can imagine hardly how lease service might
help - that will be only some approximate capacity planning help in future

* there is other way - if every instance in cloud will be reserved via
Climate (so there will be full planning). If so, Climate will know for sure
what and when will be running. And price will be some priority stuff there
- due to it not started leases will be rescheduled. Like if capacity load
in moment X is Y and user gives price Z for some VM and it's more than
minimal price counted for that X moment, his VM will be leased for X. If
not, place for VM will be found later.


It were some quick  thoughts about this idea, I'm pretty sure there might
be some other variants about it.


Thanks

Dina


On Wed, Mar 5, 2014 at 7:35 PM, Thierry Carrez wrote:

> Dina Belova wrote:
> > I think your idea is really interesting. I mean, that thought "Gantt -
> > where to schedule, Climate - when to schedule" is quite understandable
> > and good looking.
>
> Would Climate also be usable to support functionality like Spot
> Instances ? "Schedule when spot price falls under X" ?
>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

; each service should support natively.
> * Reserved Volume: Not sure how that works.
> * Virtual Private Cloud.  It would be great to see OpenStack support a
> hardware isolated virtual private cloud, but not sure what the best
> way to implement that is.
> * Capacity Planning. Sure, but it would be nice to see a more fleshed
> out story for it.
>
>
> It would be nice to see more of these use cases discussed.
>
>
> On Mon, Mar 3, 2014 at 11:16 AM, Joe Gordon  wrote:
> > On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague  wrote:
> >> On 03/03/2014 01:35 PM, Joe Gordon wrote:
> >>> On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter 
> wrote:
> >>>> On 03/03/14 12:32, Joe Gordon wrote:
> >>>>>>
> >>>>>>> - if you're reserving resources far before you'll need them, it'll
> be
> >>>>>>> cheaper
> >>>>>
> >>>>> Why? How does this save a provider money?
> >>>>
> >>>>
> >>>> If an operator has zero information about the level of future demand,
> they
> >>>> will have to spend a *lot* of money on excess capacity or risk
> running out.
> >>>> If an operator has perfect information about future demand, then they
> need
> >>>> spend no money on excess capacity. Everywhere in between, the amount
> of
> >>>> extra money they need to spend is a non-increasing function of the
> amount of
> >>>> information they have. QED.
> >>>
> >>> Sure. if an operator has perfect information about future demand they
> >>> won't need any excess capacity. But assuming you know some future
> >>> demand, how do you figure out how much of the future demand you know?
> >>> But sure I can see this as a potential money saver, but unclear by how
> >>> much. The Amazon model for this is a reservation is at minimum a year,
> >>> I am not sure how useful short term reservations would be in
> >>> determining future demand.
> >>
> >> There are other useful things with reservations though. In a private
> >> context the classic one is running number for close of business. Or
> >> software team that's working towards a release might want to preallocate
> >> resources for longer scale runs during a particular week.
> >
> > Why can't they pre-allocate now?
> >
> >>
> >> Reservation can really be about global policy giving some tenants more
> >> priority in getting resources than others (because you pre-allocate
> them).
> >>
> >> I also know that with a lot of the HPC teams using OpenStack, this is a
> >> fundamental part of scheduling. Not just the when, but the how long.
> >> Having systems automatically get reaped after a certain amount of time
> >> is something they very much want.
> >
> > Agreed, I think this should either be part of Nova or Heat directly.
> >
> >>
> >> So I think the general idea have merrit. I just think we need to make
> >> sure it integrates well with the rest of OpenStack, which I believe
> >> means strong coupling to the scheduler.
> >>
> >> -Sean
> >>
> >> --
> >> Sean Dague
> >> Samsung Research America
> >> s...@dague.net / sean.da...@samsung.com
> >> http://dague.net
> >>
> >>
> >> ___
> >> 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
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Nova gate currently broken

[Dina Belova]

Michael, hello.

I've found this issue some days ago with oslo.messaging master (and now
it's released, as you see..)

The main problem here is: *Error importing module
nova.openstack.common.sslutils: duplicate option: ca_file*

That's because of https://review.openstack.org/#/c/71997/ merged to
oslo.messaging - and now released

Author changed opts not only in oslo.messaging files, but also in
openstack.compute one - sslutils - and we've got duplicate option error
with openstack.common.sslutils in nova.

As I discussed that with Doug Hellmann (and understood him), on
#openstack-dev some days ago, he proposed to merge the same fix to
oslo-incubator and then update all other projects using oslo.messaging.

Here is the fix: https://review.openstack.org/#/c/76300/ to oslo.incubator

Although, I suppose now your idea with simply not using last oslo.messaging
release will be much quicker due to code freeze.

On Tue, Mar 4, 2014 at 2:38 PM, Michael Still  wrote:

> Hi.
>
> You might have noticed that the nova gate is currently broken. I
> believe this is related to an oslo.messaging release today, and have
> proposed a fix at https://review.openstack.org/#/c/77844/
>
> Cheers,
> Michael
>
> --
> Rackspace Australia
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Oh, Sylvain, you were first :)

I have just small things to add here: Joe, resource usage planning is great
feature, that, I believe, is not supported in OS services now. Resource
planning will allow cloud providers to react on future picks of loads,
because they *will know* about that. As Zane said, otherwise you need to
spend much money keeping much extra capacity in common pool, or have real
risks to run out of resources.

Everything else was described by Sylvain, I guess :)

-- Dina


On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza wrote:

> Hi Joe,
>
>
> 2014-03-03 18:32 GMT+01:00 Joe Gordon :
>
>
>>
>> This sounds like something that belongs in nova, Phil Day has an
>> elegant solution for this:
>> https://blueprints.launchpad.net/nova/+spec/whole-host-allocation
>>
>>
> This blueprint has already been addressed by Climate team, and we
> discussed about this with Phil directly.
> This blueprint has been recently abandoned by its author and Phil is
> trying to focus on dedicated instances instead.
>
> As we identified this blueprint as non-supported yet, we implemented its
> logic directly within Climate. That said, don't confuse 2 different things
> :
>  - the locking process for isolating one compute node to a single tenant :
> that should be done in Nova
>  - the timetable for scheduling hosts and electing which ones are
> appropriate : that must be done in Climate (and in the future, should use
> Gantt as external scheduler for electing from a pool of available hosts on
> that timeframe)
>
> Don't let me say that the resource isolation must be done within Climate :
> I'm definitely conviced that this logic should be done on the resource
> project level (Nova, Cinder, Neutron) and Climate should use their
> respective CLI for asking isolation.
> The overall layer for defining what will available when, and what are the
> dependencies in between projects, still relies on a shared service, which
> is Climate.
>
>
>>
>> Heat?
>>
>> I spin up dev instances all the time and have never had this problem
>> in part because if I forget my quota will remind me.
>>
>>
> How do you ensure that you won't run out of resources when firing up an
> instance in 3 days ? How can you guaranttee that in the next couple of
> days, you would be able to create a volume with 50GB of space ?
>
> I'm not saying that the current Climate implementation does all the work.
> I'm just saying it's duty of Climate to look at Quality of Service aspects
> for resource allocation (or say SLA if you prefer)
>
>
>>
>> Why does he need to reserve them in the future? When he wants an
>> instance can't he just get one? As Sean said, what happens if someone
>> has no free quota when the reservation kicks in?
>>
>>
> That's the role of the resource plugin to manage capacity and ensure
> everything can be charged correctly.
> Regarding the virtual instances plugin logic, that's something that can be
> improved, but consider the thing that the instance is already created but
> not spawned when the lease is created, so that the quota is decreased from
> one.
>
> With the compute hosts plugin, we manage availability thanks to a resource
> planner, based on a fixed set of resources (enrolled compute hosts within
> Climate), so we can almost guaranttee this (minus the hosts outages we
> could get, of course)
>
>
>
>>
>> How is this different from 'nova boot?' When nova boot finishes the VM
>> is completely ready to be used
>>
>>
>
> Nova boot directly creates the VM when the command is issued, while the
> proposal here is to defer the booting itself only at the lease start (which
> can happen far later than when the lease is created)
>
>
>>
>> > - if you're reserving resources far before you'll need them, it'll be
>> > cheaper
>>
>> Why? How does this save a provider money?
>>
>>
> From a cloud operator point of view, don't you think it's way preferrable
> to get feedback for future capacity needs ?
> Don't you feel it would be interesting for him to propose a business model
> like this ?
>
>
>
>
>>
>> "Reserved Instances provide a capacity reservation so that you can
>> have confidence in your ability to launch the number of instances you
>> have reserved when you need them."
>> https://aws.amazon.com/ec2/purchasing-options/reserved-instances/
>>
>> Amazon does guarantee the resource will be available.  Amazon can
>> guarantee the resource because they can terminate spot instances at
>> wil

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Joe, as said, Amazon reservation is not like implemented in Climate - and
really we had different original use cases to have the same result. Amazon
instances reservations do not guarantee that instance will be provided to
user, as in Climate we started implemented reservations possibilities with
this guarantee (due to original use cases). That's why we're mostly
speaking about time-based resource management now, not billing purposes.

Lease creation request now contains the following steps: create lease ->
start lease -> end lease
Also there are user notifications, but they are connected with lease
start/end events, so that's not some separated stuff now.

Although, if we'll implement one more second step like 'allocate resources'
- that will allow us to have reservations with no guarantees, and that will
make Climate possibilities containing Amazon use case.

Thanks


On Mon, Mar 3, 2014 at 9:04 PM, Joe Gordon  wrote:

> On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle  wrote:
> >
> >
> > On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon 
> wrote:
> >>
> >> On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza 
> >> wrote:
> >> > Hi Joe,
> >> >
> >> > Thanks for your reply, I'll try to further explain.
> >> >
> >> >
> >> > Le 03/03/2014 05:33, Joe Gordon a écrit :
> >> >
> >> >> On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova 
> >> >> wrote:
> >> >>>
> >> >>> Hello, folks!
> >> >>>
> >> >>> I'd like to request Climate project review for incubation. Here is
> >> >>> official
> >> >>> incubation application:
> >> >>>
> >> >>> https://wiki.openstack.org/wiki/Climate/Incubation
> >> >>
> >> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed
> >> >> Description' from the link above, and it states Climate is trying to
> >> >> solve two uses cases (and the more generalized cases of those).
> >> >>
> >> >> 1) Compute host reservation (when user with admin privileges can
> >> >> reserve hardware resources that are dedicated to the sole use of a
> >> >> tenant)
> >> >> 2) Virtual machine (instance) reservation (when user may ask
> >> >> reservation service to provide him working VM not necessary now, but
> >> >> also in the future)
> >> >
> >> > Climate is born from the idea of dedicating compute resources to a
> >> > single
> >> > tenant or user for a certain amount of time, which was not yet
> >> > implemented
> >> > in Nova: how as an user, can I ask Nova for one compute host with
> >> > certain
> >> > specs to be exclusively allocated to my needs, starting in 2 days and
> >> > being
> >> > freed in 5 days ?
> >> >
> >> > Albeit the exclusive resource lock can be managed on the Nova side,
> >> > there is
> >> > currently no possibilities to ensure resource planner.
> >> >
> >> > Of course, and that's why we think Climate can also stand by its own
> >> > Program, resource reservation can be seen on a more general way : what
> >> > about
> >> > reserving an Heat stack with its volume and network nested resources ?
> >> >
> >> >
> >> >> You want to support being able to reserve an instance in the future.
> >> >> As a cloud operator how do I take advantage of that information? As a
> >> >> cloud consumer, what is the benefit? Today OpenStack supports both
> >> >> uses cases, except it can't request an Instance for the future.
> >> >
> >> >
> >> > Again, that's not only reserving an instance, but rather a complex mix
> >> > of
> >> > resources. At the moment, we do provide way to reserve virtual
> instances
> >> > by
> >> > shelving/unshelving them at the lease start, but we also give
> >> > possibility to
> >> > provide dedicated compute hosts. Considering it, the logic of resource
> >> > allocation and scheduling (take the word as resource planner, in order
> >> > not
> >> > to confuse with Nova's scheduler concerns) and capacity planning is
> too
> >> > big
> >> > to fail under the Compute's umbrella, as it has been agreed within the
> >> > Summit talks and periodical threads.

Re: [openstack-dev] [openstack-tc] Climate Incubation Application

[Dina Belova]

Hello, Sean

I think your idea is really interesting. I mean, that thought "Gantt -
where to schedule, Climate - when to schedule" is quite understandable and
good looking.

These two 'directions' of scheduling process really look like fitting into
one Program - probably it should be named "Resource Allocation and
Reclaiming" or something like this. My only idea is that even Gantt +
Climate will be under this new Program umbrella, they can't be one project
only because these functionalities may become wider - and projects may
become too big to manage them as one. I mean, that future energy efficiency
+ probable billing interest for Climate is not 'horizontal' scheduling
really, and that's why our scopes lay in different areas.

High level idea "Gantt is for placing objects, Climate is for planning
them" looks good IMHO.

And, as said, Compute program is not about Climate, because we're
implementing volumes reservation for 0.2.0 release, and that will be
pushing us away from the Compute Pr.

Anyway, it's an interesting discussion and I'm looking forward to
continuing it.

Thanks!


On Mon, Mar 3, 2014 at 7:04 PM, Sean Dague  wrote:

> On 03/02/2014 02:32 PM, Dina Belova wrote:
> > Hello, folks!
> >
> > I'd like to request Climate project review for incubation. Here is
> > official incubation application:
> >
> > https://wiki.openstack.org/wiki/Climate/Incubation
> >
> > Additionally due to the project scope and the roadmap, we don't see any
> > currently existing OpenStack program that fits Climate. So we've
> > prepared new program request too:
> >
> > https://wiki.openstack.org/wiki/Climate/Program
> >
> > TL;DR
> >
> > Our team is working on providing OpenStack with resource reservation
> > opportunity in time-based manner, including close integration with all
> > other OS projects.
> >
> > As Climate initiative is targeting to provide not only compute resources
> > revervation, but also volumes, network resources, storage nodes
> > reservation opportunity, we consider it is not about being a part of
> > some existing OpenStack program.
> >
> > This initiative needs to become a part of completely new Resource
> > Reservation Program, that aims to implement time-based cloud resource
> > management.
>
> At a high level this feels like this should be part of scheduling.
> Scheduling might include resources you want right now, but it could
> include resources you want in the future. It also makes sense for
> scheduling to include deadlines, so that resources are reclaimed when
> they expire. Especially given quota implications of asking for resources
> now vs. resources that a user has reserved in the future. What happens
> when a user has used all their quota in the present, and a future
> reservation comes up for access?
>
> Scheduling today is under compute. The proposal to pull Gantt out still
> leaves it in the compute program. So I would naturally assume this
> should live under compute. I could understand that if this & Gantt
> emerged together and wanted to create a "Resource Allocation" program,
> that might make sense. But I think that's way down the road.
>
> However, that's just a quick look at this. I think it will be an
> interesting discussion in how this effort moves forward.
>
> -Sean
>
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> http://dague.net
>
>
> ___
> OpenStack-TC mailing list
> openstack...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

 have
them, they will be much cheaper than guaranteed ones.

Thanks
Dina


On Mon, Mar 3, 2014 at 6:27 PM, Anne Gentle  wrote:

>
>
> On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon  wrote:
>
>> On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza 
>> wrote:
>> > Hi Joe,
>> >
>> > Thanks for your reply, I'll try to further explain.
>> >
>> >
>> > Le 03/03/2014 05:33, Joe Gordon a écrit :
>> >
>> >> On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova 
>> wrote:
>> >>>
>> >>> Hello, folks!
>> >>>
>> >>> I'd like to request Climate project review for incubation. Here is
>> >>> official
>> >>> incubation application:
>> >>>
>> >>> https://wiki.openstack.org/wiki/Climate/Incubation
>> >>
>> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed
>> >> Description' from the link above, and it states Climate is trying to
>> >> solve two uses cases (and the more generalized cases of those).
>> >>
>> >> 1) Compute host reservation (when user with admin privileges can
>> >> reserve hardware resources that are dedicated to the sole use of a
>> >> tenant)
>> >> 2) Virtual machine (instance) reservation (when user may ask
>> >> reservation service to provide him working VM not necessary now, but
>> >> also in the future)
>> >
>> > Climate is born from the idea of dedicating compute resources to a
>> single
>> > tenant or user for a certain amount of time, which was not yet
>> implemented
>> > in Nova: how as an user, can I ask Nova for one compute host with
>> certain
>> > specs to be exclusively allocated to my needs, starting in 2 days and
>> being
>> > freed in 5 days ?
>> >
>> > Albeit the exclusive resource lock can be managed on the Nova side,
>> there is
>> > currently no possibilities to ensure resource planner.
>> >
>> > Of course, and that's why we think Climate can also stand by its own
>> > Program, resource reservation can be seen on a more general way : what
>> about
>> > reserving an Heat stack with its volume and network nested resources ?
>> >
>> >
>> >> You want to support being able to reserve an instance in the future.
>> >> As a cloud operator how do I take advantage of that information? As a
>> >> cloud consumer, what is the benefit? Today OpenStack supports both
>> >> uses cases, except it can't request an Instance for the future.
>> >
>> >
>> > Again, that's not only reserving an instance, but rather a complex mix
>> of
>> > resources. At the moment, we do provide way to reserve virtual
>> instances by
>> > shelving/unshelving them at the lease start, but we also give
>> possibility to
>> > provide dedicated compute hosts. Considering it, the logic of resource
>> > allocation and scheduling (take the word as resource planner, in order
>> not
>> > to confuse with Nova's scheduler concerns) and capacity planning is too
>> big
>> > to fail under the Compute's umbrella, as it has been agreed within the
>> > Summit talks and periodical threads.
>>
>> Capacity planning not falling under Compute's umbrella is news to me,
>> are you referring to Gantt and scheduling in general? Perhaps I don't
>> fully understand the full extent of what 'capacity planning' actually
>> is.
>>
>> >
>> > From the user standpoint, there are multiple ways to integrate with
>> Climate
>> > in order to get Capacity Planning capabilities. As you perhaps noticed,
>> the
>> > workflow for reserving resources is different from one plugin to
>> another.
>> > Either we say the user has to explicitly request for dedicated resources
>> > (using Climate CLI, see dedicate compute hosts allocation), or we
>> implicitly
>> > integrate resource allocation from the Nova API (see virtual instance
>> API
>> > hook).
>>
>> I don't see how Climate reserves resources is relevant to the user.
>>
>> >
>> > We truly accept our current implementation as a first prototype, where
>> > scheduling decisions can be improved (possibly thanks to some tight
>> > integration with a future external Scheduler aaS, hello Gantt), where
>> also
>> > resource isolation and preemption must also be integrate

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

Hello Joe, Thierry, Sylvain.

Joe, I pretty agree with Sylvain in how he had described Climate idea. I
hope it is more understandable now.

Thierry, thanks for answering. I'm sorry I did not send this email before :)

Thanks
Dina


On Mon, Mar 3, 2014 at 4:42 PM, Sylvain Bauza wrote:

> Hi Joe,
>
> Thanks for your reply, I'll try to further explain.
>
>
> Le 03/03/2014 05:33, Joe Gordon a écrit :
>
>  On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova 
>> wrote:
>>
>>> Hello, folks!
>>>
>>> I'd like to request Climate project review for incubation. Here is
>>> official
>>> incubation application:
>>>
>>> https://wiki.openstack.org/wiki/Climate/Incubation
>>>
>> I'm unclear on what Climate is trying to solve. I read the 'Detailed
>> Description' from the link above, and it states Climate is trying to
>> solve two uses cases (and the more generalized cases of those).
>>
>> 1) Compute host reservation (when user with admin privileges can
>> reserve hardware resources that are dedicated to the sole use of a
>> tenant)
>> 2) Virtual machine (instance) reservation (when user may ask
>> reservation service to provide him working VM not necessary now, but
>> also in the future)
>>
> Climate is born from the idea of dedicating compute resources to a single
> tenant or user for a certain amount of time, which was not yet implemented
> in Nova: how as an user, can I ask Nova for one compute host with certain
> specs to be exclusively allocated to my needs, starting in 2 days and being
> freed in 5 days ?
>
> Albeit the exclusive resource lock can be managed on the Nova side, there
> is currently no possibilities to ensure resource planner.
>
> Of course, and that's why we think Climate can also stand by its own
> Program, resource reservation can be seen on a more general way : what
> about reserving an Heat stack with its volume and network nested resources ?
>
>
>  You want to support being able to reserve an instance in the future.
>> As a cloud operator how do I take advantage of that information? As a
>> cloud consumer, what is the benefit? Today OpenStack supports both
>> uses cases, except it can't request an Instance for the future.
>>
>
> Again, that's not only reserving an instance, but rather a complex mix of
> resources. At the moment, we do provide way to reserve virtual instances by
> shelving/unshelving them at the lease start, but we also give possibility
> to provide dedicated compute hosts. Considering it, the logic of resource
> allocation and scheduling (take the word as resource planner, in order not
> to confuse with Nova's scheduler concerns) and capacity planning is too big
> to fail under the Compute's umbrella, as it has been agreed within the
> Summit talks and periodical threads.
>
> From the user standpoint, there are multiple ways to integrate with
> Climate in order to get Capacity Planning capabilities. As you perhaps
> noticed, the workflow for reserving resources is different from one plugin
> to another. Either we say the user has to explicitly request for dedicated
> resources (using Climate CLI, see dedicate compute hosts allocation), or we
> implicitly integrate resource allocation from the Nova API (see virtual
> instance API hook).
>
> We truly accept our current implementation as a first prototype, where
> scheduling decisions can be improved (possibly thanks to some tight
> integration with a future external Scheduler aaS, hello Gantt), where also
> resource isolation and preemption must also be integrated with subprojects
> (we're currently seeing how to provision Cinder volumes and Neutron routers
> and nets), but anyway we still think there is a (IMHO big) room for
> resource and capacity management on its own project.
>
> Hoping it's clearer now,
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] Climate Incubation Application

[Dina Belova]

Hello, folks!

I'd like to request Climate project review for incubation. Here is official
incubation application:

https://wiki.openstack.org/wiki/Climate/Incubation

Additionally due to the project scope and the roadmap, we don't see any
currently existing OpenStack program that fits Climate. So we've prepared
new program request too:

https://wiki.openstack.org/wiki/Climate/Program

TL;DR

Our team is working on providing OpenStack with resource reservation
opportunity in time-based manner, including close integration with all
other OS projects.

As Climate initiative is targeting to provide not only compute resources
revervation, but also volumes, network resources, storage nodes reservation
opportunity, we consider it is not about being a part of some existing
OpenStack program.

This initiative needs to become a part of completely new Resource
Reservation Program, that aims to implement time-based cloud resource
management.

Thanks!

Best regards,

Dina Belova

Climate Technical Lead

Software Engineer

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

[openstack-dev] [Climate] New name voting results (round #1)

[Dina Belova]

Hello everyone :)

Just closed first round of voting to choose 5 best candidates for being new
name of our "Climate" project. We needed to do that, because of some
trademark issues and because there are already existing 'climate' repos on
PyPi, readthedocs, etc.

Here is link to the results of this first round :)

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_30ac36e0aa791e09

Most popular candidates are:

1. *Forecast*  (Not defeated in any contest vs. another choice)2. *Reserva*,
loses to Forecast by 7-43. *Prophecy*, loses to Reserva by 7-34. *Blazar*,
loses to Prophecy by 7-65. *Cast*, loses to Blazar by 8-4
Thanks and have a nice day!

P.S. round #2 will be started on Monday.

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Thanks for taking part in our meeting :)

Meeting minutes are:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.txt

Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.log.html


Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

Only problem here is that we'll remove admin climate user in the future and
will use only trusts, so how you'll get needed info?

I think we may keep info unduplicated only in one case: use trust from
admin user who marked tenant as reservable to get needed info later.

In this case storing needed info in keystone is ok for me.

Dina

On Thursday, February 27, 2014, Sanchez, Cristian A <
cristian.a.sanc...@intel.com> wrote:

> I don't think that duplicating the information in Climate is a really good
> idea. Why don't let Keystone manage the tenant dates information? Moreover,
> we can also add that to Horizon.
> Then, during Lease creations, Climate should query Keystone to get the
> tenant dates.
>
> What do you think?
>
> From: Dina Belova  dbel...@mirantis.com >>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Date: miércoles, 26 de febrero de 2014 02:10
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
> Also we have to mention Adam's letter - cause now he said he loves to see
> start/end date functionality in keystone.
>
> If so, we may store this info in Keystone - but anyway, I suppose that it
> might be somehow duplicated in Climate not to process one more request to
> Keystone when it'll be needed. I still have no clear idea how that will be
> looking speaking about user rights.
>
> Now we're using trusts + special admin user. We'll get rid of this special
> user in future. But to work with projects we still need admin's rights.
>
> Any ideas?
>
> On Wednesday, February 26, 2014, Dina Belova 
> 
> <mailto:dbel...@mirantis.com >> wrote:
> Don't think it's needed in this case. We may store this info in Climate
> not to intersect with Keystone without serious reasons.
>
> On Wednesday, February 26, 2014, Sanchez, Cristian A <
> cristian.a.sanc...@intel.com  cristian.a.sanc...@intel.com ');>> wrote:
> One question to clarify: the project will be marked as reservable by
> calling Keystone API (from Climate) to store that info in the project extra
> specs in Keystone DB.
> Is this correct?
>
> From: Sylvain Bauza  sylvain.ba...@gmail.com >>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Date: martes, 25 de febrero de 2014 17:55
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
>
>
>
> 2014-02-25 17:42 GMT+01:00 Dina Belova 
> <mailto:dbel...@mirantis.com >>:
>
> >>> I think it should be a Climate "policy" (be careful, the name is
> confusing) : if admin wants to grant any new project for reservations, he
> should place a call to Climate. That's up to Climate-Nova (ie. Nova
> extension) to query Climate in order to see if project has been granted or
> not.
>
> Now I think that it'll be better, yes.
> I see some workflow like:
>
> 1) Mark project as reservable in Climate
> 2) When some resource is created (like Nova instance) it should be checked
> (in the API extensions, for example) via Climate if project is reservable.
> If is, and there is no special reservation flags passed, it should be used
> default_reservation stuff for this instance
>
> Sylvain, is that ira you're talking about?
>
>
> tl;dr : Yes, let's define/create a new endpoint for the need.
>
> That's exactly what I'm thinking, Climate should manage reservations on
> its own (including any new model) and projects using it for reserving
> resources should place a call to it in order to get some information.
>
> -Sylvain
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

Also we have to mention Adam's letter - cause now he said he loves to see
start/end date functionality in keystone.

If so, we may store this info in Keystone - but anyway, I suppose that it
might be somehow duplicated in Climate not to process one more request to
Keystone when it'll be needed. I still have no clear idea how that will be
looking speaking about user rights.

Now we're using trusts + special admin user. We'll get rid of this special
user in future. But to work with projects we still need admin's rights.

Any ideas?

On Wednesday, February 26, 2014, Dina Belova  wrote:

> Don't think it's needed in this case. We may store this info in Climate
> not to intersect with Keystone without serious reasons.
>
> On Wednesday, February 26, 2014, Sanchez, Cristian A <
> cristian.a.sanc...@intel.com>
> wrote:
>
>> One question to clarify: the project will be marked as reservable by
>> calling Keystone API (from Climate) to store that info in the project extra
>> specs in Keystone DB.
>> Is this correct?
>>
>> From: Sylvain Bauza > sylvain.ba...@gmail.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Date: martes, 25 de febrero de 2014 17:55
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>>
>>
>>
>>
>> 2014-02-25 17:42 GMT+01:00 Dina Belova > dbel...@mirantis.com>>:
>>
>> >>> I think it should be a Climate "policy" (be careful, the name is
>> confusing) : if admin wants to grant any new project for reservations, he
>> should place a call to Climate. That's up to Climate-Nova (ie. Nova
>> extension) to query Climate in order to see if project has been granted or
>> not.
>>
>> Now I think that it'll be better, yes.
>> I see some workflow like:
>>
>> 1) Mark project as reservable in Climate
>> 2) When some resource is created (like Nova instance) it should be
>> checked (in the API extensions, for example) via Climate if project is
>> reservable. If is, and there is no special reservation flags passed, it
>> should be used default_reservation stuff for this instance
>>
>> Sylvain, is that ira you're talking about?
>>
>>
>> tl;dr : Yes, let's define/create a new endpoint for the need.
>>
>> That's exactly what I'm thinking, Climate should manage reservations on
>> its own (including any new model) and projects using it for reserving
>> resources should place a call to it in order to get some information.
>>
>> -Sylvain
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>

-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

Don't think it's needed in this case. We may store this info in Climate not
to intersect with Keystone without serious reasons.

On Wednesday, February 26, 2014, Sanchez, Cristian A <
cristian.a.sanc...@intel.com> wrote:

> One question to clarify: the project will be marked as reservable by
> calling Keystone API (from Climate) to store that info in the project extra
> specs in Keystone DB.
> Is this correct?
>
> From: Sylvain Bauza  sylvain.ba...@gmail.com >>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Date: martes, 25 de febrero de 2014 17:55
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org  openstack-dev@lists.openstack.org >>
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
>
>
>
> 2014-02-25 17:42 GMT+01:00 Dina Belova 
> <mailto:dbel...@mirantis.com >>:
>
> >>> I think it should be a Climate "policy" (be careful, the name is
> confusing) : if admin wants to grant any new project for reservations, he
> should place a call to Climate. That's up to Climate-Nova (ie. Nova
> extension) to query Climate in order to see if project has been granted or
> not.
>
> Now I think that it'll be better, yes.
> I see some workflow like:
>
> 1) Mark project as reservable in Climate
> 2) When some resource is created (like Nova instance) it should be checked
> (in the API extensions, for example) via Climate if project is reservable.
> If is, and there is no special reservation flags passed, it should be used
> default_reservation stuff for this instance
>
> Sylvain, is that ira you're talking about?
>
>
> tl;dr : Yes, let's define/create a new endpoint for the need.
>
> That's exactly what I'm thinking, Climate should manage reservations on
> its own (including any new model) and projects using it for reserving
> resources should place a call to it in order to get some information.
>
> -Sylvain
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

Ok, so

>>> I'm just asking why we should hack Keystone workflow by adding an hook,
like we did for Nova. From my POV, that's not worth it.

Idea was about some extra specs, that will be processed by Climate anyway.
Keystone will know nothing about reservations or smth.

>>> I think it should be a Climate "policy" (be careful, the name is
confusing) : if admin wants to grant any new project for reservations, he
should place a call to Climate. That's up to Climate-Nova (ie. Nova
extension) to query Climate in order to see if project has been granted or
not.

Now I think that it'll be better, yes.
I see some workflow like:

1) Mark project as reservable in Climate
2) When some resource is created (like Nova instance) it should be checked
(in the API extensions, for example) via Climate if project is reservable.
If is, and there is no special reservation flags passed, it should be used
default_reservation stuff for this instance

Sylvain, is that ira you're talking about?

Dina



On Tue, Feb 25, 2014 at 7:53 PM, Sylvain Bauza wrote:

>
>
>
> 2014-02-25 16:25 GMT+01:00 Dina Belova :
>
>  Why should it require to be part of Keystone to hook up on Climate ?
>>
>>
>> Sorry, can't get your point.
>>
>>
>
> I'm just asking why we should hack Keystone workflow by adding an hook,
> like we did for Nova. From my POV, that's not worth it.
>
>
>
>> Provided we consider some projects as 'reservable', we could say this
>>> should be a Climate API endpoint like CRUD /project/ and up to the admin
>>> responsability to populate it.
>>> If we say that new projects should automatically be 'reservable', that's
>>> only policy from Climate to whiteboard these.
>>
>>
>> So you propose to make some API requests to Climate (like for hosts) and
>> mark some already existing projects as reserved. But how we'll automate
>> process of some resource reservation belonging to that tenant? Or do you
>> propose still to add some checkings to, for example, climate-nova
>> extensions to check this somehow there?
>>
>> Thanks
>>
>>
>
> I think it should be a Climate "policy" (be careful, the name is
> confusing) : if admin wants to grant any new project for reservations, he
> should place a call to Climate. That's up to Climate-Nova (ie. Nova
> extension) to query Climate in order to see if project has been granted or
> not.
>
> Conceptually, this 'reservation' information is tied to Climate and should
> not be present within the projects.
>
> -Sylvain
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

>
> Why should it require to be part of Keystone to hook up on Climate ?


Sorry, can't get your point.

Provided we consider some projects as 'reservable', we could say this
> should be a Climate API endpoint like CRUD /project/ and up to the admin
> responsability to populate it.
> If we say that new projects should automatically be 'reservable', that's
> only policy from Climate to whiteboard these.


So you propose to make some API requests to Climate (like for hosts) and
mark some already existing projects as reserved. But how we'll automate
process of some resource reservation belonging to that tenant? Or do you
propose still to add some checkings to, for example, climate-nova
extensions to check this somehow there?

Thanks


On Tue, Feb 25, 2014 at 6:48 PM, Sylvain Bauza wrote:

>
>
>
> 2014-02-25 15:38 GMT+01:00 Dina Belova :
>
> I guess that's simple and that's why nice solution for this problem.
>>
>> So you propose to implement that feature in following way:
>> 1) mark project as 'reservable' during its creation in extras specs
>> 2) add some more logic to reservable resources creation/reservation. Like
>> adding one more checking in instance creation request. Currently we're
>> checking hints in request, you propose to check project extra info and
>> if project is 'reservable' you'll use smth like default_reservation stuff
>> for instances
>>
>> Although it looks ok (because of no changes to Keystone/Nova/etc. core
>> code), I have some question about this solution:
>> - info about project should be given only to admins, really. But all
>> these VMs will be booted by simple users, am I right? In this case you'll
>> have no possibility to get info about project and to process checking.
>>
>> Do you have some ideas about how to solve this problem?
>>
>> Dina
>>
>>
>
> Why should it require to be part of Keystone to hook up on Climate ?
> Provided we consider some projects as 'reservable', we could say this
> should be a Climate API endpoint like CRUD /project/ and up to the admin
> responsability to populate it.
>
> If we say that new projects should automatically be 'reservable', that's
> only policy from Climate to whiteboard these.
>
> Provided a VM is booted by a single end-user, that would still be
> Climate's responsability to verify that the user's tenant has been
> previously granted.
>
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

I guess that's simple and that's why nice solution for this problem.

So you propose to implement that feature in following way:
1) mark project as 'reservable' during its creation in extras specs
2) add some more logic to reservable resources creation/reservation. Like
adding one more checking in instance creation request. Currently we're
checking hints in request, you propose to check project extra info and
if project is 'reservable' you'll use smth like default_reservation stuff
for instances

Although it looks ok (because of no changes to Keystone/Nova/etc. core
code), I have some question about this solution:
- info about project should be given only to admins, really. But all these
VMs will be booted by simple users, am I right? In this case you'll have no
possibility to get info about project and to process checking.

Do you have some ideas about how to solve this problem?

Dina



On Tue, Feb 25, 2014 at 6:22 PM, Martinez, Christian <
christian.marti...@intel.com> wrote:

> Yeah.. That could be a good approach.
> Just add some extra info to the tenant creation.. Then, on climate nova,
> when a resource is created, check by the tenant id if that tenant has a
> "lease param" (or smth like that). If it does, then act accordingly..
> Is that make sense? Dina, Sylvain ??
>
>
> -Original Message-
> From: Sanchez, Cristian A [mailto:cristian.a.sanc...@intel.com]
> Sent: Thursday, February 20, 2014 4:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
> I agree with Bauza that the main purpose of Climate is to reserve
> resources, and in the case of keystone it should reserve tenant, users,
> domains, etc.
>
> So, it could be possible that climate is not the module in which the
> tenant "lease" information should be saved. As stated in the use case, the
> only purpose of this BP is to allow the creation of tenants with start and
> end dates. Then when creating resources in that tenant (like VMs) climate
> could take "lease" information from the tenant itself and create actual
> leases for the VMs.
>
> Any thoughts of this?
>
> From: Sylvain Bauza  sylvain.ba...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org
> >>
> Date: jueves, 20 de febrero de 2014 15:57
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org
> >>
> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design
>
>
>
>
> 2014-02-20 19:32 GMT+01:00 Dina Belova  dbel...@mirantis.com>>:
> Sylvain, as I understand in BP description, Christian is about not exactly
> reserving tenants itself like we actually do with VMs/hosts - it's just
> naming for that. I think he is about two moments:
>
> 1) mark some tenants as "needed to be reserved" - speaking about resources
> assigned to it
> 2) reserve these resources via Climate (VMs for first approximation)
>
>
> Well, I understood your BP, that's Christian's message which was a bit
> misunderstanding.
> Speaking of marking a tenant as "reserved" would then mean that it does
> have kind of priority vs. another tenant. But again, at said, how could you
> ensure at the marking (ie. at lease creation) that Climate can honor
> contracts with resources that haven't been explicitely defined ?
>
> I suppose Christian is speaking now about hacking tenants creation process
> to mark them as "needed to be reserved" (1st step).
>
>
> Again, a lease is mutually and exclusively linked with explicit resources.
> If you say "create a lease, for the love" without speaking of what, I don't
> see the interest in Climate, unless I missed something obvious.
>
> -Sylvain
> Christian, correct me if I'm wrong, please Waiting for your comments
>
>
> On Thu, Feb 20, 2014 at 10:06 PM, Sylvain Bauza  <mailto:sylvain.ba...@gmail.com>> wrote:
> Hi Christian,
>
> 2014-02-20 18:10 GMT+01:00 Martinez, Christian <
> christian.marti...@intel.com<mailto:christian.marti...@intel.com>>:
>
> Hello all,
> I'm working in the following BP:
> https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept,
> in which the idea is to have the possibility to create "special" tenants
> that have a lease for all of its associated resources.
>
> The BP is in discussing phase and we were having conversations on IRC
> about what approa

Re: [openstack-dev] [Keystone] Tenant expiration dates

[Dina Belova]

Cristian, hello

I believe that should not be done in such direct way, really.
Why not using project.extra field in DB to store this info? Is that not
appropriate for your ideas or there will be problems with there
implementing using extras?

Thanks,
Dina


On Mon, Feb 24, 2014 at 5:25 PM, Sanchez, Cristian A <
cristian.a.sanc...@intel.com> wrote:

> Hi,
> I'm thinking about creating a blueprint to allow the creating of tenants
> defining start-date and end-date of that tenant. These dates will define a
> time window in which the tenant is considered 'enabled' and auth tokens
> will be given only when current time is between those dates.
> This can be particularly useful for projects like Climate where resources
> are reserved. And any resource (like VMs) created for a tenant will have
> the same expiration dates as the tenant.
>
> Do you think this is something that can be added to Keystone?
>
> Thanks
>
> Cristian
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Thanks everyone who was on our meeting :)
Meeting minutes are here:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.txt

Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.log.html


Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Climate] Lease by tenants feature design

[Dina Belova]

Sylvain, as I understand in BP description, Christian is about not exactly
reserving tenants itself like we actually do with VMs/hosts - it's just
naming for that. I think he is about two moments:

1) mark some tenants as "needed to be reserved" - speaking about resources
assigned to it
2) reserve these resources via Climate (VMs for first approximation)

I suppose Christian is speaking now about hacking tenants creation process
to mark them as "needed to be reserved" (1st step).

Christian, correct me if I'm wrong, please
Waiting for your comments


On Thu, Feb 20, 2014 at 10:06 PM, Sylvain Bauza wrote:

> Hi Christian,
>
> 2014-02-20 18:10 GMT+01:00 Martinez, Christian <
> christian.marti...@intel.com>:
>
>   Hello all,
>>
>> I'm working in the following BP:
>> https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept,
>> in which the idea is to have the possibility to create "special" tenants
>> that have a lease for all of its associated resources.
>>
>>
>>
>> The BP is in discussing phase and we were having conversations on IRC
>> about what approach should we follow.
>>
>>
>>
>
> Before speaking about implementation,  I would definitely know the
> usecases you want to design.
> What kind of resources do you want to provision using Climate ? The basic
> thing is, what is the rationale thinking about hooking tenant creation ?
> Could you please be more explicit ?
>
> At the tenant creation, Climate wouldn't have no information in terms of
> calculating the resources asked, because the resources wouldn't have been
> allocated before. So, generating a lease on top of this would be like a
> non-formal contract in between Climate and the user, accounting nothing.
>
> The main reason behind Climate is to provide SLAs for either user requests
> or projects requests, meaning that's duty of Climate to guarantee that the
> desired associated resource with the lease will be created in the future.
> Speaking of Keystone, the Keystone objects are tenants, users or domains.
> In that case, if Climate would be hooking Keystone, that would say that
> Climate ensures that the cloud will have enough capacity for creating these
> resources in the future.
>
> IMHO, that's not worth implementing it.
>
>
>  First of all, we need to add some "parameters or flags" during the
>> tenant creation so we can know that the associated resources need to have a
>> lease. Does anyone know if Keystone has similar functionality to Nova in
>> relation with Hooks/API extensions (something like the stuff mentioned on
>> http://docs.openstack.org/developer/nova/devref/hooks.html ) ? My first
>> idea is to intercept the tenant creation call (as it's being done with
>> climate-nova) and use that information to associate a lease quota to the
>> resources assigned to that tenant.
>>
>>
>
> Keystone has no way to know which resources are associated within a
> tenant, see how the middleware authentication is done here [1]
> Regarding the BP, the motivation is to possibly 'leasify' all the VMs from
> one single tenant. IIRC, that should still be duty of Nova to handle that
> workflow and send the requests to Climate.
>
> -Sylvain
>
> [1] :
> http://docs.openstack.org/developer/keystone/middlewarearchitecture.html
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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