Re: [openstack-dev] [masakari]py35 unit tests are failed

2017-10-29 Thread Rikimaru Honjo 

Hello,

I understood why py35 unit tests were failed.

The 'message' attribute was deprecated and removed from Python3.[1]
But, some codes of masakari uses message attribute.[2]
So some unit tests are failed on py35.

I try to fix this by modifying below patch.

* Stop using deprecated 'message' attribute in Exception
  https://review.openstack.org/#/c/486576/

[1]
https://www.python.org/dev/peps/pep-0352/

[2]
For example...
https://github.com/openstack/masakari/blob/master/masakari/db/sqlalchemy/api.py#L231

On 2017/10/27 15:47, Rikimaru Honjo wrote:

Hello,

py35 unit tests of masakari are failed by same errors on gerrit.

e.g.
* https://review.openstack.org/#/c/441796/
   
=>http://logs.openstack.org/96/441796/3/check/openstack-tox-py35/d958f3f/testr_results.html.gz

* https://review.openstack.org/#/c/509782/
   
=>http://logs.openstack.org/82/509782/23/check/openstack-tox-py35/9612809/testr_results.html.gz

It seems to have been caused by sqlalchemy, but I haven't analyzed it enough 
yet.
Please tell in this ML or submit a patch if you can solve it.

Best regards,


--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



__
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] 答复: RE: [vitrage] some error in Aodh datasource

2017-10-29 Thread dong.wenjuan 
Hi Idan,






Sorry, maybe it's the issue of my OpenStack env. I'll check it later. Thanks~






BR,


dwj

























原始邮件




发件人：董文娟00101742
收件人： ;
抄送人： ;
日 期 ：2017年10月30日 08:59
主 题 ：答复: RE: [openstack-dev][vitrage] some error in Aodh datasource








Hi Idan,






Yes, it happens when Vitrage receives the Aodh alarm(event alarm) state change 
notification.


But for the event alarm and threshold alarms, they don't combine type dict and 
type Unicode.


So only gnocchi threshold alarm needs to encode.


I think gnocchi threshold alarm need to handle the state change notification 
separately, 



otherwise the event alarm and threshold alarm will raise exception as shown in 
the log below.


What do you think?





BR,


dwj






























发件人： ;
收件人：董文娟00101742;
抄送人： ;
日 期 ：2017年10月29日 17:04
主 题 ：RE: [openstack-dev][vitrage] some error in Aodh datasource








Hi dwj,


 


In this patch I added support for gnocchi threshold alarm.


This kind of alarm combine type dict and type Unicode. This occurs when 
receiving notification about state transition from insufficient data to alarm.


 


In order not to make a major change in the code structure this type of error 
should occur in event alarm (because it entirely type dict). It is caught in 
_convert_alarm_state_transition_event.


 


In the upcoming changes in Aodh datasource (because of Ceilometer’s API is 
being removed)  we might need to insert some changes so 
_convert_alarm_state_transition_event will receive also the alarm type (event, 
gnocchi..).


 


Let me know if I can be of any help.


 


Thanks.


BR


 


 


Idan kinory


 





 


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
 Sent: Friday, October 27, 2017 10:51 AM
 To: Kinory, Idan (Nokia - IL/Kfar Sava) 
 Cc: Afek, Ifat (Nokia - IL/Kfar Sava) ; 
openstack-dev@lists.openstack.org
 Subject: [openstack-dev][vitrage] some error in Aodh datasource


 

Hi Idan Kinory,

 

I deploy Vitrage with devstack using master branch.

Currently I found a error in Aodh datasource when I change the Aodh alarm 
state(alarm_state_transition notification).

 

The error log is as follows:


Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:30:50.429 
9880 DEBUG vitrage.datasources.listener_service [-] EVENT ENQUEUED:
 Oct 27 07:30:50 dwj-vitrage vitrage-collector[9880]: {'description': u'Alarm 
when * event occurred.', 'resource_id': None, 'vitrage_entity_type': 'aodh', 
'timestamp': u'2017-10-26T06:37:41.353447', 'state_timestamp': 
u'2017-10-27T07:09:06.636137', 'name': u'dwj',  'vitrage_datasource_action': 
'update', 'severity': u'low', 'vitrage_sample_date': '2017-10-27 
07:30:50.382730+00:00', 'vitrage_event_type': u'alarm.deletion', 'enabled': 
True, 'alarm_id': u'9578d0eb-5d09-49a2-80e9-fb1a6c7ce7e9', 'state': u'alarm', 
'repeat_actions':  False, 'event_type': (u'*',), 'project_id': 
u'378f268c64fc42c28226704dd71f37fe', 'type': u'event'} _enqueue_events 
/opt/stack/vitrage/vitrage/datasources/listener_service.py:106
 Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.327 
10104 DEBUG vitrage.datasources.services [-] start get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:119
 Oct 27 07:31:02 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:02.331 
10104 DEBUG vitrage.datasources.services [-] end get changes _get_changes 
/opt/stack/vitrage/vitrage/datasources/services.py:126
 Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver [-] Failed to Convert alarm state 
transition event - 'dict' object has no attribute 'encode': AttributeError: 
'dict' object has no attribute  'encode'
 Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver Traceback (most recent call last):
 Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver   File 
"/opt/stack/vitrage/vitrage/datasources/aodh/driver.py", line 352, in 
_convert_alarm_state_transition_event
 Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver unicode_to_str = 
state.encode("ascii")
 Oct 27 07:31:12 dwj-vitrage vitrage-collector[9880]: 2017-10-27 07:31:12.087 
9880 ERROR vitrage.datasources.aodh.driver AttributeError: 'dict' object has no 
attribute 'encode'

I noticed that you fix the code in this patch(Line 352-368): 
https://review.openstack.org/#/c/501701/4/vitrage/datasources/aodh/driver.py

Can you please explain why? Thanks.

 

BR,

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

Re: [openstack-dev] [Magnum] Docker Swarm Mode Support

2017-10-29 Thread Ricardo Rocha 
Hi Vahric.

On Fri, Oct 27, 2017 at 9:51 PM, Vahric MUHTARYAN  wrote:
> Hello All ,
>
>
>
> I found some blueprint about supporting Docker Swarm Mode
> https://blueprints.launchpad.net/magnum/+spec/swarm-mode-support
>
>
>
> I understood that related development is not over yet and no any Openstack
> version or Magnum version to test it also looks like some more thing to do.
>
> Could you pls inform when we should expect support of Docker Swarm Mode ?

Swarm mode is already available in Pike:
https://docs.openstack.org/releasenotes/magnum/pike.html

> Another question is fedora atomic is good but looks like its not up2date for
> docker , instead of use Fedora Atomic , why you do not use Ubuntu, or some
> other OS and directly install docker with requested version ?

Atomic also has advantages (immutable, etc), it's working well for us
at CERN. There are also Suse and CoreOS drivers, but i'm not familiar
with those.

Most pieces have moved to Atomic system containers, including all
kubernetes components so the versions are decouple from the Atomic
version.

We've also deployed locally a patch running docker itself in a system
container, this will get upstream with:
https://bugs.launchpad.net/magnum/+bug/1727700

With this we allow our users to deploy clusters with any docker
version (selectable with a label), currently up to 17.09.

> And last, to help to over waiting items “Next working items: ”  how we could
> help ?

I'll let Spyros reply to this and give you more info on the above items too.

Regards,
  Ricardo

>
>
>
> Regards
>
> Vahric Muhtaryan
>
>
> __
> 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

2017-10-29 Thread Jean-Philippe Evrard 
On 25 October 2017 at 10:10, Flavio Percoco  wrote:
> On 24/10/17 15:35 -0700, Emilien Macchi wrote:
>>
>> I figured that Sydney would be a great opportunity to have face2face
>> discussion around this topic, and I commit to be there and try to make
>> progress on this discussion.
>> I would love to get some people representing their deployment projects
>> and operators as well.
>>
>> Please join us :
>>
>> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20456/what-do-operators-want-from-the-stable-policy
>> and probably
>> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20480/upstream-lts-releases
>
>
> I'm interested in joining this discussion!
> Flavio
>
>
>> Thanks,
>>
>> On Tue, Oct 17, 2017 at 8:32 AM, Fox, Kevin M  wrote:
>>>
>>> So, my $0.02.
>>>
>>> A supported/recent version of a tool to install an unsupported version of
>>> a software is not a bad thing.
>>>
>>> OpenStack has a bad reputation (somewhat deservedly) for being hard to
>>> upgrade. This has mostly gotten better over time but there are still a large
>>> number of older, unsupported deployments at this point.
>>>
>>> Sometimes, burning down the cloud isn't an option and sometimes upgrading
>>> in place isn't an option either, and they are stuck on an unsupported
>>> version.
>>>
>>> Being able to deploy with a more modern installer the same version of the
>>> cloud your running in production and shift the load to it (sideways
>>> upgrade), but then have an upgrade path provided by the tool would be a
>>> great thing.
>>>
>>> Thanks,
>>> Kevin
>>> 
>>> From: Michał Jastrzębski [inc...@gmail.com]
>>> Sent: Monday, October 16, 2017 3:50 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible]
>>> [puppet] Proposing changes in stable policy for installers
>>>
>>> So my 0.02$
>>>
>>> Problem with handling Newton goes beyond deployment tools. Yes, it's
>>> popular to use, but if our dependencies (openstack services
>>> themselves) are unmaintained, so should we. If we say "we support
>>> Newton" in deployment tools, we make kind of promise we can't keep. If
>>> for example there is CVE in Nova that affects Newton, there is nothing
>>> we can do about it and our "support" is meaningless.
>>>
>>> Not having LTS kind of model was issue for OpenStack operators
>>> forever, but that's not problem we can solve in deployment tools
>>> (although we are often asked for that because our communities are
>>> largely operators and we're arguably closest projects to operators).
>>>
>>> I, for one, think we should keep current stable policy, not make
>>> exception for deployment tools, and address this issue across the
>>> board. What Emilien is describing is real issue that hurts operators.
>>>
>>> On 16 October 2017 at 15:38, Emilien Macchi  wrote:

 On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez 
 wrote:
>
> Emilien Macchi wrote:
>>
>> [...]
>> ## Proposal
>>
>> Proposal 1: create a new policy that fits for projects like
>> installers.
>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>> (open for feedback).
>> Content can be read here:
>>
>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>> please review).
>>
>> The idea is really to not touch the current stable policy and create a
>> new one, more "relax" that suits well for projects like installers.
>>
>> Proposal 2: change the current policy and be more relax for projects
>> like installers.
>> I haven't worked on this proposal while it was something I was
>> considering doing first, because I realized it could bring confusion
>> in which projects actually follow the real stable policy and the ones
>> who have exceptions.
>> That's why I thought having a dedicated tag would help to separate
>> them.
>>
>> Proposal 3: no change anywhere, projects like installer can't claim
>> stability etiquette (not my best option in my opinion).
>>
>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>> this need), please get involved in the review process.
>
>
> My preference goes to proposal 1, however rather than call it "relaxed"
> I would make it specific to deployment/lifecycle or cycle-trailing
> projects.
>
> Ideally this policy could get adopted by any such project. The
> discussion started on the review and it's going well, so let's see
> where
> it goes :)


 Thierry, when I