[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 <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 <dbel...@mirantis.com> 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 <m...@us.ibm.com> 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 <dbel...@mirantis.com>
>> To:lebre.adr...@free.fr, Joshua Harlow <harlo...@fastmail.com>,
>> 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*
>> <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* <dbel...@mirantis.com>>
>> > À: "OpenStack Development Mailing List" <
>> *openstack-dev@lists.openstack.org* <openstack-dev@lists.openstack.org>>,
>> "openstack-operators"
>> > <*openstack-operat...@lists.openstack.org*
>> <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* <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*
>> <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
> <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 <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 <mkassaw...@gmail.com>
wrote:

> Why isn't this content in the openstack-manuals repository?
>
> On Sun, Aug 21, 2016 at 4:38 PM, Kaustubh Kelkar <kaustubh_kel...@live.com
> > 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 <dbel...@mirantis.com>
>> *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
>> <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 <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 <kaustubh_kel...@live.com>
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 <dbel...@mirantis.com>
> *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
> <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 <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 <m...@us.ibm.com> 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 <dbel...@mirantis.com>
> To:lebre.adr...@free.fr, Joshua Harlow <harlo...@fastmail.com>,
> Augie Mena III/Austin/IBM@IBMUS
> Cc:OpenStack Development Mailing List <openstack-dev@lists.
> openstack.org>, openstack-operators <openstack-operators@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*
> <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* <dbel...@mirantis.com>>
> > À: "OpenStack Development Mailing List" <
> *openstack-dev@lists.openstack.org* <openstack-dev@lists.openstack.org>>,
> "openstack-operators"
> > <*openstack-operat...@lists.openstack.org*
> <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* <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*
> <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 <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, <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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>



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

*Phone: 650-772-8418Email: dbel...@mirantis.com <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 <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 <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 <edgar.mag...@workday.com>
wrote:

> Indeed it will be a terrific contribution.
>
> Edgar
>
>
> On Apr 20, 2016, at 4:10 AM, Dina Belova <dbel...@mirantis.com> 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 <edgar.mag...@workday.com>
>> 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 <akamyshnik...@mirantis.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <openstack-dev@lists.openstack.org>
>>> 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
>>>>
>>>> &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]

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


-- 

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] [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 <morgan.fainb...@gmail.com>
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 <dbel...@mirantis.com>
>> 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 <m...@mattfischer.com>
>>> wrote:
>>>
>>>> On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova <dbel...@mirantis.com>
>>>> 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
&g

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 <m...@mattfischer.com> wrote:

> On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova <dbel...@mirantis.com> 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 <dbel...@mirantis.com> 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 <dbel...@mirantis.com> 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 <sba...@redhat.com> 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 <cl...@fewbar.com> 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 <cl...@fewbar.com> 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 <mrie...@linux.vnet.ibm.com>
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 <er...@skyatlas.com> 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 <mwag...@redhat.com> wrote:

>
> For clarification, this is 3-4 PM (15:00 - 16:00) UTC, correct ?.
>
> -mark
>
> - Original Message -
> > From: "Dina Belova" <dbel...@mirantis.com>
> > To: "Matt Riedemann" <mrie...@linux.vnet.ibm.com>
> > 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 <dbel...@mirantis.com>
> 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
> > >>>> benchmarkin

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 <dbel...@mirantis.com> 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-

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 <bo...@pavlovic.me> 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

[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 <sandeep.ra...@gmail.com>
wrote:

> On Tue, Sep 22, 2015 at 6:27 PM, Dina Belova <dbel...@mirantis.com> 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 <klindg...@godaddy.com>
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 <dbel...@mirantis.com>
> Date: Tuesday, September 22, 2015 7:57 AM
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
> "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 bdobre...@mirantis.com
 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 samsong8...@gmail.com 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 idegtia...@mirantis.com
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 teng...@linux.vnet.ibm.com
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 egl...@redhat.com 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 blacker1...@163.com 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 g...@live.ca 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]

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] 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 jul...@danjou.info 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]

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

Thanks,
Dina


On Wed, Aug 13, 2014 at 2:40 PM, Dina Belova dbel...@mirantis.com wrote:

 Julien, will do right now.

 Thanks
 Dina


 On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou jul...@danjou.info 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] 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 21
  18 then
  19 echo Could not find mongod command 12
  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] [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] [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 ildiko.van...@ericsson.com
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

[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] [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 dava...@gmail.com 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 dbel...@mirantis.com 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

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 doug.hellm...@dreamhost.com
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 dbel...@mirantis.com 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

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 egl...@redhat.com 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 dbel...@mirantis.com
 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]

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 dbel...@mirantis.com 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 egl...@redhat.com 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 dbel...@mirantis.com
 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] [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 sba...@redhat.com 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] [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 sba...@redhat.com 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

[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] [climate] Friday Meeting

[Dina Belova]

+1


On Wed, Apr 30, 2014 at 11:41 PM, Sylvain Bauza sylvain.ba...@gmail.comwrote:

 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 dbel...@mirantis.com:

 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

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 dbel...@mirantis.com:

  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] [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 egl...@redhat.com 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]

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

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 sylvain.ba...@gmail.comwrote:

 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 dbel...@mirantis.com:

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

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=allmetric=commitsproject_type=allmodule=climatecompany=user_id=dbelova
[2]
http://stackalytics.com/?release=allmetric=marksproject_type=allmodule=climatecompany=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

Re: [openstack-dev] Climate Incubation Application

[Dina Belova]

 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

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

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 thie...@openstack.orgwrote:

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

[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

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 thie...@openstack.orgwrote:

 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]

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 sylvain.ba...@gmail.comwrote:

 Hi Thierry,


 2014-03-06 11:46 GMT+01:00 Thierry Carrez thie...@openstack.org:

 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] 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 mi...@stillhq.com 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]

 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 joe.gord...@gmail.com wrote:
  On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague s...@dague.net wrote:
  On 03/03/2014 01:35 PM, Joe Gordon wrote:
  On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter zbit...@redhat.com
 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] 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 sylvain.ba...@bull.netwrote:

 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 dbel...@mirantis.com
 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

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 joe.gord...@gmail.com wrote:

 On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle a...@openstack.org wrote:
 
 
  On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com
 wrote:
 
  On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net
  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 dbel...@mirantis.com
   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 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

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 sylvain.ba...@gmail.comwrote:

 Hi Joe,


 2014-03-03 18:32 GMT+01:00 Joe Gordon joe.gord...@gmail.com:



 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
 will, but OpenStack doesn't have this concept today.


 That's why we think there is a need for guarantteing resource allocation
 within Openstack.
 Spot instances can be envisaged thanks to Climate as a formal contract for
 reserving resources that can be freed if needed.

 -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

[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] 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 javascript:;mailto:
 dbel...@mirantis.com javascript:;
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 Date: miércoles, 26 de febrero de 2014 02:10
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 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 
 dbel...@mirantis.comjavascript:;
 mailto:dbel...@mirantis.com javascript:; 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 javascript:;javascript:_e(%7B%7D,'cvml','
 cristian.a.sanc...@intel.com javascript:;'); 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 javascript:;mailto:
 sylvain.ba...@gmail.com javascript:;
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 Date: martes, 25 de febrero de 2014 17:55
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design




 2014-02-25 17:42 GMT+01:00 Dina Belova dbel...@mirantis.comjavascript:;
 mailto:dbel...@mirantis.com javascript:;:

  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 javascript:;
 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 javascript:;
 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.commailto:
 sylvain.ba...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.orgmailto: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.orgmailto: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.commailto:
 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 sylvain.ba...@gmail.com
 mailto:sylvain.ba...@gmail.com wrote:
 Hi Christian,

 2014-02-20 18:10 GMT+01:00 Martinez, Christian 
 christian.marti...@intel.commailto: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

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 sylvain.ba...@gmail.comwrote:




 2014-02-25 15:38 GMT+01:00 Dina Belova dbel...@mirantis.com:

 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]

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 sylvain.ba...@gmail.comwrote:




 2014-02-25 16:25 GMT+01:00 Dina Belova dbel...@mirantis.com:

  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]

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 javascript:;mailto:
 sylvain.ba...@gmail.com javascript:;
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 Date: martes, 25 de febrero de 2014 17:55
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org javascript:;mailto:
 openstack-dev@lists.openstack.org javascript:;
 Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design




 2014-02-25 17:42 GMT+01:00 Dina Belova dbel...@mirantis.comjavascript:;
 mailto:dbel...@mirantis.com javascript:;:

  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 javascript:;
 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 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.comjavascript:_e(%7B%7D,'cvml','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.commailto:
 sylvain.ba...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.orgmailto:
 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.orgmailto:
 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.commailto:
 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] [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 sylvain.ba...@gmail.comwrote:

 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

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Thanks everyone who took part in our weekly meeting. It is real pleasure to
work with you, folks!

Meeting minutes are here:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-14-15.04.html

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

Log:
http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-14-15.04.log.html

Thanks!


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-incubator] update.py copies more modules than expected

[Dina Belova]

May we use smth like:

module=notifier.api

only to copy needed for middleware notifier?


On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella 
bucce...@linux.vnet.ibm.com wrote:

 On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote:

 Hi,
 We've modified the openstack-commons.conf file for climate remove rpc and
 notifier modules. But when the update.py  is executed, the notifier and rpc
 modules are still copied. Do you know what could be wrong?
 Here you can see a log showing this situation:
 http://paste.openstack.org/show/64674/


 I think it's because you're pulling in middleware. The audit module
 imports notifier, so notifier gets dragged along as a dependency.


 -Chris



 ___
 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-incubator] update.py copies more modules than expected

[Dina Belova]

Cause it seems that such thing is not working:
http://paste.openstack.org/show/64740/
It still downloads all directories for notifier and roc, although is only
module=notifier.api in conf file.

Thanks
Dina


On Wed, Feb 12, 2014 at 11:13 PM, Dina Belova dbel...@mirantis.com wrote:

 May we use smth like:

 module=notifier.api

 only to copy needed for middleware notifier?


 On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella 
 bucce...@linux.vnet.ibm.com wrote:

 On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote:

 Hi,
 We've modified the openstack-commons.conf file for climate remove rpc
 and notifier modules. But when the update.py  is executed, the notifier and
 rpc modules are still copied. Do you know what could be wrong?
 Here you can see a log showing this situation:
 http://paste.openstack.org/show/64674/


 I think it's because you're pulling in middleware. The audit module
 imports notifier, so notifier gets dragged along as a dependency.


 -Chris



 ___
 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] [oslo-incubator] update.py copies more modules than expected

[Dina Belova]

I think variant with using oslo.messaging is nice here - cause now it looks
strange when openstack.common.middleware asks to use
openstack.common.notifier.api - and that leads to two unused really dirs
downloaded by update.py script.

Anyway, we should go further and begin using oslo.messaging where it's
possible now.

Dina


On Wed, Feb 12, 2014 at 11:34 PM, Doug Hellmann doug.hellm...@dreamhost.com
 wrote:

 The update script tries to be smart about the dependencies between
 modules, based on cross-module imports.

 It looks like the notifier middleware will need to move out of the
 incubator, or be updated to use oslo.messaging or the rpc code from the
 incubator.

 Doug


 On Wed, Feb 12, 2014 at 2:23 PM, Dina Belova dbel...@mirantis.com wrote:

 Cause it seems that such thing is not working:
 http://paste.openstack.org/show/64740/
 It still downloads all directories for notifier and roc, although is only
 module=notifier.api in conf file.

 Thanks
 Dina


 On Wed, Feb 12, 2014 at 11:13 PM, Dina Belova dbel...@mirantis.comwrote:

 May we use smth like:

 module=notifier.api

 only to copy needed for middleware notifier?


 On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella 
 bucce...@linux.vnet.ibm.com wrote:

 On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote:

 Hi,
 We've modified the openstack-commons.conf file for climate remove rpc
 and notifier modules. But when the update.py  is executed, the notifier 
 and
 rpc modules are still copied. Do you know what could be wrong?
 Here you can see a log showing this situation:
 http://paste.openstack.org/show/64674/


 I think it's because you're pulling in middleware. The audit module
 imports notifier, so notifier gets dragged along as a dependency.


 -Chris



 ___
 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



 ___
 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][Scheduler] Policy Based Scheduler and Solver Scheduler

[Dina Belova]

 Like a restaurant reservation, it would claim the resources for use by
 someone at a later date.  That way nobody else can use them.
 That way the scheduler would be responsible for determining where the
 resource should be allocated from, and getting a reservation for that
 resource.  It would not have anything to do with actually instantiating the
 instance/volume/etc.


Although I'm quite new to topic of Solver Scheduler, it seems to me that in
that case you need to look on Climate project. It aims to provide resource
reservation to OS clouds (and by resource I mean here instance/compute
host/volume/etc.)

And Climate logic is like: create lease - get resources from common pool -
do smth with them when lease start time will come.

I'll say one more time - I'm not really common with this discussion, but it
looks like Climate might help here.

Thanks
Dina


On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen
chris.frie...@windriver.comwrote:

 On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote:

 Second, there is nothing wrong with booting the instances (or

 instantiating other

 resources) as separate commands as long as we support some kind of
 reservation token.


 I'm not sure what reservation token would do, is it some kind of informing
 the scheduler that the resources would not be initiated until later ?


 Like a restaurant reservation, it would claim the resources for use by
 someone at a later date.  That way nobody else can use them.

 That way the scheduler would be responsible for determining where the
 resource should be allocated from, and getting a reservation for that
 resource.  It would not have anything to do with actually instantiating the
 instance/volume/etc.


  Let's consider a following example:

 A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one
 with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM
 left, and another with 30 GB RAM left, using Filter Scheduler's default
 RamWeigher.

 If we pass the demand as two commands, there is a chance that the small VM
 arrives first. RamWeigher will put it in the 50 GB RAM host, which will be
 reduced to 30 GB RAM. Then, when the big VM request arrives, there will be
 no space left to host it. As a result, the whole demand is failed.

 Now if we can pass the two VMs in a command, SolverScheduler can put their
 constraints all together into one big LP as follow (x_uv = 1 if VM u is
 hosted in host v, 0 if not):


 Yes.  So what I'm suggesting is that we schedule the two VMs as one call
 to the SolverScheduler.  The scheduler then gets reservations for the
 necessary resources and returns them to the caller.  This would be sort of
 like the existing Claim object in nova/compute/claims.py but generalized
 somewhat to other resources as well.

 The caller could then boot each instance separately (passing the
 appropriate reservation/claim along with the boot request).  Because the
 caller has a reservation the core code would know it doesn't need to
 schedule or allocate resources, that's already been done.

 The advantage of this is that the scheduling and resource allocation is
 done separately from the instantiation.  The instantiation API could remain
 basically as-is except for supporting an optional reservation token.


  That responses to your first point, too. If we don't mind that some VMs
 are placed and some are not (e.g. they belong to different apps), then
 it's OK to pass them to the scheduler without Instance Group. However, if
 the VMs are together (belong to an app), then we have to put them into an
 Instance Group.


 When I think of an Instance Group, I think of 
 https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension;.
   Fundamentally Instance Groups describes a runtime relationship between
 different instances.

 The scheduler doesn't necessarily care about a runtime relationship, it's
 just trying to allocate resources efficiently.

 In the above example, there is no need for those two instances to
 necessarily be part of an Instance Group--we just want to schedule them
 both at the same time to give the scheduler a better chance of fitting them
 both.

 More generally, the more instances I want to start up the more beneficial
 it can be to pass them all to the scheduler at once in order to give the
 scheduler more information.  Those instances could be parts of completely
 independent Instance Groups, or not part of an Instance Group at all...the
 scheduler can still do a better job if it has more information to work with.


 Chris

 ___
 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][Scheduler] Policy Based Scheduler and Solver Scheduler

[Dina Belova]

 This is something to explore to add in Nova, using
 a local service or external service (need to explore Climate).


I need to find out more about Climate.


Here is Climate Launchpad: https://launchpad.net/climate

That's still really young project, but I believe it'll have great future
speaking about resource reservation. So if you need some kind of
reservation logic, I also believe that should be implemented in Climate (as
it's proposed and currently implemented as Reservation-as-a-Service)

Thanks


On Tue, Feb 11, 2014 at 8:23 PM, Yathiraj Udupi (yudupi)
yud...@cisco.comwrote:

  Hi Dina,

  Thanks for note about Climate logic.  This is something that will be
 very useful, when we will have to schedule from Nova multiple instances (of
 potentially different flavors) as a single request.  If the Solver
 Scheduler, can make a request to the Climate service to reserve the
 resources soon after the placement decision has been made, then the nova
 provisioning logic can handle the resource provisioning using the climate
 reserved leases.  Regarding Solver Scheduler for your reference, just sent
 another email about this with some pointers about it.  Otherwise this is
 the blueprint -
 https://blueprints.launchpad.net/nova/+spec/solver-scheduler
 I guess this is something to explore more and see how Nova provisioning
 logic to work with Climate leases. Or this is something that already works.
  I need to find out more about Climate.

  Thanks,
 Yathi.


   On 2/11/14, 7:44 AM, Dina Belova dbel...@mirantis.com wrote:

Like a restaurant reservation, it would claim the resources for use
 by someone at a later date.  That way nobody else can use them.
 That way the scheduler would be responsible for determining where the
 resource should be allocated from, and getting a reservation for that
 resource.  It would not have anything to do with actually instantiating the
 instance/volume/etc.


  Although I'm quite new to topic of Solver Scheduler, it seems to me that
 in that case you need to look on Climate project. It aims to provide
 resource reservation to OS clouds (and by resource I mean here
 instance/compute host/volume/etc.)

  And Climate logic is like: create lease - get resources from common pool
 - do smth with them when lease start time will come.

  I'll say one more time - I'm not really common with this discussion, but
 it looks like Climate might help here.

  Thanks
 Dina


 On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen 
 chris.frie...@windriver.com wrote:

 On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote:

  Second, there is nothing wrong with booting the instances (or

 instantiating other

 resources) as separate commands as long as we support some kind of
 reservation token.


 I'm not sure what reservation token would do, is it some kind of
 informing
 the scheduler that the resources would not be initiated until later ?


  Like a restaurant reservation, it would claim the resources for use by
 someone at a later date.  That way nobody else can use them.

 That way the scheduler would be responsible for determining where the
 resource should be allocated from, and getting a reservation for that
 resource.  It would not have anything to do with actually instantiating the
 instance/volume/etc.


  Let's consider a following example:

 A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one
 with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM
 left, and another with 30 GB RAM left, using Filter Scheduler's default
 RamWeigher.

 If we pass the demand as two commands, there is a chance that the small
 VM
 arrives first. RamWeigher will put it in the 50 GB RAM host, which will
 be
 reduced to 30 GB RAM. Then, when the big VM request arrives, there will
 be
 no space left to host it. As a result, the whole demand is failed.

 Now if we can pass the two VMs in a command, SolverScheduler can put
 their
 constraints all together into one big LP as follow (x_uv = 1 if VM u is
 hosted in host v, 0 if not):


  Yes.  So what I'm suggesting is that we schedule the two VMs as one call
 to the SolverScheduler.  The scheduler then gets reservations for the
 necessary resources and returns them to the caller.  This would be sort of
 like the existing Claim object in nova/compute/claims.py but generalized
 somewhat to other resources as well.

 The caller could then boot each instance separately (passing the
 appropriate reservation/claim along with the boot request).  Because the
 caller has a reservation the core code would know it doesn't need to
 schedule or allocate resources, that's already been done.

 The advantage of this is that the scheduling and resource allocation is
 done separately from the instantiation.  The instantiation API could remain
 basically as-is except for supporting an optional reservation token.


  That responses to your first point, too. If we don't mind that some VMs
 are placed and some are not (e.g. they belong to different apps

[openstack-dev] [Climate] Meeting minutes

[Dina Belova]

Thanks everyone who took part in our weekly meeting :)

Meeting minutes are:

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

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

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


Thanks everyone :)

-- 

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] [Governance] Integrated projects and new requirements

[Dina Belova]

 I propose we do this in future TC meetings, time permitting. I
 propose we start with projects where the PTL was also elected to the TC,
 so that we give this new review's process some mileage.


+1, good idea


On Thu, Feb 6, 2014 at 5:47 PM, Thierry Carrez thie...@openstack.orgwrote:

 Dina Belova wrote:
  Perhaps we should start putting each project on the TC agenda for a
  review of its current standing.  For any gaps, I think we should set
 a
  specific timeframe for when we expect these gaps to be filled.
 
 
  Really good idea. New requirements are great, but frankly speaking not
  all currently integrated projects fit all of them.
  Will be nice to find out all gaps there and fix them asap.

 Agreed. I propose we do this in future TC meetings, time permitting. I
 propose we start with projects where the PTL was also elected to the TC,
 so that we give this new review's process some mileage.

 So.. Nova, Cinder, Neutron ?

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