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

[Ryota Mibu]

Hi Tony,


That 'gate_hook.sh' is not good for tempest jobs. DEVSTACK_GATE_TEMPEST is set 
0 in that script, and default one seems better 
(devstack-gate/devstack-vm-gate.sh) .

https://review.openstack.org/#/c/320770/


BR,
Ryota

> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Wednesday, May 25, 2016 1:11 PM
> To: openstack-dev@lists.openstack.org; Mibu Ryota(壬生 亮太)
> Subject: Re: [openstack-dev] [aodh] Tempest gate not working
> 
> On Tue, May 24, 2016 at 04:50:21PM +0200, Julien Danjou wrote:
> > 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.
> 
> Your gate scripts didn't like tempest as an enabled service.
> 
> https://review.openstack.org/#/c/320734/1
> 
> Looks to fix it.
> 
> Yours Tony.
__
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] [aodh] Tempest gate not working

[Ryota Mibu]

Julien,


Thank you for the heads up.

I'll check aodh tempest tests, and also drop tempest full tests in ceilometer 
since the code for ceilometer was removed from tempest.


BR,
Ryota

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Tuesday, May 24, 2016 11:50 PM
> To: openstack-dev@lists.openstack.org
> Cc: Mibu Ryota(壬生 亮太)
> Subject: [aodh] Tempest gate not working
> 
> 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-1
> 9_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,
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info

__
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] [aodhclient] does the aodh have the feature for import/export batch alarms?

[Ryota Mibu]

Hi,


I also agree with ZhiQiang.

How about using Heat Template which improve portability of app and configs?


Cheers,
Ryota

> -Original Message-
> From: ZhiQiang Fan [mailto:aji.zq...@gmail.com]
> Sent: Friday, May 20, 2016 11:42 AM
> To: li.yuanz...@zte.com.cn
> Cc: OpenStack Development Mailing List; Ildikó Váncsa; lianhao...@intel.com; 
> Sheng Liu; Mibu Ryota(壬生 亮太); Julien
> Danjou
> Subject: Re: [openstack-dev] [aodhclient] does the aodh have the feature for 
> import/export batch alarms?
> 
> batch alarm is not supported, and I think it is a burden instead of good 
> feature to implement it in aodh
> 
> import/export alarm is not supported, considering dump db and restore it in 
> new env? or you can get alarm list from old
> env and create new alarm in new env via REST API if data set is not too large.
> 
> On Fri, May 20, 2016 at 9:37 AM,  wrote:
> 
> 
>   HI All,
> 
>   in the aodh/aodhclient, I not find the feature for 
> import/export batch alarms.
> 
>   I mainly want to use it to implement the following requirement:
>   In "migrate alarms from one openstack env to another openstack 
> env" scenario, I would like to do this
> requirement
>  by a simple method, such as exporting/downloading the alarms 
> from one env and then importing these alarms
> to a new env.
> 
>   currently, does the aodh have the similar command for 
> import/export batch alarms?
>   or does have an alternative method to implement this 
> requirement?
>   If not have, does the feature need to add in aodh/aodhclient?
> 
>   Rajen(liyuanzhen)
> 
> 
>   
>   ZTE Information Security Notice: The information contained in this mail 
> (and any attachment transmitted herewith)
> is privileged and confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended
> recipient, any disclosure, reproduction, distribution or other dissemination 
> or use of the information contained is strictly
> prohibited.  If you have received this mail in error, please delete it and 
> notify us immediately.
> 
> 
> 
> 

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

Re: [openstack-dev] [Openstack] [AodhClient] "composite alarm" unit test missing in aodhclient ?

[Ryota Mibu]

Agree, we should have it. Could you propose the change, adding liusheng as a 
reviewer? He made this composite alarm and can check your patch properly.

/Ryota

> -Original Message-
> From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn]
> Sent: Thursday, May 19, 2016 5:36 PM
> To: Mibu Ryota(壬生 亮太); openstack-dev@lists.openstack.org
> Cc: aji.zq...@gmail.com; ildiko.van...@ericsson.com; Julien Danjou; 
> lianhao...@intel.com; liusheng2...@gmail.com
> Subject: RE: RE: [Openstack] [AodhClient] "composite alarm" unit test missing 
> in aodhclient ?
> 
> Yes, right, the "composite_rule" should be None in def test_alarm_from_args  
> :-)
> 
> In addition, read the unit tests in "test_alarm_cli.py", there is no 
> composite test, (like "def test_validate_args_composite",
> similar with "test_validate_args_threshold, 
> test_validate_args_gnocchi_resources_threshold " ), which is corresponding
> to composite alarm.
> 
> So, I think the "def test_validate_args_composite" may be needed, What do you 
> think?
> 
> thank you
> 
> best regards
> 
> Rajen
> 
> >
> > Hi,
> >
> >
> > The test case you pointed is for threshold alarm, so it is OK and expected 
> > that "composite_rule" is None.
> >
> > Checking test codes is good idea. You can add new tests when you found 
> > something missing by posting new patch.
> >
> >
> > BR,
> > Ryota
> >
> > > -Original Message-
> > > From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn
> > >  ]
> > > Sent: Thursday, May 19, 2016 12:27 PM
> > > To: openstack-dev@lists.openstack.org
> > > Cc: aji.zq...@gmail.com; ildiko.van...@ericsson.com;
> > > lianhao...@intel.com; liusheng2...@gmail.com; Mibu Ryota(壬生 亮
> > > 太); Julien Danjou
> > > Subject: [Openstack] [AodhClient] "composite alarm" unit test missing in 
> > > aodhclient ?
> > >
> > > HI All,
> > > in aodhclient/tests/unit/test_alarm_cli.py[1]
> > >  
>  > , the "composite_rule" is None.
> > > is the composite_rule test missing? and should we add it ?
> > >
> > > [1]
> > > https://github.com/openstack/python-aodhclient/blob/master/aodhclien
> > > t/tests/unit/test_alarm_cli.py
> > >  > > nt/tests/unit/test_alarm_cli.py>
> > >  > > nt/tests/unit/test_alarm_cli.py
> > >  > > nt/tests/unit/test_alarm_cli.py> >
> > >
> > > Rajen(liyuanzhen)
> > >
> > >
> > > 
> > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee(s).  
> > > If you are not an intended recipient, any
> disclosure, reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.
> > > If you have received this mail in error, please delete it and notify us 
> > > immediately.
> > >
> > >
> >
> >
> >
> 
> 
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is
> privileged and confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended recipient,
> any disclosure, reproduction, distribution or other dissemination or use of 
> the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us 
> immediately.
> 
> 


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

Re: [openstack-dev] [Openstack] [AodhClient] "composite alarm" unit test missing in aodhclient ?

[Ryota Mibu]

Hi,


The test case you pointed is for threshold alarm, so it is OK and expected that 
"composite_rule" is None.

Checking test codes is good idea. You can add new tests when you found 
something missing by posting new patch.


BR,
Ryota

> -Original Message-
> From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn]
> Sent: Thursday, May 19, 2016 12:27 PM
> To: openstack-dev@lists.openstack.org
> Cc: aji.zq...@gmail.com; ildiko.van...@ericsson.com; lianhao...@intel.com; 
> liusheng2...@gmail.com; Mibu Ryota(壬生 亮
> 太); Julien Danjou
> Subject: [Openstack] [AodhClient] "composite alarm" unit test missing in 
> aodhclient ?
> 
> HI All,
> in aodhclient/tests/unit/test_alarm_cli.py[1]
> 
>  , the "composite_rule" is None.
> is the composite_rule test missing? and should we add it ?
> 
> [1] 
> https://github.com/openstack/python-aodhclient/blob/master/aodhclient/tests/unit/test_alarm_cli.py
> 
> 
> Rajen(liyuanzhen)
> 
> 
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is
> privileged and confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended recipient,
> any disclosure, reproduction, distribution or other dissemination or use of 
> the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us 
> immediately.
> 
> 


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

Re: [openstack-dev] [Openstack] [Aodh] add "meter-list" command in Aodh CLI

[Ryota Mibu]

Hi,


We shouldn't have 'meter-list' in aodhclient.

Nova have API and function to show image list, and 'nova image-list' is talking 
to nova, not glance. It would be strange if '$ aodh meter-list' (aodhclient) 
made request to ceilometer.

On the other hand, I understand your concern. We can improve aodh document 
and/or add help message of aodhclient, saying like 'meter can be found in 
ceilometer'. What do you think?


Cheers,
Ryota

> -Original Message-
> From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn]
> Sent: Wednesday, May 18, 2016 11:52 AM
> To: Julien Danjou; openstack-dev@lists.openstack.org
> Cc: openstack-dev@lists.openstack.org; liusheng2...@gmail.com; 
> aji.zq...@gmail.com; ildiko.van...@ericsson.com;
> lianhao...@intel.com; Mibu Ryota(壬生 亮太); zhang.yuj...@zte.com.cn
> Subject: [Openstack] [Aodh] add "meter-list" command in Aodh CLI
> 
> So sorry, my mistake when create the link.
> 
> 
> > On Tue, May 17 2016, li.yuanz...@zte.com.cn wrote:
> >
> > > Now, in Aodh CLI, when create a threshold alarm, the
> > > -m/--meter-name must be required.
> > > But, if the user is not familiar with ceilometer or aodh,
> > > the user is not sure what value should give to -m/--meter-name.
> > > So the command "aodh meter list", I think, is needed.
> 
> > I don't think so, that's a Ceilometer command. There's no need for
> > Aodh client to talk to Ceilometer.
> 
> Thank you for your suggestion, but I have a different opinion.
> meter list, I think, is not exclusive for ceilometer command, especially 
> after aodh is seperated from ceilometer.
> Add meter list in Aodh CLI can make user more convenience and easy to use 
> Aodh, such as when users create a threshold
> alarm and don't know which kind of meter is supported, users can easily query 
> it by meter-list.
> For example, "nova image-list ", as well as "glance list"command, can get the 
> image value, which is required for creating
> a instance by "nova boot --image  ".
> 
> But there is really an ambiguity for the " migrate meter-list command from 
> ceilometer CLI to Aodh CLI ", my miss.
> May "add meter-list in Aodh CLI" is more appropriate.
> 
> 
> 
> 
> 
> >
> > > I create a bp[1], to migrate "meter-list" command from
> > > ceilometer CLI to Aodh CLI.
> > > Is there any suggestion for this bp? or is the bp necessary?
> > >
> > > [1]:
> > > https://blueprints.launchpad.net/cinder/+spec/migrate-meter-list-com
> > > mand-from-ceilometer-cli-to-aodh-cli
> > >  > > mmand-from-ceilometer-cli-to-aodh-cli>
> 
> > Thanks for your effort! Though I'd like to point a few problems here:
> > 1. This blueprint is created in Cinder 2. You sent this mail to the
> > *user* mailing list, and not to the
> >developer mailing list (openstack-dev@lists.openstack.org)
> > 3. You did not discuss anything on the dev mailing list with any of the
> >   active Telemetry developer before, and just took action before we can
> >   comment and state that this is a bad idea (like I just did). Not the
> >   best move.
> > 4. Cc'ing individuals is not the best move (again, dev mailing list is
> >the right medium)
> >
> > Cheers,
> > --
> > Julien Danjou
> 
> I will obsolete the link in cinder, and thank you for your suggestion again.
> 
> 
> 
> 
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is
> privileged and confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended recipient,
> any disclosure, reproduction, distribution or other dissemination or use of 
> the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us 
> immediately.
> 
> 


__
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][tempest] disabling 'full' tempest tests for ceilometer changes in CI

[Ryota Mibu]

Hi,


Can we disable 'full' tempest tests for ceilometer?

- gate-tempest-dsvm-ceilometer-mongodb-full
- gate-tempest-dsvm-ceilometer-mysql-full
- gate-tempest-dsvm-ceilometer-mysql-neutron-full
- gate-tempest-dsvm-ceilometer-postgresql-full
- gate-tempest-dsvm-ceilometer-es-full

We've merged ceilometer test cases from tempest repo to ceilometer/aodh repo as 
tempest plugin [1-2].
So, I suppose we can disable these jobs for ceilometer checks and gates, once 
we enabled ceilometer tempest tests with migrated codes [3].

But, it will stop other tempest tests not in ceilometer dir of tempest in gate 
jobs for ceilometer, as current setup is to kick 'full' tempest tests even for 
ceilometer changes.
Let me know if there is any problem.
I might miss the original intention of Jenkins job setup for ceilometer.

[1] https://blueprints.launchpad.net/ceilometer/+spec/tempest-plugin
[2] https://blueprints.launchpad.net/ceilometer/+spec/tempest-aodh-plugin
[3] https://review.openstack.org/#/c/303921/


Thanks,
Ryota


__
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] [tempest] clients/manager in plugins

[Ryota Mibu]

Hi Ghanshyam,



Thanks for your response.

It seems that I'm headed in the right direction.

One more question. - Should we migrate from 'service_client' to 'rest_client' 
in tempest-lib?



Best regards,
Ryota

> -Original Message-
> From: GHANSHYAM MANN [mailto:ghanshyamm...@gmail.com]
> Sent: Saturday, December 12, 2015 11:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tempest] clients/manager in plugins
> 
> Hi Ryota,
> 
> That is the one way as you mentioned.
> 
> On Fri, Dec 11, 2015 at 8:15 PM, Ryota Mibu  wrote:
> > Hi,
> >
> >
> > This is a question regarding design of clients and managers in a tempest 
> > plugin.
> >
> >
> > I'm not familiar with tempest, but it seems that there are the following 
> > terms:
> >
> > Client: client of service or feature (part of service)
> >
> > ClientManager: having clients which are needed for particular test
> > scenario
> 
> Yes, clients called service clients are those which place request on services 
> and Manager to load those clients and
> make them available for tests cases.
> 
> > According to [1], we are encouraged to have own client in each project 
> > repository instead of tempest tree. That
> means we may have to gather clients from other repositories to create a test 
> scenario when it use other services.
> For example, when  and  are out of tempest scope/tree, 
> we have to load client of 
> from its repository in order to create a test scenario under .
> 
> Yes, Tempest will maintain the service client for 6 core projects (as per Big 
> tent Architecture) and those will be
> available in Tempest-lib as stable interfaces (many of the compute clients 
> are available [4] and other in progress).
> Plugins or any functional tests can use those from Tempest-lib and about 
> other project(other than those 6 which Tempest
> own) clients, yes plugin needs to use from that project repo.
> 
> >
> > If so, I'd like to use tempest.test.BaseTestCase() with my ClientManager 
> > which is customized to load clients from
> other repositories out of tempest and my own repository. So, I proposed [2]. 
> But, if there is a better approach to
> do the similar thing, please let me know.
> 
> So existing plugins like Manila etc, instantiate their Manager  in their base 
> test class which is inherited from
> tempest.test.BaseTestCase() Along with that way, your idea of adding option 
> in Tempest base class itelf to give
> flexibility to users to provide Manager class looks good to me as a short 
> term solution.
> Tempest long term solution/goal is to provide the plugin ability for Manager 
> class also and make that available from
> lib. But that is plan and might take time.
> 
> >
> >
> > [1] http://docs.openstack.org/developer/tempest/plugin.html
> > [2] https://review.openstack.org/#/c/255161/
> 
> [3] - 
> https://github.com/openstack/tempest-lib/tree/master/tempest_lib/services
> 
> >
> >
> > Thanks,
> > Ryota
> >
> > ---
> > "Ryota Mibu" 
> > NEC Corporation
> >
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> --
> Regards
> Ghanshyam Mann
> +81-8084200646
> 
> __
> 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] [tempest] clients/manager in plugins

[Ryota Mibu]

Hi,


This is a question regarding design of clients and managers in a tempest plugin.


I'm not familiar with tempest, but it seems that there are the following terms:

Client: client of service or feature (part of service)

ClientManager: having clients which are needed for particular test scenario

According to [1], we are encouraged to have own client in each project 
repository instead of tempest tree. That means we may have to gather clients 
from other repositories to create a test scenario when it use other services. 
For example, when  and  are out of tempest scope/tree, we 
have to load client of  from its repository in order to create a 
test scenario under .

If so, I'd like to use tempest.test.BaseTestCase() with my ClientManager which 
is customized to load clients from other repositories out of tempest and my own 
repository. So, I proposed [2]. But, if there is a better approach to do the 
similar thing, please let me know.


[1] http://docs.openstack.org/developer/tempest/plugin.html
[2] https://review.openstack.org/#/c/255161/


Thanks,
Ryota

-------
"Ryota Mibu" 
NEC Corporation


__
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][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,



> > Can we clarify use case again in terms of service role definition?
> 
> Our use cases focus on giving value to the cloud admin, who will be able to:
> 
> - view the topology of his environment, the relations between the physical, 
> virtual and applicative layer and the
> statuses all resources
> - view the alarms history
> - view alarms about problems that Vitrage deduced could happen, even if no 
> other OpenStack component reported these
> problems (yet)
> - view RCA information about the alarms

OK, thanks.

> > Aodh provides alarming mechanism to *notify* events and situations
> > calculated from various data sources. But, original/master information
> > of resource including latest resource state is owned by other services
> > such as nova.
> >
> > So, user who wants to know current resource state to find out dead
> > resources (instances), can simply query instances via nova api. And,
> > user who wants to know when/what failure occurred can query events via
> > ceilometer api. Aodh has alarm state and history though.
> 
> I'm not sure I fully understand the difference between Aodh events and 
> alarms. If the user wants to know what failure
> occurred, is it part of Aodh events, alarms, or both?

In short, 'event' is generated in OpenStack, 'alarm' is defined by a user. 
'event' is a container of data passed from other OpenStack services through 
OpenStack notification bus. 'event' and contained data will be stored in 
ceilometer DB and exposed via event api [1]. 'alarm' is pre-configured alerting 
rule defined by a user via alarm API [2]. 'Alarm' also has state like 'ok' and 
'alarm', and history as well.

[1] 
http://docs.openstack.org/developer/ceilometer/webapi/v2.html#events-and-traits
[2] http://docs.openstack.org/developer/aodh/webapi/v2.html#alarms


The point is whether we should use 'event' or 'alarm' for all failure 
representation. Maybe we can use 'event' for all raw error/fault notification, 
and use 'alarm' for exposing deduced/wrapped failure. This is my view, so might 
be wrong.


Best regards,
Ryota

__
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][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,


> > > Let me see if I got this right: are you suggesting that we create
> > > on-the-fly alarm definitions with no alarm_actions, for every
> > > deduced
> > alarm that we want to raise? And this will spare us the extra alarm
> > evaluation in AODH?
> >
> > Yes. But, please note that could be the first step. The next step
> > would be make vitrage to send out alarm event to ceilometer/aodh the
> > pre- configured event alarm will recognize the alarm and fire the
> > alarm notification to another service or an end user. Eventually, we
> > should have relevant alarm type and evaluator to proxy evaluation in
> > vitrage, I think.
> 
> The next step can happen if and when Aodh supports alarm templates.
> If Vitrage can handle about 30 alarm types, and there are 100 instances, we 
> don't want to pre-configure 3000 alarms,
> which most likely will never be triggered.


I understand your concern. Aodh is user facing service, so having lots of 
alarms doesn't make sense.

Can we clarify use case again in terms of service role definition?

Aodh provides alarming mechanism to *notify* events and situations calculated 
from various data sources. But, original/master information of resource 
including latest resource state is owned by other services such as nova.

So, user who wants to know current resource state to find out dead resources 
(instances), can simply query instances via nova api. And, user who wants to 
know when/what failure occurred can query events via ceilometer api. Aodh has 
alarm state and history though.



> > > Another question is our need to get alarms from other sources, like
> > > Nagios, zabbix, ganglia, etc. We thought that Vitrage would query
> > > these Alarms from each source directly, and then create alarms in
> > AODH in the same way as our deduced alarms: for example create
> > nagios_ovs_vswitchd alarm if nagios check_ovs_vswitchd test failed.
> > > An alternative could be to integrate nagios directly with AODH.
> > > What do you think?
> >
> > Hmm, I don't have clear view on this. If the source can includes
> > OpenStack IDs and can be generate relevant meter/sample, it should be
> > useful to integrate with ceilometer. But if you want to do some
> > operations (like correlation), then it is reasonable to integrate with
> > vitrage.
> 
> The source may include alarms on resources that are not defined in OpenStack, 
> like switches or ports. And the alarms
> are not necessarily related to meters, they can be test nagios failures for 
> example.


Yes, so it depends on type of resource and its parameter.



> > > > BTW, is it useful to have on-the-fly evaluation of combination
> > alarm
> > > > with event alarms for alarm aggregation or other cases?
> > >
> > > I'm not sure I understand. Can you give a detailed example?
> >
> > OK. The 'combination' type alarm enables you to aggregate multiple
> > alarm to one alarm. This can be used when you want to receive alarm
> > when the both of physical NIC ports are downed to recognize logical
> > connection unavailability if the ports are teamed for redundancy. Now,
> > the combination alarms are evaluated periodically that means you can
> > receive combination alarm not on-the-fly while you are using event
> > alarms as source of combination alarm though.
> 
> I think I understand your point. It means that certain alarms will arrive to 
> Vitrage in delay, due to your evaluation
> policy. I think we will have to address this issue at some point, but it 
> won't change our overall design.

Yes, I'm just curious if there is any user can get benefit from this 
improvement to set priority.



> > > In addition, in Vitrage we plan to handle alarm aggregation by
> > > creating aggregation rule templates, for example based on the RCA
> > information.
> > > The user will be able to see only the root cause alarms, and then
> > > drill down to all specific alarms. But I doubt if this will be done
> > for Mitaka.
> >
> > I think 'the RCA information' means information for RCA. I mean
> > vitrage will use the resource topologies or relationship in
> > aggregation, rather than result of RCA. Am I right?
> 
> The term "aggregation" is used in different contexts, which may be confusing. 
> Our plan is to examine the already-computed
> RCA information, and see, for example, that a switch failure alarm caused 
> alarms on 100 related instances. In horizon,
> the result will be 101 alarms shown to the user in a flat list.
> By "alarm aggregation based on RCA" we mean that we will have an API to get 
> root cause alarms, which will return only
> the switch alarm. The horizon user will see one alarm, and may then ask to 
> expand the view and see all the other alarms
> that were caused by it.

I see. I used the term "aggregation" for aggregation process in alarm 
evaluation.



Thanks,
Ryota


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,


> > One approach we can take, is that you configure aodh to pass each row
> > event (e.g. each VM downed) wrapped in alarm notification to vitrage,
> > then do some operation (e.g. deducing, aggregating) and store
> > resource- level alarm without any alarm_actions, so that users can see
> > the alarms in horizon view. This may not require alarm evaluation, so
> > we can forget the problem I raised (cache refresh interval).
> 
> Let me see if I got this right: are you suggesting that we create on-the-fly 
> alarm definitions with no alarm_actions,
> for every deduced alarm that we want to raise? And this will spare us the 
> extra alarm evaluation in AODH?

Yes. But, please note that could be the first step. The next step would be make 
vitrage to send out alarm event to ceilometer/aodh the pre-configured event 
alarm will recognize the alarm and fire the alarm notification to another 
service or an end user. Eventually, we should have relevant alarm type and 
evaluator to proxy evaluation in vitrage, I think.


> My next question is how exactly we should create these resource-level alarms. 
> Can we create an alarm definition with
> no rule, no actions, and initial state set to "alarm"? (I'm not sure it can 
> be done in the current AODH API)

You can. This is not proper way of using aodh though. But, this is easy to 
create an alarm entry to show it in horizon.


> Another question is our need to get alarms from other sources, like Nagios, 
> zabbix, ganglia, etc. We thought that
> Vitrage would query these Alarms from each source directly, and then create 
> alarms in AODH in the same way as our
> deduced alarms: for example create nagios_ovs_vswitchd alarm if nagios 
> check_ovs_vswitchd test failed.
> An alternative could be to integrate nagios directly with AODH.
> What do you think?

Hmm, I don't have clear view on this. If the source can includes OpenStack IDs 
and can be generate relevant meter/sample, it should be useful to integrate 
with ceilometer. But if you want to do some operations (like correlation), then 
it is reasonable to integrate with vitrage.


> > BTW, is it useful to have on-the-fly evaluation of combination alarm
> > with event alarms for alarm aggregation or other cases?
> 
> I'm not sure I understand. Can you give a detailed example?

OK. The 'combination' type alarm enables you to aggregate multiple alarm to one 
alarm. This can be used when you want to receive alarm when the both of 
physical NIC ports are downed to recognize logical connection unavailability if 
the ports are teamed for redundancy. Now, the combination alarms are evaluated 
periodically that means you can receive combination alarm not on-the-fly while 
you are using event alarms as source of combination alarm though.

> > Horizon view is the different topic. Maybe we can reduce the number of
> > alarms listed in user view by creating raw alarms in admin space that
> > is not visible from end user, or using relevant severity or tag so
> > that user can filter out uninterested alarms.
> 
> Referring to this[1] blueprint, do you have specific concerns regarding the 
> usability/performance of Horizon view
> when there are many alarms?
> I think that your ideas make sense, and we can implement them if there is a 
> need.

Sorry, I'm not familiar with horizon these days... But, if you need change in 
aodh side, I can help you.


> In addition, in Vitrage we plan to handle alarm aggregation by creating 
> aggregation rule templates, for example based
> on the RCA information.
> The user will be able to see only the root cause alarms, and then drill down 
> to all specific alarms. But I doubt if
> this will be done for Mitaka.

I think 'the RCA information' means information for RCA. I mean vitrage will 
use the resource topologies or relationship in aggregation, rather than result 
of RCA. Am I right?


Best regards,
Ryota

__
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][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi,


Sorry for my late response...

It seems like a fundamental question whether we should have rich function or 
intelligence in on-the-fly event alarm evaluation. I think we can add simple 
operations (like aggregating alarm) in aodh evaluator, and other operations 
(like deducing with referring some external DB) should be done outside of the 
evaluation process to reduce impact on other evaluations. But, if we separate 
too much, then there will be many interactions between two services that makes 
slow to finish sequence of alarm handling.

One approach we can take, is that you configure aodh to pass each row event 
(e.g. each VM downed) wrapped in alarm notification to vitrage, then do some 
operation (e.g. deducing, aggregating) and store resource-level alarm without 
any alarm_actions, so that users can see the alarms in horizon view. This may 
not require alarm evaluation, so we can forget the problem I raised (cache 
refresh interval).

BTW, is it useful to have on-the-fly evaluation of combination alarm with event 
alarms for alarm aggregation or other cases?

Horizon view is the different topic. Maybe we can reduce the number of alarms 
listed in user view by creating raw alarms in admin space that is not visible 
from end user, or using relevant severity or tag so that user can filter out 
uninterested alarms.


Best regards,
Ryota


---
"Ryota Mibu" 
NEC Corporation


__
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][vitrage] Raising custom alarms in AODH

[Ryota Mibu]

Hi Ifat,


Thank you for starting discussion how AODH can be integrated with Vitrage that 
would be a good example of AODH integration with other OpenStack components.

The key role of creating alarm definition is to set endpoint (alarm_actins) 
which can be receive alarm notification from AODH. How the endpoints can be set 
in your use case? Those endpoints are configured via virtage API and stored in 
its DB?

I agree with Gordon, you can use even-alarm with generating "event" containing 
alarming message that can be captured in aodh if vitrage relay the alarm 
definition to aodh. That is more feasible way rather than creating alarm 
definition right before triggering alarm notification. The reason is that aodh 
evaluator may not be aware of new alarm definitions and won't send notification 
until its alarm definition cache is refreshed in less than 60 sec (default 
value).

Having special rule and external evaluator would be alternative, but it should 
be difficult to catch up latest aodh, since it will be changed faster with 
small code base as result of split from ceilometer.


BR,
Ryota

> -Original Message-
> From: AFEK, Ifat (Ifat) [mailto:ifat.a...@alcatel-lucent.com]
> Sent: Tuesday, November 24, 2015 1:15 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom 
> alarms in AODH
> 
> Hi Gord,
> 
> Please see my answers below.
> 
> Ifat.
> 
> 
> > -Original Message-
> > From: gord chung [mailto:g...@live.ca]
> > Sent: Monday, November 23, 2015 4:57 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising
> > custom alarms in AODH
> >
> > hi Ifat,
> >
> > i added some questions below.
> >
> > On 23/11/2015 7:16 AM, AFEK, Ifat (Ifat) wrote:
> > > Hi,
> > >
> > > We have a couple of questions regarding AODH alarms.
> > >
> > > In Vitrage[1] project we have two use cases that involve Ceilometer:
> > >
> > > 1. Import Ceilometer alarms, as well as alarms and resources from
> > other sources (Nagios, Zabbix, Nova, Heat, etc.), and produce RCA
> > insights about the connection between different alarms.
> > to clarify, Ceilometer alarms is deprecated for Aodh and will be
> > removed very, very soon.
> 
> Right, I meant Aodh alarms.
> 
> >
> > > 2. Raise "deduced alarms". For example, in case we detect a high
> > memory consumption on a host, we would like to raise deduced alarms
> > saying "instance might be suffering due to high memory consumption on
> > the host" on all related instances. Then, we can further deduce that
> > applications running on these instances might also be affected, and
> > raise alarms on them as well.
> > >
> > > Initially we planned to raise these deduced alarms in AODH, so other
> > Openstack components may consume them as well. Then, when we looked at
> > AODH alarms documentation, we noticed that there is currently no way
> > of raising custom alarms. We saw only three types of alarms: threshold
> > alarms, combination alarms and event alarms.
> > >
> > > So, our questions are:
> > >
> > > * Is there an alternative way of raising alarms in AODH?
> > what do we mean by raising alarms? do you want to create a new alarm
> > definition for Aodh or do you want to trigger an action? do you want
> > to have a new non-REST action?
> 
> I guess I would like to do both: create a new alarm definition, then trigger 
> it (call alarm_actions), and possibly
> later on set its state back to OK (call ok_action).
> I understood that currently all alarm triggering is internal in AODH, 
> according to threshold/events/combination alarm
> rules. Would it be possible to add a new kind of rule, that will allow 
> triggering the alarm externally?
> 
> >
> > > * Do you think custom alarms belong in AODH? Are you interested in
> > adding this capability to AODH?
> > >
> > > We would be happy to hear your vision and thoughts about it.
> > >
> > >
> > > Thanks,
> > > Ifat and Alexey.
> > >
> > >
> > > [1] https://wiki.openstack.org/wiki/Vitrage
> > >
> > >
> > >
> > >
> > >
> > __
> > >  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.

[openstack-dev] [ceilometer] jenkis job failures

[Ryota Mibu]

Hi,


Quick note to ceilometer folks.

Many check and gate jobs for ceilometer are failed due to WSME related issue 
that is already addressed by [1], so please make sure your patch set are 
rebased on the current master before execute 'recheck'.

[1] https://review.openstack.org/#/c/208467/


Thanks,
Ryota

-------
"Ryota Mibu" 
NEC Corporation


__
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

[Ryota Mibu]

Hi,


Sorry for my late response and my absent in weekly meetings...

I'm not sure whether I captured your idea correctly, but I prefer the second 
approach now.

I agreed the point Igor and liusheng mentioned that the second approach enables 
end users to have configurable expire-time.

In another point of view, the first approach may affect pipeline performance 
since it have to keep event sequence state or have to access DB for state 
querying when each event received. This is just my concern, but I think event 
pipeline should be simplest and limited to have only common features between 
event data storage, event alarming and other receiver like audit system.


Thanks,
Ryota

> -Original Message-
> From: liusheng [mailto:liusheng1...@126.com]
> Sent: Wednesday, August 05, 2015 1:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
> 
> 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
> 
> 
> 
>   
> __
>   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] [ceilometer] Aodh has been imported, next steps

[Ryota Mibu]

Hi,


I'd like to see how we can develop new alarm features, since I'm working on 
event-alarm.

Having duplicated code bases may confuse developer too, so we should have some 
policies like:

 * aodh focus on making sure that it provides existing API and functionality as 
of kilo to end users
 * ceilometer/alarm is open to develop new experimental features until L2/L3
 * having a merge window to move those new features to aodh from 
ceilometer/alarm around L3

What do you think?


Thanks,
Ryota

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Tuesday, June 30, 2015 3:48 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
> 
> 
> 
> On 29/06/2015 11:40 AM, Chris Dent wrote:
> > On Mon, 29 Jun 2015, Julien Danjou wrote:
> >
> >> Hi team,
> >>
> >> Aodh has been imported and is now available at:
> >>
> >>  https://git.openstack.org/cgit/openstack/aodh/
> >
> > woot!
> >
> >> I'm pretty clear about the next steps for Aodh and what we need to
> >> build, but something is still not clear to me. Do we go ahead and
> >> bite the bullet and remove ceilometer-alarming from ceilometer in Liberty?
> 
> i think we should follow up with the packagers. if i understand correctly, 
> the location of the code is not known from
> a user pov, it's the packagers that build the appropriate packages for them 
> to use.
> 
> if from packagers pov, they just need to work against Aodh, then i would lean 
> more to removing alarming from Ceilometer
> repo asap to avoid maintaining duplicate code bases and the eventual 
> diversion of the two.
> 
> >
> > This is the big question and is one of the things listed on the
> > potential agenda for the mid-cylce. When we do the splits do we
> > deprecate or delete the old code. Given the high chance of us
> > missing some of potential issues it seems like hasing it some before
> > the mid-cylce is a good idea.
> >
> > The two big overarching issues (that inform a lot of the details)
> > that I'm aware of are:
> >
> > * If we delete then we need to make sure we're working hand in hand
> >   with all of: downstream packagers, tempest, grenade, devstack,
> >   etc.
> >
> > * If we deprecate will people bother to use the new stuff?
> 
> i would think/hope the experience from end user doesn't actually change.
> ie. all the same packaged services remain.
> 
> >
> > I'm sure there are plenty of others.
> >
> 
> --
> 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] [ceilometer] RE: [all] how to send messages (and events) to our users

[Ryota Mibu]

Hi Gordon,


Great!

I put some generic questions regarding "Alerting on events" + "immediate 
notification" in gerrit.

> https://review.openstack.org/#/c/172893

I'd like to capture high-level direction of this feature.
If it's not right place to having such discussion and should move to mailing 
list, please let me know.
I can re-post them to this mailing list.


Thanks,
Ryota

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Tuesday, April 14, 2015 10:14 PM
> To: OpenStack Development Mailing List not for usage questions
> Subject: Re: [openstack-dev] [ceilometer] RE: [all] how to send messages (and 
> events) to our users
> 
> 
> 
> 
> > From: r-m...@cq.jp.nec.com
> > To: openstack-dev@lists.openstack.org
> > Date: Tue, 14 Apr 2015 08:36:01 +
> > Subject: [openstack-dev] [ceilometer] RE: [all] how to send messages
> > (and events) to our users
> >
> > Hi Gordon and Ceilometer folks,
> >
> >
> > I'm newbie in Ceilometer, but would like to get involved the contribution 
> > of "alerting on events".
> >
> >> in Liberty, we intend on support action/alerting on events so maybe
> >> it's something we should collaborate on to ensure the right functionality 
> >> is provided.
> >
> > Could you point the thread or link in which those discussion happen.
> >
> > I also drafted blueprint here:
> >
> > https://blueprints.launchpad.net/ceilometer/+spec/notification-alarm-e
> > valuator
> >
> > I hope this helps.
> >
> >
> > Thanks,
> > Ryota
> 
> this is perfect. we can discuss the details on the spec you posted. for those 
> interested in the topic, the spec is here:
> https://review.openstack.org/#/c/172893
> 
> cheers,
> 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] RE: [all] how to send messages (and events) to our users

[Ryota Mibu]

Hi Gordon and Ceilometer folks,


I'm newbie in Ceilometer, but would like to get involved the contribution of 
"alerting on events".

> in Liberty, we intend on support action/alerting on events so maybe it's 
> something we should collaborate on to ensure
> the right functionality is provided.

Could you point the thread or link in which those discussion happen.

I also drafted blueprint here:


https://blueprints.launchpad.net/ceilometer/+spec/notification-alarm-evaluator

I hope this helps.


Thanks,
Ryota

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Wednesday, April 08, 2015 2:52 AM
> To: OpenStack Development Mailing List not for usage questions
> Subject: Re: [openstack-dev] [all] how to send messages (and events) to our 
> users
> 
> > This could be extended to richer JSON events that include the stack,
> > resources affected in the update, stats like "num-deleted-resources"
> > or "num-replaced-resources", autoscaling actions, and info about stack 
> > errors.
> >
> > Is there a way for users as-is to view those raw notifications, not
> > just the indexed k/v pairs?
> 
> from Ceilometer POV, currently, raw notifications are optionally stored (for 
> auditing, postmortem analysis, etc...) but
> they are not queryable from the api (we don't support it as the performance 
> will [arguably] suffer depending on the backend).
> 
> the basic structure of an Event in Ceilometer is: id, timestamp, event_type, 
> a list of traits (queryable k/v pairs pulled
> from notification), and raw (full json notifications)
> 
> in Liberty, we intend on support action/alerting on events so maybe it's 
> something we should collaborate on to ensure
> the right functionality is provided.
> 
> cheers,
> 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][neutron] bridge name generator for vif plugging

[Ryota Mibu]

Ian and Daniel,


Thanks for the comments.

I have neutron spec here and planned to start from Neutron side to expose 
bridge name via port-binding API.

https://review.openstack.org/#/c/131342/


Thanks,
Ryota

> -Original Message-
> From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
> Sent: Monday, December 15, 2014 8:08 PM
> To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [nova][neutron] bridge name generator for vif
> plugging
> 
> Let me write a spec and see what you both think.  I have a couple of things
> we could address here and while it's a bit late it wouldn't be a dramatic
> thing to fix and it might be acceptable.
> 
> 
> On 15 December 2014 at 11:28, Daniel P. Berrange 
> wrote:
> 
>   On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote:
>   > Hey Ryota,
>   >
>   > A better way of describing it would be that the bridge name is,
> at present,
>   > generated in *both* Nova *and* Neutron, and the VIF type semantics
> define
>   > how it's calculated.  I think you're right that in both cases
> it would make
>   > more sense for Neutron to tell Nova what the connection endpoint
> was going
>   > to be rather than have Nova calculate it independently.  I'm not
> sure that
>   > that necessarily requires two blueprints, and you don't have a
> spec there
>   > at the moment, which is a problem because the Neutron spec deadline
> is upon
>   > us, but the idea's a good one.  (You might get away without a
> Neutron spec,
>   > since the change to Neutron to add the information should be small
> and
>   > backward compatible, but that's not something I can make judgement
> on.)
> 
>   Yep, the fact that both Nova & Neutron calculat the bridge name
> is a
>   historical accident. Originally Nova did it, because nova-network
> was
>   the only solution. Then Neutron did it too, so it matched what Nova
>   was doing. Clearly if we had Neutron right from the start, then
> it
>   would have been Neutrons responsibility todo this. Nothing in Nova
>   cares what the names are from a functional POV - it just needs to
>   be told what to use.
> 
>   Regards,
>   Daniel
>   --
>   |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
>   |: http://libvirt.org  -o-
> http://virt-manager.org :|
>   |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
>   |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|
> 
> 
>   ___
>   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] [nova][neutron] bridge name generator for vif plugging

[Ryota Mibu]

Hi all,


We are proposing a change to move bridge name generator (creating bridge name 
from net-id or reading integration bridge name from nova.conf) from Nova to 
Neutron. The followings are BPs in Nova and Neutron.

https://blueprints.launchpad.net/nova/+spec/neutron-vif-bridge-details
https://blueprints.launchpad.net/neutron/+spec/vif-plugging-metadata

I'd like to get your comments on this change whether this is relevant 
direction. I found related comment in Nova code [3] and guess these discussion 
had in context of vif-plugging and port-binding, but I'm not sure there was 
consensus about bridge name.


https://github.com/openstack/nova/blob/2014.2/nova/network/neutronv2/api.py#L1298-1299


Thanks,
Ryota


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

Re: [openstack-dev] [nova] Configuring libivrt VIF driver

[Ryota Mibu]

Hi Daniel,


> For Juno the vif_driver option still exists & can be used.

In the current master branch, there is no 'vif_driver' option for libvirt.
It has been deleted by [1], and I can't find any patches to enable 'vif_driver' 
config on gerrit.
Is there plan to get the 'vif_driver' config available before the Juno release?

[1] https://review.openstack.org/#/c/109266/


Regards,
Ryota

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Wednesday, August 27, 2014 11:07 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Configuring libivrt VIF driver
> 
> On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote:
> > Hi,
> >
> > Following the conversation [1]:
> > My understanding was that the way to use out of the tree vif_driver
> is
> > to set vif_driver option in nova.conf until there is a better way to
> > support such cases but the commit [2] removed this option.
> > Can someone clarify the current status (i.e. what is the current way
> > to do it ) in Juno?
> 
> For Juno the vif_driver option still exists & can be used.
> 
> It is only deleted in the Kilo release.
> 
> The recommendation is that people working on new VIF drivers should do
> so on a branch of the Nova repo, so that the can modify the libvirt VIF
> driver code to support their needs, rather than try to write a completely
> isolated out of tree impl. This is an approach that will need to be taken
> regardless in order to submit the VIF driver for review and merge to Nova.
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o-
> http://virt-manager.org :|
> |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|
> 
> ___
> 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

Re: [openstack-dev] [Baremetal][Neutron] SDN Solution for Openstack Baremetal Driver

[ryota mibu]

Hi Tim,

NTT-docomo and VTJ developed network isolation in baremetal before they
merging baremetal driver to upstream, and I also supported them by
providing SDN(OpenFlow) controller plugin. I don't have good article to
explain that for now, but I can have discussion if you are in the summit.

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