[Openstack-operators] Fwd: [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Dina Belova]

Kris,

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

Cheers,
Dina

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

> Dina,
>
> Do we have a place to put things (etherpad) that we are seeing performance
> issues with?  I know we are seeing issues with CPU load under
> nova-conductor as well as some stuff with the neutron API timing out (seems
> like it never responds to the request (no log entry on the neutron side).
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Matt Van Winkle
> Date: Tuesday, September 22, 2015 at 7:46 AM
> To: Dina Belova, OpenStack Development Mailing List, "
> openstack-operators@lists.openstack.org"
> Subject: Re: [Openstack-operators] [Large Deployments Team][Performance
> Team] New informal working group suggestion
>
> Thanks, Dina!
>
> For context to the rest of the LDT folks, Dina reached out to me about
> working on this under our umbrella for now.  It made sense until we
> understand if it's a large enough thing to live as its own working group
> because most of us have various performance concerns too.  So, like Public
> Clouds, we'll have to figure out how to integrate this sub group.
>
> I suspect the time slot for Tokyo is already packed, so the work for the
> Performance subgroup may have to be informal or in other sessions, but I'll
> start working with Tom and the folks covering the session for me (since I
> won't be able to make it) on what we might be able to do.  I've also asked
> Dina to join the Oct meeting prior to the Summit so we can further discuss
> the sub team.
>
> Thanks!
> VW
>
> From: Dina Belova 
> Date: Tuesday, September 22, 2015 7:57 AM
> To: OpenStack Development Mailing List ,
> "openstack-operators@lists.openstack.org" <
> openstack-operators@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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Keystone performance issue

[Dina Belova]

Reza,

afair the number of tokens that can be processed simultaneously by Keystone
in reality is equal to the number of Keystone workers (either admin workers
or public workers, depending on the user's nature). And this number
defaults to the number of CPUs. So that is kind of default limitation, that
may influence your testing.

Btw did you evaluate Rally for the Keystone CRUD benchmarking?

Cheers,
Dina

On Tue, Oct 27, 2015 at 12:39 AM, Clint Byrum  wrote:

> Excerpts from Reza Bakhshayeshi's message of 2015-10-27 05:11:28 +0900:
> > Hi all,
> >
> > I've installed OpenStack Kilo (with help of official document) on a
> > physical HP server with following specs:
> >
> > 2 Intel(R) Xeon(R) CPU E5-2695 v2 @ 2.40GHz each 12 physical core
> (totally
> > 48 threads)
> > and 128 GB of Ram
> >
> > I'm going to benchmark keystone performance (with Apache JMeter) in order
> > to deploy OpenStack in production, but unfortunately I'm facing extremely
> > low performance.
> >
> > 1000 simultaneously token creation requests took around 45 seconds.
> (WOW!)
> > By using memcached in keystone.conf (following configuration) and
> threading
> > Keystone processes to 48, response time decreased to 18 seconds, which is
> > still too high.
> >
>
> I'd agree that 56 tokens per second isn't very high. However, it
> also isn't all that terrible given that keystone is meant to be load
> balanced, and so you can at least just throw more boxes at it without
> any complicated solution at all.
>
> Of course, that's assuming you're running with Fernet tokens. With UUID,
> which is the default if you haven't changed it, then you're pounding those
> tokens into the database, and that means you need to tune your database
> service quite a bit and provide high performance I/O (you didn't mention
> the I/O system).
>
> So, first thing I'd recommend is to switch to Liberty, as it has had some
> performance fixes for sure. But I'd also recommend evaluating the Fernet
> token provider. You will see much higher CPU usage on token validations,
> because the caching bonuses you get with UUID tokens aren't as mature in
> Fernet even in Liberty, but you should still see an overall scalability
> win by not needing to scale out your database server for heavy writes.
>
> > [cache]
> > enabled = True
> > config_prefix = cache.keystone
> > expiration_time = 300
> > backend = dogpile.cache.memcached
> > backend_argument = url:localhost:11211
> > use_key_mangler = True
> > debug_cache_backend = False
> >
> > I also increased Mariadb, "max_connections" and Apache allowed open files
> > to 4096, but they didn't help much (2 seconds!)
> >
> > Is it natural behavior? or we can optimize keystone performance more?
> > What are your suggestions?
>
> I'm pretty focused on doing exactly that right now, but we will need to
> establish some baselines and try to make sure we have tools to maintain
> the performance long-term.
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 

Best regards,

Dina Belova

Senior Software Engineer

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

[Openstack-operators] 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Informal Ops Meetup?

[Dina Belova]

Kruithof,

Grand Prince Hotel Takanawa, B1F layer - big room with lots of round tables.

Cheers,
Dina

On Fri, Oct 30, 2015 at 10:18 AM, Kruithof, Piet <
pieter.c.kruithof...@hpe.com> wrote:

> Feel like I should know thisbut where is the prince room?
>
> Sent from my Cyanogen phone
>
> On Oct 30, 2015 10:12 AM, Joe Topjian  wrote:
> We're currently in the Prince room by the projector.
>
> On Fri, Oct 30, 2015 at 10:07 AM, Edgar Magana  <mailto:edgar.mag...@workday.com>> wrote:
> Where are you meeting?
>
> Edgar
>
> From: "Kris G. Lindgren"  klindg...@godaddy.com>>
> Date: Thursday, October 29, 2015 at 6:37 AM
> To: Sam Morrison mailto:sorri...@gmail.com>>, "
> openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org>" <
> openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org>>
>
> Subject: Re: [Openstack-operators] Informal Ops Meetup?
>
> We seem to have enough interest… so meeting time will be at 10am in the
> Prince room (if we get an actual room I will send an update).
>
> Does anyone have any ideas about what they want to talk about?  I am
> pretty much open to anything.  I started:
> https://etherpad.openstack.org/p/TYO-informal-ops-meetup  for tracking of
> some ideas/time/meeting place info.
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Sam Morrison mailto:sorri...@gmail.com>>
> Date: Thursday, October 29, 2015 at 6:14 PM
> To: "openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org>" <
> openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org>>
> Subject: Re: [Openstack-operators] Informal Ops Meetup?
>
> I’ll be there, talked to Tom too and he said there may be a room we can
> use else there is plenty of space around the dev lounge to use.
>
> See you tomorrow.
>
> Sam
>
>
> On 29 Oct 2015, at 6:02 PM, Xav Paice  xavpa...@gmail.com>> wrote:
>
> Suits me :)
>
> On 29 October 2015 at 16:39, Kris G. Lindgren  <mailto:klindg...@godaddy.com>> wrote:
> Hello all,
>
> I am not sure if you guys have looked at the schedule for Friday… but its
> all working groups.  I was talking with a few other operators and the idea
> came up around doing an informal ops meetup tomorrow.  So I wanted to float
> this idea by the mailing list and see if anyone was interested in trying to
> do an informal ops meet up tomorrow.
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org OpenStack-operators@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org OpenStack-operators@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org OpenStack-operators@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] Informal Ops Meetup?

[Dina Belova]

We're on the ex-HP-lounge - 2F floor :)

Cheers,
Dina

On Fri, Oct 30, 2015 at 10:50 AM, David Medberry 
wrote:

> They all just moved up to the Prince Takanawa library. the "Prince" room
> was getting too loud.
>
> On Fri, Oct 30, 2015 at 10:38 AM, Balaji Narayanan (பாலாஜி நாராயணன்) <
> li...@balajin.net> wrote:
>
>> Hello Erik /Edgar,
>>
>> We are in the Prince room in building #44, closer to the projector screen.
>>
>> -balaji
>>
>> On 30 October 2015 at 10:08, Erik McCormick 
>> wrote:
>> > Which table are you all at?
>> >
>> > On Oct 29, 2015 11:53 PM, "Belmiro Moreira"
>> >  wrote:
>> >>
>> >> +1
>> >>
>> >> Belmiro
>> >>
>> >>
>> >>
>> >>
>> >> On Thursday, 29 October 2015, Kris G. Lindgren 
>> >> wrote:
>> >>>
>> >>> We seem to have enough interest… so meeting time will be at 10am in
>> the
>> >>> Prince room (if we get an actual room I will send an update).
>> >>>
>> >>> Does anyone have any ideas about what they want to talk about?  I am
>> >>> pretty much open to anything.  I started:
>> >>> https://etherpad.openstack.org/p/TYO-informal-ops-meetup  for
>> tracking of
>> >>> some ideas/time/meeting place info.
>> >>>
>> >>> ___
>> >>> Kris Lindgren
>> >>> Senior Linux Systems Engineer
>> >>> GoDaddy
>> >>>
>> >>> From: Sam Morrison 
>> >>> Date: Thursday, October 29, 2015 at 6:14 PM
>> >>> To: "openstack-operators@lists.openstack.org"
>> >>> 
>> >>> Subject: Re: [Openstack-operators] Informal Ops Meetup?
>> >>>
>> >>> I’ll be there, talked to Tom too and he said there may be a room we
>> can
>> >>> use else there is plenty of space around the dev lounge to use.
>> >>>
>> >>> See you tomorrow.
>> >>>
>> >>> Sam
>> >>>
>> >>>
>> >>> On 29 Oct 2015, at 6:02 PM, Xav Paice  wrote:
>> >>>
>> >>> Suits me :)
>> >>>
>> >>> On 29 October 2015 at 16:39, Kris G. Lindgren 
>> >>> wrote:
>> >>>>
>> >>>> Hello all,
>> >>>>
>> >>>> I am not sure if you guys have looked at the schedule for Friday… but
>> >>>> its all working groups.  I was talking with a few other operators
>> and the
>> >>>> idea came up around doing an informal ops meetup tomorrow.  So I
>> wanted to
>> >>>> float this idea by the mailing list and see if anyone was interested
>> in
>> >>>> trying to do an informal ops meet up tomorrow.
>> >>>>
>> >>>> ___
>> >>>> Kris Lindgren
>> >>>> Senior Linux Systems Engineer
>> >>>> GoDaddy
>> >>>>
>> >>>> ___
>> >>>> OpenStack-operators mailing list
>> >>>> OpenStack-operators@lists.openstack.org
>> >>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >>>>
>> >>>
>> >>> _______
>> >>> OpenStack-operators mailing list
>> >>> OpenStack-operators@lists.openstack.org
>> >>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >>>
>> >>>
>> >>
>> >> ___
>> >> OpenStack-operators mailing list
>> >> OpenStack-operators@lists.openstack.org
>> >>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >>
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>>
>>
>>
>> --
>> http://balajin.net/blog
>> http://flic.kr/balajijegan
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

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

[Dina Belova]

Matt,

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

Cheers,
Dina

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

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

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

[Dina Belova]

Folks,

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

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

See you tomorrow :)

Cheers,
Dina


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

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

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

[Dina Belova]

Boris,

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

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

Cheers,
Dina

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

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


-- 

Best regards,

Dina Belova

Software Engineer

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

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

[Dina Belova]

Mark,

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

Cheers,
Dina

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

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

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] FYI, local conductor mode is deprecated, pending removal in N

[Dina Belova]

Folks,

we'll take a look if we have observed this issue during MOS testing on 200
nodes lab. Sadly I do not remember this pattern being seen, although we do
not keep lots of the VMs for a long time during the synthetic tests.

Cheers,
Dina

On Fri, Nov 13, 2015 at 2:34 AM, Joshua Harlow 
wrote:

> Ok, so the following is starting to form:
>
> https://etherpad.openstack.org/p/remote-conductor-performance
>
> Hopefully we can get to the bottom of this (especially for clouds that run
> a large amount of computes in a single cell/only one cell).
>
>
> Andrew Laski wrote:
>
>> On 11/12/15 at 10:53am, Clint Byrum wrote:
>>
>>> Excerpts from Joshua Harlow's message of 2015-11-12 10:35:21 -0800:
>>>
>>>> Mike Dorman wrote:
>>>> > We do have a backlog story to investigate this more deeply, we just
>>>> have not had the time to do it yet. For us, it’s been easier/faster
>>>> to add more hardware to conductor to get over the hump temporarily.
>>>> >
>>>> > We kind of have that work earmarked for after the Liberty upgrade,
>>>> in hopes that maybe it’ll be fixed there.
>>>> >
>>>> > If anybody else has done even some trivial troubleshooting already,
>>>> it’d be great to get that info as a starting point. I.e. which
>>>> specific calls to conductor are causing the load, etc.
>>>> >
>>>> > Mike
>>>> >
>>>>
>>>> +1 I think we in the #openstack-performance channel really need to
>>>> investigate this, because it really worries me personally from hearing
>>>> many many rumors about how the remote conductor falls over. Please join
>>>> there and we can try to work through a plan to figure out what to do
>>>> about this situation. It would be great if the nova people also joined
>>>> there (because in the end, likely something in nova will need to be
>>>> fixed/changed/something else to resolve what appears to be a problem for
>>>> many operators).
>>>>
>>>>
>>> Falling over is definitely a bad sign. ;)
>>>
>>> The concept of pushing messages over a bus instead of just making local
>>> calls shouldn't result in much extra load. Perhaps we just have too many
>>> layers of unoptimized encapsulation. I have to wonder if something like
>>> protobuf would help.
>>>
>>
>> Falling over is also a very broad description and doesn't let us know
>> what the actual issue is.
>>
>>  From my experience the performance concern with conductor has been in
>> not understanding the ratio of conductor nodes to computes that are
>> necessary for our usage. Conductor doesn't add much extra load, but it
>> concentrates it on a smaller number of services. If we ran one conductor
>> per compute I suspect we would have no performance issues, but that's a
>> lot of capacity to use for this.
>>
>> I am curious what conductor/compute ratios that others are trying to
>> achieve, given equal hardware types for each, and what are the barriers
>> to this happening?
>>
>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] Mirantis Fuel Multi-Region

[Dina Belova]

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

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

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


-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

[Dina Belova]

Dear operators,

yesterday we (Performance Team) had weekly IRC meeting
,
one of the things on board to discuss was nova-conductor performance issue
 raised by
Kris Lindgren (GoDaddy).

There are still things to investigate and several suggestions about nature
of this behaviour, but one of the questions/ideas raised was "If the
conductor nodes to compute nodes ratio was ok?".

In fact I never saw any recommendations on safe enough ratio for conductor
nodes or networking nodes or whatever nodes vs compute ones.

As providing OpenStack community with understandable recommendations and
instructions on performant OpenStack cloud deployments is part of
Performance Team mission, I'm kindly asking you to share your experience on
safe cloud deployment ratio between various types of nodes you're having
right now and the possible issues you observed (as an example: discussed
GoDaddy's cloud is having 3 conductor boxes vs 250 computes in the cell,
and there was an opinion that it's simply not enough and that's it).

Thanks in advance!

Cheers,
Dina
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

[Dina Belova]

Dan,

sure, I did not mean that we should collect this information without
understanding the workloads happening on the cloud, but still this is very
interesting information to gather.

Cheers,
Dina

On Thu, Nov 19, 2015 at 1:52 AM, Dan Smith  wrote:

> > As providing OpenStack community with understandable recommendations
> > and instructions on performant OpenStack cloud deployments is part
> > of Performance Team mission, I'm kindly asking you to share your
> > experience on safe cloud deployment ratio between various types of
> > nodes you're having right now and the possible issues you observed
> > (as an example: discussed GoDaddy's cloud is having 3 conductor boxes
> > vs 250 computes in the cell, and there was an opinion that it's
> > simply not enough and that's it).
>
> That was my opinion, and it was based on an apparently incorrect
> assumption that they had a lot of things coming and going on their
> cloud. I think they've demonstrated at this point that (other issues
> aside) three is enough for them, given their environment, workload, and
> configuration.
>
> The problem with coming up with any sort of metric that will apply to
> everyone is that it's highly variable. If you have 250 compute nodes and
> never create or destroy any instances, you'll be able to get away with
> *many* fewer conductors than if you have a very active cloud. Similarly,
> during a live upgrade (or following any upgrade where we do some online
> migration of data), your conductor load will be higher than normal. Of
> course, 4-core and 96-core conductor nodes aren't equal either.
>
> So, by all means, we should gather information on what people are doing
> successfully, but keep in mind that it depends *a lot* on what sort of
> workloads the cloud is supporting.
>
> --Dan
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Performance] Where to place OpenStack performance documentation?

[Dina Belova]

Hi TC members,

I'm writing to find out where to place information that Performance Team
would like to share with community. We would like to share (and grab the
feedback on) test plans (for OpenStack itself - we can use and develop
Rally, for underlying layers like DB, MQ something else.), results of those
testing, results of various investigations, etc... I think it'll be very
useful to have some web page or whatever where we'll be able to show all
the progress.

Although Performance Team is not (yet :)) official OpenStack team, so we
cannot simply use docs.openstack.org for this purpose for just team's
needs. I had a quick chat with Anne, she suggested to use Rally as an
umbrella for this potential docs repository, but only part of the
information will be related there to Rally in fact.

So please share your opinion on what can be done here :)

Thanks in advance,
Dina
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?

[Dina Belova]

Thierry,

this can work, of course, but in that case we won't have, for instance,
ready reviewing mechanism for test plans. That is not the biggest deal I
suppose, feedback can be collected in various ways. So if wiki will be the
decision, I suppose it's ok.

Probably some operators will comment as well, as i suspect they will be one
of the groups interesting in such docs source.

Cheers
Dina

On Tue, Dec 1, 2015 at 3:43 PM, Thierry Carrez 
wrote:

> Dina Belova wrote:
> > I'm writing to find out where to place information that Performance Team
> > would like to share with community. We would like to share (and grab the
> > feedback on) test plans (for OpenStack itself - we can use and develop
> > Rally, for underlying layers like DB, MQ something else.), results of
> > those testing, results of various investigations, etc... I think it'll
> > be very useful to have some web page or whatever where we'll be able to
> > show all the progress.
> >
> > Although Performance Team is not (yet :)) official OpenStack team, so we
> > cannot simply use docs.openstack.org <http://docs.openstack.org> for
> > this purpose for just team's needs. I had a quick chat with Anne, she
> > suggested to use Rally as an umbrella for this potential docs
> > repository, but only part of the information will be related there to
> > Rally in fact.
> >
> > So please share your opinion on what can be done here :)
>
> In the past we've liberally used the wiki as a free publishing space...
> Would that be an option for you ?
>
> --
> Thierry Carrez (ttx)
>
> _______
> OpenStack-TC mailing list
> openstack...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?

[Dina Belova]

Boris,

of course that's possible in future if there will be significant results
and TC will recognise them ;)

Ok, so I believe we may use Rally as a parent here, I may add new docs
project as a child to Rally in programs.yam :)
If everybody is ok with that, let's do it.

Cheers,
Dina

On Wed, Dec 2, 2015 at 2:08 AM, Boris Pavlovic  wrote:

> Dina,
>
> Is it possible just to get for performance team official status?
>
> However, for now we can use "rally" namespace if you would like.
> Like OSprofiler is for part of Rally for now...
>
>
> Best regards,
> Boris Pavlovic
>
> On Tue, Dec 1, 2015 at 4:57 AM, Dina Belova  wrote:
>
>> Thierry,
>>
>> this can work, of course, but in that case we won't have, for instance,
>> ready reviewing mechanism for test plans. That is not the biggest deal I
>> suppose, feedback can be collected in various ways. So if wiki will be the
>> decision, I suppose it's ok.
>>
>> Probably some operators will comment as well, as i suspect they will be
>> one of the groups interesting in such docs source.
>>
>> Cheers
>> Dina
>>
>> On Tue, Dec 1, 2015 at 3:43 PM, Thierry Carrez 
>> wrote:
>>
>>> Dina Belova wrote:
>>> > I'm writing to find out where to place information that Performance
>>> Team
>>> > would like to share with community. We would like to share (and grab
>>> the
>>> > feedback on) test plans (for OpenStack itself - we can use and develop
>>> > Rally, for underlying layers like DB, MQ something else.), results of
>>> > those testing, results of various investigations, etc... I think it'll
>>> > be very useful to have some web page or whatever where we'll be able to
>>> > show all the progress.
>>> >
>>> > Although Performance Team is not (yet :)) official OpenStack team, so
>>> we
>>> > cannot simply use docs.openstack.org <http://docs.openstack.org> for
>>> > this purpose for just team's needs. I had a quick chat with Anne, she
>>> > suggested to use Rally as an umbrella for this potential docs
>>> > repository, but only part of the information will be related there to
>>> > Rally in fact.
>>> >
>>> > So please share your opinion on what can be done here :)
>>>
>>> In the past we've liberally used the wiki as a free publishing space...
>>> Would that be an option for you ?
>>>
>>> --
>>> Thierry Carrez (ttx)
>>>
>>> _______
>>> OpenStack-TC mailing list
>>> openstack...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?

[Dina Belova]

Thierry,

the main issue is to publish docs somewhere people will be easily able to
read them and leave feedback on them. So just repository with the docs is
not enough (wherever to place it, openstack/* is cool), we need a place to
publish them. And as I understand, we need some excuse to publish the docs
to the docs.openstack.org - like being now part of 'Rally' program.

Cheers,
Dina

On Wed, Dec 2, 2015 at 11:53 AM, Thierry Carrez 
wrote:

> Dina Belova wrote:
> > of course that's possible in future if there will be significant results
> > and TC will recognise them ;)
> >
> > Ok, so I believe we may use Rally as a parent here, I may add new docs
> > project as a child to Rally in programs.yam :)
> > If everybody is ok with that, let's do it.
>
> I'm fine with that option, but would like to suggest an alternative
> solution. You could set up a git repository under openstack/* while not
> being an official team (what used to be "stackforge").
>
> Your work group currently needs a git repository under Gerrit to start
> working, and it's too early (in terms of team results) to apply to be an
> official team. Just setting up the git repo under the OpenStack
> infrastructure sounds like a reasonable solution ?
>
> --
> Thierry Carrez (ttx)
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?

[Dina Belova]

Ack, thanks :)

Will send the repo creation request today.

Cheers,
Dina

On Wed, Dec 2, 2015 at 12:05 PM, Thierry Carrez 
wrote:

> Dina Belova wrote:
> > the main issue is to publish docs somewhere people will be easily able
> > to read them and leave feedback on them. So just repository with the
> > docs is not enough (wherever to place it, openstack/* is cool), we need
> > a place to publish them. And as I understand, we need some excuse to
> > publish the docs to the docs.openstack.org <http://docs.openstack.org> -
> > like being now part of 'Rally' program.
>
> OK, sounds good as a workaround solution :)
>
> --
> Thierry Carrez (ttx)
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Dina Belova]

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

Cheers, Dina

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

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

> Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> > Dear performance folks,
> >
> > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> > 16:00 UTC (also Tuesdays
> > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to
> > make them more comfortable for US guys.
> >
> > Please leave your +1 / -1 here in the email thread.
> >
> > Btw +1 from me :)
>
> +1, this makes it actually possible for me to participate. :)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

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

[Dina Belova]

Sylvain,

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

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

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


Thanks for the link ^^, will do.

Cheers,
Dina

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

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


-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Performance][Holidays] IRC meeting schedule

[Dina Belova]

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

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

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

Cheers,
Dina

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

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



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [Rally] Scale testing of openstack

[Dina Belova]

Akshay,

you may try to use
http://docs.openstack.org/developer/rally/plugin/plugin_reference.html#novaservers-boot-server-scenario
and
specify two contexts in the scenario configuration: user context for tenant
creation and network context for networks creation for these tenants.
Scenario itself will be creating the VMs and link them to the networks.

Cheers,
Dina

On Thu, Mar 10, 2016 at 6:03 PM, Akshay Kumar Sanghai <
akshaykumarsang...@gmail.com> wrote:

> Hi,
> I have a openstack setup with 1 controller node, 1 network node and 2
> compute nodes. I want to perform scale testing of the setup in the
> following manner:
>
> - Create 10 tenants
> - Create 1 router per tenant
> - Create 100 neutron networks across 10 tenants attached to the router
> - Create 500 VMs spread across 10 tenants attached to the networks
>
> Individually, I can create tenants, routers , networks ,vms , but I don't
> know how to keep them interconnected meaning the networks connecting to
> those existing router and then  VMs connecting to those networks.
>
> Please suggest me if some plugin is already available and  how to generate
> load from those VMs
>
>
> Thanks,
> Akshay Sanghai
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [Rally] Scale testing of openstack

[Dina Belova]

Hm, sounds like a bug.. + Andrey and Boris - possibly they can tell more..

On Thu, Mar 10, 2016 at 9:04 PM, Edgar Magana 
wrote:

> I am including one of our Rally expert to provide some guidance!
>
> Kyle, please provide any details that you may have in mind.
>
> Thanks,
>
> Edgar
>
> From: Akshay Kumar Sanghai 
> Date: Thursday, March 10, 2016 at 9:43 AM
> To: Dina Belova 
> Cc: openstack-operators 
> Subject: Re: [Openstack-operators] [Rally] Scale testing of openstack
>
> Hi Dina,
> Thanks for the reference.
> I edited the sample boot.json file and added the network context. It gives
> an error while executing the task: "Error BadRequest: Multiple possible
> networks found, use a Network ID to be more specific". I think because I
> have multiple networks, its asking for which network to select.
> JSON file:
> {
> "NovaServers.boot_server": [
> {
> "args": {
> "flavor": {
> "name": "m1.tiny"
> },
> "image": {
> "name": "cirros-0.3.4-x86_64"
> }
> },
> "runner": {
> "type": "constant",
> "times": 4,
> "concurrency": 2
> },
> "context": {
> "users": {
> "tenants": 3,
> "users_per_tenant": 2
>     },
> "network": {
> "networks_per_tenant": 2,
> "subnets_per_network": 1
> }
> }
> }
> ]
> }
>
> Can you please help me with this issue ?
>
> Thanks,
> Akshay
>
>
> On Thu, Mar 10, 2016 at 10:19 PM, Dina Belova 
> wrote:
>
>> Akshay,
>>
>> you may try to use
>> http://docs.openstack.org/developer/rally/plugin/plugin_reference.html#novaservers-boot-server-scenario
>>  and
>> specify two contexts in the scenario configuration: user context for tenant
>> creation and network context for networks creation for these tenants.
>> Scenario itself will be creating the VMs and link them to the networks.
>>
>> Cheers,
>> Dina
>>
>> On Thu, Mar 10, 2016 at 6:03 PM, Akshay Kumar Sanghai <
>> akshaykumarsang...@gmail.com> wrote:
>>
>>> Hi,
>>> I have a openstack setup with 1 controller node, 1 network node and 2
>>> compute nodes. I want to perform scale testing of the setup in the
>>> following manner:
>>>
>>> - Create 10 tenants
>>> - Create 1 router per tenant
>>> - Create 100 neutron networks across 10 tenants attached to the router
>>> - Create 500 VMs spread across 10 tenants attached to the networks
>>>
>>> Individually, I can create tenants, routers , networks ,vms , but I
>>> don't know how to keep them interconnected meaning the networks connecting
>>> to those existing router and then  VMs connecting to those networks.
>>>
>>> Please suggest me if some plugin is already available and  how to
>>> generate load from those VMs
>>>
>>>
>>> Thanks,
>>> Akshay Sanghai
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] [Rally] Scale testing of openstack

[Dina Belova]

Thanks Boris!

Akshay, please try the variant proposed by Boris.

Cheers,
Dina

On Thu, Mar 10, 2016 at 9:34 PM, Boris Pavlovic 
wrote:

> Dina,
>
> It's not Rally bug, however it's UX issue.
>
> There are many networks, so rally should pick one of them, to pick every
> time random network you should
> fix your sceanrio args to:
>
>
>  "NovaServers.boot_server": [
> {
> "args": {
> *"**auto_assign_nic": true*,
> "flavor": {
> "name": "m1.tiny"
> },
> "image": {
> "name": "cirros-0.3.4-x86_64"
> }
> },
>
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Mar 10, 2016 at 10:28 AM, Dina Belova 
> wrote:
>
>> Hm, sounds like a bug.. + Andrey and Boris - possibly they can tell more..
>>
>> On Thu, Mar 10, 2016 at 9:04 PM, Edgar Magana 
>> wrote:
>>
>>> I am including one of our Rally expert to provide some guidance!
>>>
>>> Kyle, please provide any details that you may have in mind.
>>>
>>> Thanks,
>>>
>>> Edgar
>>>
>>> From: Akshay Kumar Sanghai 
>>> Date: Thursday, March 10, 2016 at 9:43 AM
>>> To: Dina Belova 
>>> Cc: openstack-operators 
>>> Subject: Re: [Openstack-operators] [Rally] Scale testing of openstack
>>>
>>> Hi Dina,
>>> Thanks for the reference.
>>> I edited the sample boot.json file and added the network context. It
>>> gives an error while executing the task: "Error BadRequest: Multiple
>>> possible networks found, use a Network ID to be more specific". I think
>>> because I have multiple networks, its asking for which network to select.
>>> JSON file:
>>> {
>>> "NovaServers.boot_server": [
>>> {
>>> "args": {
>>> "flavor": {
>>> "name": "m1.tiny"
>>> },
>>> "image": {
>>> "name": "cirros-0.3.4-x86_64"
>>> }
>>> },
>>> "runner": {
>>>     "type": "constant",
>>> "times": 4,
>>> "concurrency": 2
>>> },
>>> "context": {
>>> "users": {
>>> "tenants": 3,
>>> "users_per_tenant": 2
>>> },
>>> "network": {
>>> "networks_per_tenant": 2,
>>> "subnets_per_network": 1
>>> }
>>> }
>>> }
>>> ]
>>> }
>>>
>>> Can you please help me with this issue ?
>>>
>>> Thanks,
>>> Akshay
>>>
>>>
>>> On Thu, Mar 10, 2016 at 10:19 PM, Dina Belova 
>>> wrote:
>>>
>>>> Akshay,
>>>>
>>>> you may try to use
>>>> http://docs.openstack.org/developer/rally/plugin/plugin_reference.html#novaservers-boot-server-scenario
>>>>  and
>>>> specify two contexts in the scenario configuration: user context for tenant
>>>> creation and network context for networks creation for these tenants.
>>>> Scenario itself will be creating the VMs and link them to the networks.
>>>>
>>>> Cheers,
>>>> Dina
>>>>
>>>> On Thu, Mar 10, 2016 at 6:03 PM, Akshay Kumar Sanghai <
>>>> akshaykumarsang...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>> I have a openstack setup with 1 controller node, 1 network node and 2
>>>>> compute nodes. I want to perform scale testing of the setup in the
>>>>> following manner:
>>>>>
>>>>> - Create 10 tenants
>>>>> - Create 1 router per tenant
>>>>> - Create 100 neutron networks across 10 tenants attached to the router
>>>>> - Create 500 VMs spread across 10 tenants attached to the networks
>>>>>
>>>>> Individually, I can create tenants, routers , networks ,vms , but I
>>>>> don't know how to keep them interconnected meaning the networks connecting
>>>>> to those existing router and then  VMs connecting to those networks.
>>>>>
>>>>> Please suggest me if some plugin is already available and  how to
>>>>> generate load from those VMs
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Akshay Sanghai
>>>>>
>>>>> ___
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>>
>>>> Dina Belova
>>>>
>>>> Software Engineer
>>>>
>>>> Mirantis Inc.
>>>>
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>>
>> Dina Belova
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [Openstack-operators] Allow to investigate instance actions after instance deletion

[Dina Belova]

George,

I really believe this can be processed via Ceilometer events. Events about
all actions happened to instance are coming to Ceilometer.

Cheers,
Dina

On Wed, Apr 13, 2016 at 12:23 PM, George Shuklin 
wrote:

> I filed a bug (feature request) about ability to see deleted instances
> action list: https://bugs.launchpad.net/nova/+bug/1569779
>
> Any ideas?
>
> I really want to see it like this:
>
> I filed a bug (feature request) about ability to see deleted instances
> action list: https://bugs.launchpad.net/nova/+bug/1569779
>
> Any ideas?
>
> I really want to see it like this:
>
>
> +---+--+-++
> | Action| Request_ID   | Message |
> Start_Time |
>
> +---+--+-++
> | create| req-31f61086-ce71-4e0a-9ef5-3d1bdd386043 | -   |
> 2015-05-26T12:09:54.00 |
> | reboot| req-4632c799-a83e-489c-bb04-5ed4f47705af | -   |
> 2015-05-26T14:21:53.00 |
> | stop  | req-120635d8-ef53-4237-b95a-7d15f00ab6bf | -   |
> 2015-06-01T08:46:03.00 |
> | migrate   | req-bdd680b3-06d5-48e6-868b-d3e4dc17796a | -   |
> 2015-06-01T08:48:14.00 |
> | confirmResize | req-a9af49d4-833e-404e-86ac-7d8907badd9e | -   |
> 2015-06-01T08:58:03.00 |
> | start | req-5a2f5295-8b63-4cb7-84d9-dad1c6abf053 | -   |
> 2015-06-01T08:58:20.00 |
> | delete| req----- | -   |
> 2016-04-01T00:00:00.00 |
>
> +---+--+-++
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 

Best regards,

Dina Belova

Software Engineer

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

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Hey, OpenStackers!

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

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

Please leave your comments.

Cheers,
Dina

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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

[Dina Belova]

Folks,

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

Thanks in advance!

Cheers,
Dina

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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

Adrien,

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

Cheers,
Dina

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

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



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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

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

Cheers,
Dina

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

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


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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Dina Belova]

Kaustubh,

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

Cheers,
Dina

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

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



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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Dina Belova]

Matt,

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

Cheers,
Dina

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

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


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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Performance][Meeting time] Possible meeting time change: feedback appreciated

[Dina Belova]

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

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

Cheers,
Dina

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

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



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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Performance] No Performance Team meeting today

[Dina Belova]

Folks,

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

Sorry for inconvenience.

Cheers,
Dina

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

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Performance] No meeting today

[Dina Belova]

Folks,

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

Sorry for inconvenience.

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085
*Email: dbel...@mirantis.com *
www.mirantis.com
<https://www.mirantis.com/>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators