[Openstack-operators] How to config spice in openstack instead of vnc

[hittang]

Hi,everyone
   I use fuel 8.0 deploy an openstack(Liberty) environment, the host os is 
ubuntu14.04, the default console is vnc, I want to use spice for high 
performance.  What should I do?  Is there is tutorial about installing packages 
and modify config files? Thanks for all.




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

[Openstack-operators] Howto use spice in openstack instead of vnc

[hittang]

Hi,everyone
   I use fuel 8.0 deploy an openstack(Liberty) environment, the host os is 
ubuntu14.04, the default console is vnc, I want to use spice for high 
performance.  What should I do?  Is there is tutorial about installing packages 
and modify config files? Thanks for all.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Neutron] L3 HA testing on scale

[Kosnik, Lubosz]

Great work Ann.
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

Regards,
Lubosz “diltram” Kosnik

On Apr 18, 2016, at 10:42 AM, John Schwarz 
> wrote:

This is some awesome work, Ann. It's very neat to see that all the
races we've struggled with w.r.t. the l3 scheduler has paid off. 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.

Also, we should see how to best handle of the issue Ann found (and is
tracked at https://review.openstack.org/#/c/305774/). Specifically,
reproducing this should be our goal.

John.

On Mon, Apr 18, 2016 at 5: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.

[1] - http://akamyshnikova.github.io/neutron-benchmark-results/
[2] -
https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing

Regards,
Ann Kamyshnikova
Mirantis, Inc

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




--
John Schwarz,
Red Hat.

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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Fox, Kevin M]

We've used it too to work around the lack of instance users in nova. Please 
keep it until a viable solution can be reached.

Thanks,
Kevin

From: David Medberry [openst...@medberry.net]
Sent: Monday, April 18, 2016 7:16 AM
To: Ned Rhudy
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in 
nova.conf?

Hi Ned, Jay,

We use it also and I have to agree, it's onerous to require users to add that 
functionality back in. Where was this discussed?

On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) 
> wrote:
Requiring users to remember to pass specific userdata through to their instance 
at every launch in order to replace functionality that currently works 
invisible to them would be a step backwards. It's an alternative, yes, but it's 
an alternative that adds burden to our users and is not one we would pursue.

What is the rationale for desiring to remove this functionality?

From: jaypi...@gmail.com
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in 
nova.conf?
On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
> I noticed while reading through Mitaka release notes that
> vendordata_driver has been deprecated in Mitaka
> (https://review.openstack.org/#/c/288107/) and is slated for removal at
> some point. This came as somewhat of a surprise to me - I searched
> openstack-dev for vendordata-related subject lines going back to January
> and found no discussion on the matter (IRC logs, while available on
> eavesdrop, are not trivially searchable without a little scripting to
> fetch them first, so I didn't check there yet).
>
> We at Bloomberg make heavy use of this particular feature to inject
> dynamically generated JSON into the metadata service of instances; the
> content of the JSON differs depending on the instance making the request
> to the metadata service. The functionality that adds the contents of a
> static JSON file, while remaining around, is not suitable for our use case.
>
> Please let me know if you use vendordata_driver so that I/we can present
> an organized case for why this option or equivalent functionality needs
> to remain around. The alternative is that we end up patching the
> vendordata driver directly in Nova when we move to Mitaka, which I'd
> like to avoid; as a matter of principle I would rather see more
> classloader overrides, not fewer.

Wouldn't an alternative be to use something like Chef, Puppet, Ansible,
Saltstack, etc and their associated config variable storage services
like Hiera or something similar to publish custom metadata? That way,
all you need to pass to your instance (via userdata) is a URI or
connection string and some auth details for your config storage service
and the instance can grab whatever you need.

Thoughts?
-jay

___
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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Ned Rhudy (BLOOMBERG/ 731 LEX)]

Okay, if I propose something upstream what is it expected to look like? There 
is apparently a high level of opinionation around exposed class loaders I 
wasn't aware of, and I don't think there's any one-size-fits-all solution here. 
If I suggested something like adding additional instance metadata under 
/openstack/latest/meta_data.json, that might be suitable for us as private 
cloud operators but pose security risks to public cloud operators. I don't want 
to propose something that sucks and has Bloomberg pathologies all over it but 
gets jackhammered in anyway.

From: s...@dague.net At: Apr 18 2016 10:34:24
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in 
nova.conf?

On 04/18/2016 10:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
> Requiring users to remember to pass specific userdata through to their
> instance at every launch in order to replace functionality that
> currently works invisible to them would be a step backwards. It's an
> alternative, yes, but it's an alternative that adds burden to our users
> and is not one we would pursue.
> 
> What is the rationale for desiring to remove this functionality?

The Nova team would like to remove every config option that specifies an
arbitrary out of tree class file at a function point. This has been the
sentiment for a while and we did a wave of deprecations at the end of
Mitaka to signal this more broadly, because as an arbitrary class loader
it completely impossible to even understand who might be using it and how.

These interfaces are not considered stable or contractual, so exposing
them as raw class loader is something that we want to stop doing, as
we're going to horribly break people at some point. It's fine if there
are multiple implementations for these things, however those should all
be upstream, and selected by a symbolic name CONF option.

One of the alternatives is to propose your solution upstream.

  -Sean

-- 
Sean Dague
http://dague.net

___
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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Sean Dague]

On 04/18/2016 10:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
> Requiring users to remember to pass specific userdata through to their
> instance at every launch in order to replace functionality that
> currently works invisible to them would be a step backwards. It's an
> alternative, yes, but it's an alternative that adds burden to our users
> and is not one we would pursue.
> 
> What is the rationale for desiring to remove this functionality?

The Nova team would like to remove every config option that specifies an
arbitrary out of tree class file at a function point. This has been the
sentiment for a while and we did a wave of deprecations at the end of
Mitaka to signal this more broadly, because as an arbitrary class loader
it completely impossible to even understand who might be using it and how.

These interfaces are not considered stable or contractual, so exposing
them as raw class loader is something that we want to stop doing, as
we're going to horribly break people at some point. It's fine if there
are multiple implementations for these things, however those should all
be upstream, and selected by a symbolic name CONF option.

One of the alternatives is to propose your solution upstream.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[David Medberry]

Hi Ned, Jay,

We use it also and I have to agree, it's onerous to require users to add
that functionality back in. Where was this discussed?

On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) <
erh...@bloomberg.net> wrote:

> Requiring users to remember to pass specific userdata through to their
> instance at every launch in order to replace functionality that currently
> works invisible to them would be a step backwards. It's an alternative,
> yes, but it's an alternative that adds burden to our users and is not one
> we would pursue.
>
> What is the rationale for desiring to remove this functionality?
>
> From: jaypi...@gmail.com
> Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in
> nova.conf?
>
> On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
> > I noticed while reading through Mitaka release notes that
> > vendordata_driver has been deprecated in Mitaka
> > (https://review.openstack.org/#/c/288107/) and is slated for removal at
> > some point. This came as somewhat of a surprise to me - I searched
> > openstack-dev for vendordata-related subject lines going back to January
> > and found no discussion on the matter (IRC logs, while available on
> > eavesdrop, are not trivially searchable without a little scripting to
> > fetch them first, so I didn't check there yet).
> >
> > We at Bloomberg make heavy use of this particular feature to inject
> > dynamically generated JSON into the metadata service of instances; the
> > content of the JSON differs depending on the instance making the request
> > to the metadata service. The functionality that adds the contents of a
> > static JSON file, while remaining around, is not suitable for our use
> case.
> >
> > Please let me know if you use vendordata_driver so that I/we can present
> > an organized case for why this option or equivalent functionality needs
> > to remain around. The alternative is that we end up patching the
> > vendordata driver directly in Nova when we move to Mitaka, which I'd
> > like to avoid; as a matter of principle I would rather see more
> > classloader overrides, not fewer.
>
> Wouldn't an alternative be to use something like Chef, Puppet, Ansible,
> Saltstack, etc and their associated config variable storage services
> like Hiera or something similar to publish custom metadata? That way,
> all you need to pass to your instance (via userdata) is a URI or
> connection string and some auth details for your config storage service
> and the instance can grab whatever you need.
>
> Thoughts?
> -jay
>
> ___
> 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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[David Medberry]

Ah, read the bug, we are using the default, not a custom driver. so
NEVERMIND.

On Mon, Apr 18, 2016 at 8:16 AM, David Medberry 
wrote:

> Hi Ned, Jay,
>
> We use it also and I have to agree, it's onerous to require users to add
> that functionality back in. Where was this discussed?
>
> On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) <
> erh...@bloomberg.net> wrote:
>
>> Requiring users to remember to pass specific userdata through to their
>> instance at every launch in order to replace functionality that currently
>> works invisible to them would be a step backwards. It's an alternative,
>> yes, but it's an alternative that adds burden to our users and is not one
>> we would pursue.
>>
>> What is the rationale for desiring to remove this functionality?
>>
>> From: jaypi...@gmail.com
>> Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in
>> nova.conf?
>>
>> On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
>> > I noticed while reading through Mitaka release notes that
>> > vendordata_driver has been deprecated in Mitaka
>> > (https://review.openstack.org/#/c/288107/) and is slated for removal at
>> > some point. This came as somewhat of a surprise to me - I searched
>> > openstack-dev for vendordata-related subject lines going back to January
>> > and found no discussion on the matter (IRC logs, while available on
>> > eavesdrop, are not trivially searchable without a little scripting to
>> > fetch them first, so I didn't check there yet).
>> >
>> > We at Bloomberg make heavy use of this particular feature to inject
>> > dynamically generated JSON into the metadata service of instances; the
>> > content of the JSON differs depending on the instance making the request
>> > to the metadata service. The functionality that adds the contents of a
>> > static JSON file, while remaining around, is not suitable for our use
>> case.
>> >
>> > Please let me know if you use vendordata_driver so that I/we can present
>> > an organized case for why this option or equivalent functionality needs
>> > to remain around. The alternative is that we end up patching the
>> > vendordata driver directly in Nova when we move to Mitaka, which I'd
>> > like to avoid; as a matter of principle I would rather see more
>> > classloader overrides, not fewer.
>>
>> Wouldn't an alternative be to use something like Chef, Puppet, Ansible,
>> Saltstack, etc and their associated config variable storage services
>> like Hiera or something similar to publish custom metadata? That way,
>> all you need to pass to your instance (via userdata) is a URI or
>> connection string and some auth details for your config storage service
>> and the instance can grab whatever you need.
>>
>> Thoughts?
>> -jay
>>
>> ___
>> 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] [Neutron] L3 HA testing on scale

[Anna Kamyshnikova]

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.

[1] - http://akamyshnikova.github.io/neutron-benchmark-results/
[2] -
https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing

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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Ned Rhudy (BLOOMBERG/ 731 LEX)]

Requiring users to remember to pass specific userdata through to their instance 
at every launch in order to replace functionality that currently works 
invisible to them would be a step backwards. It's an alternative, yes, but it's 
an alternative that adds burden to our users and is not one we would pursue.

What is the rationale for desiring to remove this functionality?

From: jaypi...@gmail.com 
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in 
nova.conf?

On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:
> I noticed while reading through Mitaka release notes that
> vendordata_driver has been deprecated in Mitaka
> (https://review.openstack.org/#/c/288107/) and is slated for removal at
> some point. This came as somewhat of a surprise to me - I searched
> openstack-dev for vendordata-related subject lines going back to January
> and found no discussion on the matter (IRC logs, while available on
> eavesdrop, are not trivially searchable without a little scripting to
> fetch them first, so I didn't check there yet).
>
> We at Bloomberg make heavy use of this particular feature to inject
> dynamically generated JSON into the metadata service of instances; the
> content of the JSON differs depending on the instance making the request
> to the metadata service. The functionality that adds the contents of a
> static JSON file, while remaining around, is not suitable for our use case.
>
> Please let me know if you use vendordata_driver so that I/we can present
> an organized case for why this option or equivalent functionality needs
> to remain around. The alternative is that we end up patching the
> vendordata driver directly in Nova when we move to Mitaka, which I'd
> like to avoid; as a matter of principle I would rather see more
> classloader overrides, not fewer.

Wouldn't an alternative be to use something like Chef, Puppet, Ansible, 
Saltstack, etc and their associated config variable storage services 
like Hiera or something similar to publish custom metadata? That way, 
all you need to pass to your instance (via userdata) is a URI or 
connection string and some auth details for your config storage service 
and the instance can grab whatever you need.

Thoughts?
-jay

___
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

Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Jay Pipes]

On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:

I noticed while reading through Mitaka release notes that
vendordata_driver has been deprecated in Mitaka
(https://review.openstack.org/#/c/288107/) and is slated for removal at
some point. This came as somewhat of a surprise to me - I searched
openstack-dev for vendordata-related subject lines going back to January
and found no discussion on the matter (IRC logs, while available on
eavesdrop, are not trivially searchable without a little scripting to
fetch them first, so I didn't check there yet).

We at Bloomberg make heavy use of this particular feature to inject
dynamically generated JSON into the metadata service of instances; the
content of the JSON differs depending on the instance making the request
to the metadata service. The functionality that adds the contents of a
static JSON file, while remaining around, is not suitable for our use case.

Please let me know if you use vendordata_driver so that I/we can present
an organized case for why this option or equivalent functionality needs
to remain around. The alternative is that we end up patching the
vendordata driver directly in Nova when we move to Mitaka, which I'd
like to avoid; as a matter of principle I would rather see more
classloader overrides, not fewer.


Wouldn't an alternative be to use something like Chef, Puppet, Ansible, 
Saltstack, etc and their associated config variable storage services 
like Hiera or something similar to publish custom metadata? That way, 
all you need to pass to your instance (via userdata) is a URI or 
connection string and some auth details for your config storage service 
and the instance can grab whatever you need.


Thoughts?
-jay

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

[Openstack-operators] Anyone else use vendordata_driver in nova.conf?

[Ned Rhudy (BLOOMBERG/ 731 LEX)]

I noticed while reading through Mitaka release notes that vendordata_driver has 
been deprecated in Mitaka (https://review.openstack.org/#/c/288107/) and is 
slated for removal at some point. This came as somewhat of a surprise to me - I 
searched openstack-dev for vendordata-related subject lines going back to 
January and found no discussion on the matter (IRC logs, while available on 
eavesdrop, are not trivially searchable without a little scripting to fetch 
them first, so I didn't check there yet).

We at Bloomberg make heavy use of this particular feature to inject dynamically 
generated JSON into the metadata service of instances; the content of the JSON 
differs depending on the instance making the request to the metadata service. 
The functionality that adds the contents of a static JSON file, while remaining 
around, is not suitable for our use case.

Please let me know if you use vendordata_driver so that I/we can present an 
organized case for why this option or equivalent functionality needs to remain 
around. The alternative is that we end up patching the vendordata driver 
directly in Nova when we move to Mitaka, which I'd like to avoid; as a matter 
of principle I would rather see more classloader overrides, not fewer.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Cinder usage statistics

[David Ocana]

Thanks Swami, I tried that already but was looking more for the same as
format as nova usage, with the start and end dates. I'll just have to
store that information on a regular basis I guess.

Cheers,
David

On 18/04/16 12:09, M Ranga Swami Reddy wrote:
> You can try below:
>
> cinder quota-defaults 
> cinder quota-show
> cinder quota-usage 
>
>
> Thanks
> Swami
>
> On Mon, Apr 18, 2016 at 4:17 PM, David Ocana  wrote:
>> Hi operators,
>>
>> I'm trying to come up with a yearly usage report for our tenants (mainly
>> cpu, ram and storage), and I just realized I can't find any information
>> about cinder usage.
>>
>> Is there any `nova usage` equivalent for cinder? I was googling a bit
>> before writing to the list, and I found this "cinder-volume-usage-audit"
>> script which is supposed to be run after changing some cinder.conf
>> settings, but not really sure to change this in our production environment.
>>
>> Can someone paste some output of the script? Any alternatives?
>>
>> Many thanks for your help.
>>
>> Cheers,
>> David
>>
>> ___
>> 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

Re: [Openstack-operators] Cinder usage statistics

[M Ranga Swami Reddy]

You can try below:

cinder quota-defaults 
cinder quota-show
cinder quota-usage 


Thanks
Swami

On Mon, Apr 18, 2016 at 4:17 PM, David Ocana  wrote:
> Hi operators,
>
> I'm trying to come up with a yearly usage report for our tenants (mainly
> cpu, ram and storage), and I just realized I can't find any information
> about cinder usage.
>
> Is there any `nova usage` equivalent for cinder? I was googling a bit
> before writing to the list, and I found this "cinder-volume-usage-audit"
> script which is supposed to be run after changing some cinder.conf
> settings, but not really sure to change this in our production environment.
>
> Can someone paste some output of the script? Any alternatives?
>
> Many thanks for your help.
>
> Cheers,
> David
>
> ___
> 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

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

[George Shuklin]

Yes, one more reason for upgrade.

Thank you!

On 04/13/2016 06:23 PM, Kris G. Lindgren wrote:

This spec/feature has already done on it and is committed:

https://review.openstack.org/#/q/topic:bp/os-instance-actions-read-deleted-instances

It landed in mitaka.

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Dina Belova >
Date: Wednesday, April 13, 2016 at 4:08 AM
To: George Shuklin >
Cc: "openstack-operators@lists.openstack.org 
" 
>
Subject: Re: [Openstack-operators] Allow to investigate instance 
actions after instance deletion


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