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
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
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
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:
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
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
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
-
il.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,
]. 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" <r-m...@cq.jp.nec.com>
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
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
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
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" <r-m...@cq.jp.nec.com>
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.
/
Thanks,
Ryota
---
Ryota Mibu r-m...@cq.jp.nec.com
NEC Corporation
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
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
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
*
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
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
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
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]
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
22 matches
Mail list logo
