Re: [openstack-dev] [aodh] Tempest gate not working

[liusheng]

Hi,

Thanks for this mail, I also noticed that yesterday, and I am trying to 
fix  it by https://review.openstack.org/#/c/320378/


cheers,

Liusheng


在 2016/5/24 22:50, Julien Danjou 写道:

Hi,

So it turns out we tried (especially Ryota) to add Tempest support via
https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does
not actually run Tempest.

Otherwise, we would have notice something wrong in
https://review.openstack.org/#/c/318052/. As EmilienM noticed in Puppet
Aodh module, who actually runs Tempest, Aodh has a test to check the
combination alarm that now fails.

The tempest job log shows that it runs the functional tests, but not Tempest:
   
http://logs.openstack.org/52/318052/2/check/gate-aodh-dsvm-tempest-plugin-mongodb/5840d90/console.html.gz#_2016-05-19_14_01_49_072
   + ./post_test_hook.sh:main:56  :   sudo -E -H -u stack tox 
-efunctional

I've no idea how this exactly work, but if anyone has knowledge on gate
and Tempest, it'd be awesome to fix it. Or finish it, as the job are
still non-voting, I imagine nobody finished Ryota first attempt.

Cheeres,


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


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

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

[liusheng]

Another personal suggestion:

maybe we can have a weekly routine mail thread to present the things 
need to be discussed or need to be notified. The mail will also list the 
topics posted in meeting agenda and ask to Telemetry folks if  a online 
IRC meeting is necessary, if there are a very few topics or low priority 
topics, or the topics can be suitably discussed asynchronously, we can 
disuccs them in the mail thread.


any thoughts?

在 2016/3/30 19:45, Julien Danjou 写道:

Hi folks,

I've recently noticed that our way of collaborating is now mostly done
asynchronously through Gerrit and the mailing list. Which is good since
it's easy for everyone to participate. Some synchronous discussion
happens in #openstack-telemetry, which is also a good thing since it's a
handy medium for that.

On the other hand, I've noted that our IRC meetings are being less and
less useful these last weeks. Most of them only ran for a few minutes,
and were essentially gordc doing his PTL smalltalk alone.

Therefore I would suggest to schedule those meetings every 2 weeks
rather than every week as it is currently.

Thoughts?

Cheers,


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


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

Re: [openstack-dev] [telemetry] stepping down as PTL

[liusheng]

Thanks for your awsome work in last cycle Gordon!  I know you have pay a 
lot of efforts to make telemetry better, and I have learnt much from you.

--
Liu sheng

在 2016/3/12 1:33, Emilien Macchi 写道:



On Fri, Mar 11, 2016 at 11:32 AM, gordon chung > wrote:


hi folks,

as the PTL nominations are open, i just want to note that i won't be
running again as the Telemetry PTL for Newton cycle.

i've thoroughly enjoyed my time as PTL which afforded me the
opportunity
to work with and learn from some great individuals who share the same
passion to collaborate openly. i have the utmost confidence that the
projects will continue to grow and become more refined under the next
leadership.

personal thanks to everyone in Aodh, Ceilometer and Gnocchi
communities
as well as the projects that provided valuable feedback by
collaborating
with us. i thank you for sharing in the decision making so i could
spread the blame around. i also thank you for reading through terribly
written messages that make you question whether the shift keys on
all my
keyboards are broken.

cheers,


Thanks for all your work and great leadership, but also your help on 
helping other communities, like Puppet OpenStack to get puppet-aodh, 
puppet-gnocchi and puppet-ceilometer better.

--
Emilien Macchi


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


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

Re: [openstack-dev] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"

[liusheng]

Thanks for this discussion and the agreement, it sounds good, I will 
upload related changes.


--
Liu sheng

在 2016/3/7 23:42, gordon chung 写道:


On 07/03/2016 8:05 AM, Julien Danjou wrote:

On Mon, Mar 07 2016, gordon chung wrote:


shall we drop 'alarm search' nomenclature and use just 'alarm list' for
both queries (standard and complex). the concern i have right now is the
proposal is to add standard query support to 'alarm list' while complex
query support is in 'alarm search'. this is very confusing especially
because both commands use '--query' as their option input.

So you have to differentiate 2 things: the REST API and the CLI.
You can't merge both on the REST API side, because the complex query
system require to send a JSON object, so that requires a POST – whereas
listing is simply done via GET. That part we can't merge together.

Now, if your plan is to merge both command on the CLI side, I see no
objection. That's probably a good UX point.


yeah, the proposal is to merge on the client side. let's do that, since
it was same way we were leaning at the meeting[1].

1. drop aodh alarm search
2. add both --query and --complex-query support to aodh alarm list

[1]
http://eavesdrop.openstack.org/meetings/telemetry/2016/telemetry.2016-03-03-15.01.log.html

cheers,




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

[openstack-dev] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"

[liusheng]

Hi folks,
Currently, we have supported "aodh alarm list" and "aodh alarm search" 
commands to query alarms.  They both need mandatory "--type" parameter, 
and I want to drop the limitation[1]. if we agree that, the "alarm 
list"  will only used to list all alarms and don't support any query 
pamareters, it will be equal to "alarm search" command without any 
--query parameter specified.  The "alarm search" command is designed to 
support complex query which can perform almost all the filtering query, 
the complex query has been supportted in Gnocchi.  IRC meeting 
disscussions [3].


So we don't need two overlapping interfaces and want to drop one, "alarm 
list" or "alarm search" ?


i. The "alarm search" need users to post a expression in JSON format to 
perform spedific query, it is not easy to use and it is unlike a 
customary practice (I mean the most common usages of filtering query of 
other openstack projects), compare to "alarm list --filter xxx=zzz" usage.


ii. we don't have a strong requirement to support *complex* query 
scenarios of alarms, we only have alarms and alarm history records in aodh.


iii. I personally think it is enough to support filtering query with 
"--filter" which is easy to implement [2], and, we have plan to support 
pagination query in aodh.


any thoughts ?

[1] https://review.openstack.org/#/c/283958/
[2] https://review.openstack.org/#/c/283959/
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-03-03.log.html#t2016-03-03T15:21:14




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

Re: [openstack-dev] [ceilometer] Unable to get ceilometer events for instances running for demo project

[liusheng]

Hi Umar,
You can only get the events(or events without project info) belong to 
admin tenant if you run event-list command with admin project; and you 
can only get the events belong to demo tenant with event-list running 
with demo project.


--
Liu sheng
在 2016/3/1 14:00, Umar Yousaf 写道:
I have a single node configuration for devstack liberty working and I 
want to record all the *ceilometer events* like 
compute.instance.start, compute.instance.end, compute.instance.update 
etc occurred recently.
I am unable to get any event occurred for instances running for demo 
project i.e when I try *ceilometer event-list* I end up with an empty 
list but I could fortunately get all the necessary events occurred for 
instances running for admin project/tenant with the same command.
In addition to this I want to get these through python client so if 
someone could provide me with the equivalent python call, that would 
be more than handy.

Thanks in advance :)
Regard,
Umar


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


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

Re: [openstack-dev] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[liusheng]

Hi Ifat,

I meant new API to get statistcs on events data, like "statistics" API 
on samples data, that has been discussed but not implemented yet.  
because I thought you'd like to use events data about alarm changes. if 
you want to directly use the notification messages just because you want 
to be real-time notified, how about gordon's suggestion ?


Thanks
Liu sheng

在 2016/1/6 21:11, AFEK, Ifat (Ifat) 写道:

Hi,

We would like to be notified once an alarm state is changed, so we prefer using 
the message bus.
As far as I understand, ceilometer and aodh APIs do not provide immediate 
notifications. If we use the APIs, we will have to poll the data periodically 
and look for changes, and we will get them in delay. By listening to the 
message bus we can get the notifications immediately, like we do with other 
openstack components.

Is there an advantage in using the API instead?
And what do you mean by "aggregation on events data"? what kind of aggregations 
can we do?

Thanks,
Ifat.


-----Original Message-
From: liusheng [mailto:liusheng1...@126.com]
Sent: Wednesday, January 06, 2016 10:10 AM

Hi Ifat,

what way do you want to use the alarm change notifications? using
events from Ceilometer API or directly collecting the notifications
from message bus?
if we configure Ceilometer to listen the notifications from aodh, the
notifications about alarm changes will be converted to events and
stored in Ceilometer storage. if you want to use the events about alarm
changes, the same info can be queried by "alarm-history" API, may be
you want to do aggregation on events data ?

Thanks
Liu sheng

在 2016/1/5 21:37, AFEK, Ifat (Ifat) 写道:

-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Friday, December 11, 2015 10:17 PM

the original reason this was implemented i believe was to track

alarm

state changes as an event in ceilometer events. i still see this as

a

valid use case but it does duplicate some of the functionality of
alarm history.

i think the main items are to not flood the message bus with

messages

that no one is listening to. but if there is a use case for it, i'm
happy to see it remain (and improved).

you can check the patch that Liusheng referenced, but the basic
concept is as mentioned: send message when an alarm state is

changed.

Hi Gord,

We had some further discussions about this issue in Vitrage team, and

we decided we do want to use Aodh notifications about alarm state
changes.

One reason is that we want to be notified about every alarm, yet we

don't want to register our web-hook on each alarm definition
separately. The other reason is that we already listen to message bus
notifications of other openstack components (like nova), and we would
like to handle aodh notifications the same way we handle all other
openstack notifications.

We will be happy if this code remains.

Thanks,
Ifat.

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




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

Re: [openstack-dev] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[liusheng]

Hi Ifat,

what way do you want to use the alarm change notifications? using events 
from Ceilometer API or directly collecting the notifications from 
message bus?
if we configure Ceilometer to listen the notifications from aodh, the 
notifications about alarm changes will be converted to events and stored 
in Ceilometer storage. if you want to use the events about alarm 
changes, the same info can be queried by "alarm-history" API, may be you 
want to do aggregation on events data ?


Thanks
Liu sheng

在 2016/1/5 21:37, AFEK, Ifat (Ifat) 写道:

-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Friday, December 11, 2015 10:17 PM

the original reason this was implemented i believe was to track alarm
state changes as an event in ceilometer events. i still see this as a
valid use case but it does duplicate some of the functionality of alarm
history.

i think the main items are to not flood the message bus with messages
that no one is listening to. but if there is a use case for it, i'm
happy to see it remain (and improved).

you can check the patch that Liusheng referenced, but the basic concept
is as mentioned: send message when an alarm state is changed.


Hi Gord,

We had some further discussions about this issue in Vitrage team, and we 
decided we do want to use Aodh notifications about alarm state changes.

One reason is that we want to be notified about every alarm, yet we don't want 
to register our web-hook on each alarm definition separately. The other reason 
is that we already listen to message bus notifications of other openstack 
components (like nova), and we would like to handle aodh notifications the same 
way we handle all other openstack notifications.

We will be happy if this code remains.

Thanks,
Ifat.


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




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

[openstack-dev] [telemetry][aodh] The purpose of notification about alarm updating

[liusheng]

Hi folks,

Currently, a notification message will be emitted when updating an alarm 
(state transition, attribute updating, creation),  this functionality 
was added by change[1], but the change didn't describe any purpose. So I 
wonder whether there is any usage of this type of notification, we can 
get the whole details about alarm change by alarm-history API. the 
notification is implicitly ignored by default, because the 
"notification_driver"config option won't be configured by default.  if 
we enable this option in aodh.conf and enable the "store_events" in 
ceilometer.conf, this type of notifications will be stored as events. so 
maybe some users want to aggregate this with events ? what's your opinion ?


I have made a change try to deprecate this notification, see [2].

[1] https://review.openstack.org/#/c/48949/
[2] https://review.openstack.org/#/c/246727/

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

Re: [openstack-dev] [Ceilometer] [Bug#1497073]The return sample body of sample-list is different when use -m and not

[liusheng]

I don't think we need two APIs to act duplicated functionalities, the 
"sample-list -m" command actually invoke API "GET 
/V2/meters/", it is more like a meter related API, not 
sample. I personally prefer to mark the "sample-list -m" command 
deprecated and dropped in future cycle. is this reasonable ?


在 2015/11/6 6:39, gord chung 写道:
i'm sort of torn on this item. there's a general feeling that 
regarding api, nothing should be dropped so i'm hesitant to actually 
deprecate it. i think changing the data also is very dangerous when it 
comes to compatibility (even though keeping it increases inconsistency).


maybe the better solution is to document that these are different APIs 
and will return different results.


On 05/11/2015 2:30 AM, Lin Juan IX Xia wrote:

Hi,

Here is an open bug : https://bugs.launchpad.net/ceilometer/+bug/1497073

Is it a bug or not?

For the command "ceilometer sample-list --meter cpu", it calls 
"/v2/meter" API and return the OldSample objects
which return body is different from "ceilometer sample-list --query 
'meter=cpu'".
To fix this inconformity, we can deprecate the command using -m or 
fix it to return the same body as command sample-list

Best Regards,
Xia Linjuan




__
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


--
gord


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


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

[openstack-dev] [Ceilometer]heavy time cost of event-list

[liusheng]

Hi folks,

With the master Ceilometer installed, and use mysql backend, the 
event-list command met a heavy time cost.  if we have a bit large number 
of events stored, it is easy to cause event list API request timeout, 
the rally people told me that this issue has broken the 
gate-rally-dsvm-rally job, see[1], there is a bug they reported to track 
this[3]. As we konw, the admin roled uers can only query thire own 
events(the project trait value can match the project id) and events 
without project_id trait, this is implemented in event-rbac feature[2], 
before this change, the job is OK. maybe we have mistake in sql query ? 
I will dig more.


FYI, some testing infomation in my devstack environment:

root@szxbzci0007:/opt/stack/ceilometer# time ceilometer event-list |wc -l
109

real0m51.780s
user0m0.354s
sys0m0.060s


mysql> select count(*) from event;
+--+
| count(*) |
+--+
| 1540 |
+--+
1 row in set (0.00 sec)

mysql> select count(*) from trait_text;
+--+
| count(*) |
+--+
| 3097 |
+--+
1 row in set (0.01 sec)


[1] 
http://logs.openstack.org/35/222435/1/check/gate-rally-dsvm-rally/aa38d0f/rally-plot/results.html.gz#/CeilometerEvents.create_user_and_get_event/failures

[1] https://review.openstack.org/#/c/218706/
[2] https://bugs.launchpad.net/ceilometer/+bug/1494440

Best regards
Liu sheng



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

Re: [openstack-dev] [Ceilometer][Aodh] event-alarm fire policy

[liusheng]

Just a personal thought, can we add an ACK to alarm notifier? when an 
event-alarm fired, the alarm state transformed to "alarm", if 
'alarm_action' has been set, the 'alarm_action' will be triggered and 
notify. for event-alarm, a timout can be set to wait the ACK from alarm 
notifier, if the ACK recieved, reset the alarm state to OK, if timeout 
occured, set the alarm state to 'UNKNOWN'. If 'alarm_action' has not 
been set, we just need to recored the alarm state transition history.


在 2015/9/8 7:26, Zhai, Edwin 写道:

All,
Currently, event-alarm is one-shot style: don't fire again for same 
event.  But threshold-alarm is limited periodic style:

1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, 
as we reset alarm state upon insufficient data.


So maybe event-alarm should be periodic also. But I'm not sure when to 
reset the alarm state to 'UNKNOWN': after each fire, or when receive 
different event.


Fire a bug @
https://bugs.launchpad.net/aodh/+bug/1493171

Best Rgds,
Edwin

__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

[liusheng]

Hi,

Maybe the event transformer is needed in some use cases to generate new 
events or do transformations like the samples handling.  but for this 
timeout event alarming requirement,  the 'timeout' of alarms will be 
various, it not a good idea of changing event_pipeline.yaml to generate 
new events based on events timeout when we need an event-timeout alarm. 
and also, the access of event pipeline definitions to users is 
inadvisable. I personally think it'd better to implement the second 
option and based on Ryota's proposal.


Best Regards
Liusheng

在 2015/8/5 3:36, gord chung 写道:

hi Igor,

i would suggest you go with second option as i believe your 
implementation will overlap and reuse some of the functionality Ryota 
would code for his alarm spec [1]. also, since Aodh is working on an 
independent release cycle, it'll give you some more time as i don't 
think we'd be able to get this into Liberty if we went the pipeline route.


[1] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html


On 04/08/2015 10:00 AM, Igor Degtiarov wrote:

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base 
Alarming part).

In ToDo task "Сhoose the optimal way for timeout alerting implementation"
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part) 
[2]
   -- weakness of this approach is that we cannot allow user change 
config files, so only administrator will be able to set rules for 
timeout events alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms 
description like sequence of required events and timeout threshold. 
Event alarm evaluator looks thru getting events and evaluates alarm 
if even one event from required sequence isn't received in set 
"timeout".[3]


It seems that second approach is better it doesn't have restrictions 
for end user.

Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1] 
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle

[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com <http://www.mirantis.com>


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


--
--
gord


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


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

Re: [openstack-dev] [nova][security] Enable user password complexity verification

[liusheng]

Thanks for this topic, also, I think it is similar situation when 
talking about keystone users, not only the instances's password.


在 2015/6/3 17:48, 郑振宇 写道:

Hi All,

The current OpenStack does not provide user password complexity 
verification option.



When performing actions such as create instances, evacuate instances, 
rebuild instances, rescue instances and update instances' admin 
password. The complexity of user provided admin password has not been 
verified. This can cause security problems.


One solution will be adding a configuration option: 
using_complex_admin_password = True, if this option is set in 
configure file by administrator, then Nova will perform password 
complexity checks, the check standards can be set to following the IT 
industry general standard, if the provided admin password is not 
complex enough, an exception will be throw. If this option is not set 
in configure file, then the complexity check will be skipped.


When the user dose not provide admin password, generate_password() in 
utils.py is used to generate an admin password. Generate_password() 
now uses two password symbol groups: default and easier, the default 
symbol group contains numbers, upper case letters and small case 
letters. the easier symbol group contains only numbers and upper case 
letters. The generated password is not complex enough and can also 
cause security problems.


One possible solution is to add a new symbol group: 
STRONGER_PASSWORD_SYMBOLS which contains numbers, upper case letters, 
lower case letters and also special characters such as 
`~!@#$%^&*()-_=+ and space. Then adding a new option in configuration 
file: generate_strong_password = True, when this option is set, nova 
will generate password using STRONGER_PASSWORD_SYMBOLS symbol group 
and with longer password length. If this option is not set, the 
password will be generated using the default symbol group and default 
length.


AWS allows the selection of password policy to configure which kind of 
password complexity is used in the cloud. Please see:

http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingPasswordPolicies.html

And about the standard of complexity, Microsoft also have an advise 
about it, please see:

https://technet.microsoft.com/en-us/library/hh994562%28v=ws.10%29.aspx

Thanks,
BR,
Zhenyu Zheng


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


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

Re: [openstack-dev] [nova][ceilometer] FloatingIp pollster spamming n-api logs (bug 1328694)

[liusheng]

Matt, Eoghan, thanks

Firstly , sorry for the effection, the direct reason of the bug is an 
issue in nova-network scenario,
it is my mistake when commit patch 
https://review.openstack.org/#/c/81429/ to fix the bug 1262124.
with agreement of Matt's view, to dissipate the load of nova API, so it 
would better to use notification

instead of polling of floatingip or some other resources.

For this bug 1328694 the Matt's patch (has been approved)has reverted in 
ceilometer side, in nova side,
the issue should also be fixed, I have upload a patch for that 
https://review.openstack.org/#/c/99251/,

I will try to make the patch merged asap.
For the bug 1262124, I will also upload patch to fix the doc impact.


Best Regards
Liu sheng


于 2014/6/12 3:22, Eoghan Glynn 写道:

Thanks for bringing this to the list Matt, comments inline ...


tl;dr: some pervasive changes were made to nova to enable polling in
ceilometer which broke some things and in my opinion shouldn't have been
merged as a bug fix but rather should have been a blueprint.

===

The detailed version:

I opened bug 1328694 [1] yesterday and found that came back to some
changes made in ceilometer for bug 1262124 [2].

Upon further inspection, the original ceilometer bug 1262124 made some
changes to the nova os-floating-ips API extension and the database API
[3], and changes to python-novaclient [4] to enable ceilometer to use
the new API changes (basically pass --all-tenants when listing floating
IPs).

The original nova change introduced bug 1328694 which spams the nova-api
logs due to the ceilometer change [5] which does the polling, and right
now in the gate ceilometer is polling every 15 seconds.

IIUC that polling cadence in the gate is in the process of being reverted
to the out-of-the-box default of 600s.


I pushed a revert in ceilometer to fix the spam bug and a separate patch
was pushed to nova to fix the problem in the network API.

Thank you for that. The revert is just now approved on the ceilometer side,
and is wending its merry way through the gate.


The bigger problem I see here is that these changes were all made under
the guise of a bug when I think this is actually a blueprint.  We have
changes to the nova API, changes to the nova database API, CLI changes,
potential performance impacts (ceilometer can be hitting the nova
database a lot when polling here), security impacts (ceilometer needs
admin access to the nova API to list floating IPs for all tenants),
documentation impacts (the API and CLI changes are not documented), etc.

So right now we're left with, in my mind, two questions:

1. Do we just fix the spam bug 1328694 and move on, or
2. Do we revert the nova API/CLI changes and require this goes through
the nova-spec blueprint review process, which should have happened in
the first place.

So just to repeat the points I made on the unlogged #os-nova IRC channel
earlier, for posterity here ...

Nova already exposed an all_tenants flag in multiple APIs (servers,
volumes,
security-groups etc.) and these would have:

(a) generally pre-existed ceilometer's usage of the corresponding APIs

and:

(b) been tracked and proposed at the time via straight-forward LP bugs,
as  opposed to being considered blueprint material

So the manner of the addition of the all_tenants flag to the floating_ips
API looks like it just followed existing custom & practice.

Though that said, the blueprint process and in particular the nova-specs
aspect, has been tightened up since then.

My preference would be to fix the issue in the underlying API, but to use
this as "a teachable moment" ... i.e. to require more oversight (in the
form of a reviewed & approved BP spec) when such API changes are proposed
in the future.

Cheers,
Eoghan


Are there other concerns here?  If there are no major objections to the
code that's already merged, then #2 might be excessive but we'd still
need docs changes.

I've already put this on the nova meeting agenda for tomorrow.

[1] https://bugs.launchpad.net/ceilometer/+bug/1328694
[2] https://bugs.launchpad.net/nova/+bug/1262124
[3] https://review.openstack.org/#/c/81429/
[4] https://review.openstack.org/#/c/83660/
[5] https://review.openstack.org/#/c/83676/

--

Thanks,

Matt Riedemann


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


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


While there is precedent for --all-tenants with some of the other APIs,
I'm concerned about where this stops.  When ceilometer wants polling on
some other resources that the nova API exposes, will it need the same
thing?  Doing all of this polling for resources in all tenants in nova
puts an undue burden on the nova API and the database.

Yes, that's a fair point.

The only othe

Re: [openstack-dev] [ceilometer]support direct alarm_evaluator db access

[liusheng]

Hi Nihongi,
Thanks for your attention. I have tried to commit patches for this issue.
Gerrit 
topic:https://review.openstack.org/#q,topic:bp/direct-alarm-evaluator-db-access,n,z 
<https://review.openstack.org/#q,topic:bp/direct-alarm-evaluator-db-access,n,z>

hope it can be helpful for you, and any advice is appreciated:)

? 2014/4/21 18:01, Nobuyoshi Nihongi ??:

Hi Liu sheng,

We're also investigating alarm_evaluator performance.
We observed that alarm_evaluator spends half of the time for calling
ceilometerclient while evaluating alarms.
Allowing alarm_evaluator directly access db will greatly improve the
performance if you have many alarms.

Best regards,
Nihongi



From: liusheng 
To: openstack-dev@lists.openstack.org
Date: Tue, 15 Apr 2014 15:26:58 +0800
Subject: [openstack-dev] [ceilometer]support direct alarm_evaluator db access

Hi there,
Currently,alarm_evaluator invoke ceilometerclient to get all assigned
alarms. and then, evaluate per alarm by get statistics, which will also
call ceilometerclient. this process is:
evaluator-->ceilometerclient-->ceilometer API-->db.
If we use default option of evaluation_interval (60s), and if we have
many alarms, alarm_evaluator will frequently invoke ceilometerclient and
will produce many http requests per minute.
That is inefficient,it affect the performance of ceilometer(data
collection, data query, e.g.). The better way is allowing
alarm_evaluator access db directely.

Should the related codes of alarm-evaluator need a refactor?

Can you provide your thoughts about this?

I have registered a related blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/direct-alarm-evaluator-db-
access

Best regards
Liu sheng


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

--
Nobuyoshi Nihongi
NTT Software Innovation Center
Phone: +81 422 59 4880
E-mail: nihongi.nobuyo...@lab.ntt.co.jp

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


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

[openstack-dev] [ceilometer]support direct alarm_evaluator db access

[liusheng]

Hi there,
Currently,alarm_evaluator invoke ceilometerclient to get all assigned
alarms. and then, evaluate per alarm by get statistics, which will also
call ceilometerclient. this process is:
evaluator-->ceilometerclient-->ceilometer API-->db.
If we use default option of evaluation_interval (60s), and if we have
many alarms, alarm_evaluator will frequently invoke ceilometerclient and
will produce many http requests per minute.
That is inefficient,it affect the performance of ceilometer(data
collection, data query, e.g.). The better way is allowing
alarm_evaluator access db directely.

Should the related codes of alarm-evaluator need a refactor?

Can you provide your thoughts about this?

I have registered a related blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/direct-alarm-evaluator-db-access

Best regards
Liu sheng


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