Re: [openstack-dev] [all] Ubuntu 14.04 support in Newton and on

[Eric K]

Hi Jeremy, thank you for the pointers and the background on Newton!

On 1/19/17, 7:12 AM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

>On 2017-01-18 15:19:36 -0800 (-0800), Eric K wrote:
>> Hi all, Is there any community-wide policy on how long we strive
>> to maintain compatibility with Ubuntu 14.04? For example by
>> avoiding relying on MySQL 5.7 features. I've had a hard time
>> finding it on openstack.org and ML discussions. Thanks lots!
>
>Years ago the TC (only a few months after they ceased to be the PPB)
>agreed to the following:
>
>OpenStack will target its development efforts to latest
>Ubuntu/Fedora, but will not introduce any changes that would
>make it impossible to run on the latest Ubuntu LTS or latest
>RHEL.
>
>
>http://lists.openstack.org/pipermail/openstack-dev/2012-December/004052.ht
>ml
>
>http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.log.ht
>ml#l-7
>
>You can also find it referenced in our requirements documentation:
>
>
>http://docs.openstack.org/developer/requirements/#finding-distro-status
>
>The upshot has basically been that whatever the "latest Ubuntu LTS"
>was at the time the development cycle began is what we use for the
>purposes of testing development leading up to a given release, and
>is subsequently maintained for testing the resulting stable branches
>from that release until our support end-of-life is reached. However,
>the Newton release ended in an unfortunate situation...
>
>During the Newton development cycle, the Infra team decided to
>provide teams a means of gracefully migrating their testing from
>Ubuntu 14.04 LTS to 16.04 LTS with the expectation that it would be
>completed within one cycle. This did not happen in time for the
>release, and so we wound up with some projects testing stable/newton
>on 16.04 while others were testing on 14.04. Obviously we couldn't
>leave things in that state indefinitely or it would risk breaking
>some project dependencies entirely in that branch, so we pushed to
>get any remaining teams to finish uplifting their stable/newton
>testing to 16.04 soon thereafter.
>
>The result is still that upstream OpenStack, from a QA/testing
>perspective, considers stable/newton to "support" Ubuntu 16.04 LTS
>("latest Ubuntu LTS" at the time its development cycle began), and
>stable/mitaka is the last release we "supported" on Ubuntu 14.04
>LTS. Hopefully that is the answer you're seeking?
>-- 
>Jeremy Stanley
>
>__
>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] [all] Ubuntu 14.04 support in Newton and on

[Eric K]

Hi all, Is there any community-wide policy on how long we strive to maintain
compatibility with Ubuntu 14.04? For example by avoiding relying on MySQL
5.7 features.
I¹ve had a hard time finding it on openstack.org and ML discussions. Thanks
lots!


__
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] [Congress][Fuel] Fuel plugin for installing Congress

[Eric K]

Hi Serg,

That¹s awesome news. Thanks all for the great work!

Please do let us know how the Congress team can be helpful.

On 1/16/17, 11:33 AM, "Serg Melikyan"  wrote:

>I'd like to introduce you fuel plugin for installing and configuring
>Congress for Fuel [0].
>
>This plugin was developed by Fuel@Opnfv [1] Community in order to be
>included to the next release of the Fuel@Opnfv - Danube. We believe
>that this plugin might be helpful not only for us but also for general
>OpenStack community and decided to continue development of the plugin
>in the OpenStack Community.
>
>Please join us in the development of the Congress plugin, your
>feedback is greatly appreciated.
>
>P.S. Right now core team includes Fedor Zhadaev - original developer
>of the plugin, and couple of developers from Fuel@Opnfv including me.
>We considered adding congress-core to the list but decided to see
>amount of interest and feedback first from Congress team.
>
>References:
>[0] http://git.openstack.org/cgit/openstack/fuel-plugin-congress/
>[1] https://wiki.opnfv.org/display/Fuel/
>
>__
>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] [congress][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[Eric K]

On a freshly stacked devstack (Jan 12), attempting to access
`cfg.CONF.keystone_authtoken.project_domain_name` gave the error:
NoSuchOptError: no such option project_domain_name in group
[keystone_authtoken]

I¹m a little confused because it¹s part of the [keystone_authtoken] config
section generated by devstack. Could anyone point me to where these options
are declared (I¹ve searched several repos) and maybe why this option doesn¹t
exist? Thanks a lot!

Of all the options supplied by devstack under [keystone_authtoken], the
following were accessible:
memcached_servers
signing_dir
cafile
auth_uri
auth_url
auth_type

But the following were unaccessible:
project_domain_name
project_name
user_domain_name
password
username



__
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] [Congress] no meeting on December 29, 2016

[Eric K]

No congress team meeting on December 29, 2016. Regular meeting resumes on
January 5, 2016.

Happy holidays all!



__
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] [Congress] [infra] tempest job timeout appears shorter than configured

[Eric K]

The congress {pipeline}-congress-dsvm-api-{node}{suffix} check/gate job
seems to timeout around the 60 minute mark even though the project config
appears to set it for 70min. Any hints as to why? Are there two different
measures of time? Thanks so much!
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/c
ongress.yaml#L7

Here¹s an example: 
http://logs.openstack.org/24/410524/2/check/gate-congress-dsvm-api-ubuntu-xe
nial/45f6991/console.html


__
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] [gate][congress] subunit.parser failures in pythonXX gate job

[Eric K]

Hi all,

Does anyone know what could be causing these subunit.parser failures in
some pythonXX check jobs (they do not show up on my local setup). I
vaguely remember seeing them before, but can't remember what they were.
And haven't been able to find relevant info online or in lists. Thanks so
much!

Example:

FAIL: subunit.parser
tags: worker-0
Binary content:
Packet data (application/octet-stream)
Parser Error: {{{Bad checksum - calculated (0xc62b176a), stored
(0x494e464f)}}}

http://logs.openstack.org/29/254429/8/check/gate-congress-python27-ubuntu-x
enial/b3dacaf/testr_results.html.gz



__
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] [Congress] relevant horizontal efforts at PTG

[Eric K]

Hi all!
aimeeu asked during team meeting about relevant sessions on Monday and Tuesday.
I don't have anything official. I think it's more a matter of you and your 
org's interest in contributing to those horizontal efforts. 
If you're looking to contribute to a horizontal project, horizon, the community 
app catalog (I'm thinking about the TOSCA templates), and the architecture 
working group may complement congress quite well. I'm sure here are others that 
go well too.
__
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] [Congress] ekcs away

[Eric K]

Hi all!
I have personal travels planned 11/8 - 11/25. I expect to have intermittent 
access and keep up with reviews and ML, but will likely miss the IRC meetings. 
thinrichs, masahito, and ramineni have kindly agreed to organize the IRC 
meetings (UTC):
11/10: thinrichs11/17: masahito11/24: ramineni
Thanks all!__
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] [Congress] Barcelona 2016 summit recap

[Eric K]

Hi all,

Welcome back from a great summit!

Here¹s a brief recap of some Congress-related pieces.

1. Main conference
A keynote demo featured Doctor, Congress, and Vitrage. A cellular phone call
was made on an openstack NFV implementation. When network cables to a host
was cut, an immediate failover to a backup kept the phone call connected.
Congress was used as the component that decided and initiated a failover
operation in response to connection failure events.
A video of the demo is here: https://www.youtube.com/watch?v=Dvh8q5m9Ahk

Masahito and others gave a Doctor+Vitrage+Congress talk on applying Congress
for fault recovery in NFV.
https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199

2. Fishbowl session
We demoed policy monitoring and reactive enforcement features of Congress in
a fishbowl session. From the demo we got valuable discussion and feedback
from the audience. Notes here:
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.45v8uufo7tja

aheczko-mirantis discussed interest in using Congress to inspect
configurations affecting data access and multi-region data protection.
More notes: 
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.yah1udkwim5w

njohnston discussed interest in using Congress to inspect and monitor
Neutron-FWaaS rules. Key feature addition needed is CIDR arithmetic support
from Congress.
More notes: 
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.j0nqlvc7qrra

3. Work sessions
Use cases:
bryan_att on identifying OpNFV use cases that suits/needs Congress in
production:
* Policies for concrete use cases implemented
* Congress seems useful for detecting and helping avoid undesirable things,
e.g., insecure config, non-compliant workload placement,
* Some use cases implemented as test cases in OpNFV Copper:
https://wiki.opnfv.org/display/copper/testing
* More notes: 
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.7ihmxhzb7jce
aimeeu prepared a collection of Congress use-cases intended for evaluating
Congress applicability:
* Implemented policies have been added to the Congress Examples google doc.
https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zr
kSw/edit#heading=h.3jrxkmpkmd79
Vitrage: Ifat discussed Vitrage-Congress integration and how it can benefit
both projects to have the two services work well together and share data.
* Congress can make policy enforcement decisions based on rich policies and
Vitrage root-cause analysis and topology data.
> * e.g., Congress policy can decide to reconfigure network based on Vitrage
> identifying NIC failure
> * e.g., Congress policy can decide to evacuate host based on Vitrage
> identifying hard drive failure
* TODO: concretize compelling use cases, then develop Vitrage driver for
Congress
* More notes: 
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.hrnthxnp91y
Congress in OpNFV Doctor (masahito)
* Congress useful/needed in Doctor because what constitutes a failure and
what response is required are highly dependent on the context of a
deployment
* Congress policy language useful for defining failure conditions and
responses.
* More notes: 
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.lfxkbthngwi

Ocata Priorities
Based on our discussions, we want to focus on:
* Robustness and stability fixes
* Out-of-the-box policies
* CIDR math built-in for policies language
Many other desirable features were discussed. So we have plenty of good
ideas going forward:
https://docs.google.com/document/d/1Qg4ApwKHC__X-Pidnj4jGfFpxS6x5__UVHKV1TPv
LXI/edit#heading=h.mxy6o92kzi4b

Looking forward to having a great Ocata cycle with everyone!


__
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] [Congress] Restart Congress server

[Eric K]

Hi Ruben,

Awesome to hear about your progress!

The error seems to be independent of adding a new driver.

Could you try using the unchanged congress.conf and restarting again to
see if the same problem shows up?

Also, could you give the command you¹re using the launch congress-server?

Mainly I want to understand whether you¹re using single-process congress
deployment or multi-process congress deployment. If multi-process, it¹s
possible that the datasources process was stopped but wasn¹t restarted.


If your screen listing (access by pressing Ctrl-A followed by ") shows
three congress windows like this, then you¹re running in multi-process
mode:
29 congress-api
$(L)
  30 congress-engine
  $(L)
  31 congress-datasources
  $(L)

To launch Congress, make sure all three are running properly.

A simpler alternative (but takes some time) is to deploy devstack from
scratch (saving your work somewhere of course) using the latest versions
(defaults to single process), which should reduce complications from
multiple processes and make everything easier for dev-testing.

All the best!



On 11/4/16, 4:53 AM, "Ruben"  wrote:

>Hi everyone,
>I've tried to write a datasource driver for Magnum and the unit test for
>it.
>So I've add this datasource driver in
>/opt/stack/congress/congress/datasources/ and the unit test in
>/opt/stack/congress/congress/tests/datasources/ to test it.
>Moreover, I've add the driver to /etc/congress/congress.conf, but when I
>try to restart Congress server I've some errors.
>
>
>"2016-11-04 12:13:00.390 TRACE congress.service self.service_id,
>service, table)
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 468, in
>subscribe_table
>2016-11-04 12:13:00.390 TRACE congress.service {'table': table})
>2016-11-04 12:13:00.390 TRACE congress.service   File
>"/opt/stack/congress/congress/dse2/dse_node.py", line 355, in
>invoke_service_rpc
>2016-11-04 12:13:00.390 TRACE congress.service raise
>exception.NotFound(msg % service_id)
>2016-11-04 12:13:00.390 TRACE congress.service NotFound: service 'nova'
>could not be found
>2016-11-04 12:13:00.390 TRACE congress.service
>2016-11-04 12:13:00.537 DEBUG oslo_concurrency.lockutils [-] Acquired
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:212
>2016-11-04 12:13:00.538 DEBUG oslo_concurrency.lockutils [-] Releasing
>semaphore "singleton_lock" from (pid=24411) lock
>/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225"
>
>I don't know what to do to solve it and even if the driver I've written
>works.
>Maybe I make mistakes when I restart Congress server..
>What should I do to restart Congress server?
>What could I do to test the datasource and solve these problems?
>
>Ruben



__
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] [Congress] IRC during summit

[Eric K]

Hi all!

To help us connect and coordinate during the upcoming summit, those who are
interested can try IRCcloud (https://www.irccloud.com ; suggested by aimeeu)
to communicate over the #congress channel. The service acts as an IRC
bouncer to keep your nick connected and send push notifications to the
mobile app. I just tried it out and it works pretty well.

To be notified of all messages on the channel, set your mobile app to
³Notify on all messages² (under display options). To be notified only of
messages that mention your nick, just keep the default settings.

See you all at the summit soon!


__
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] [Congress] PTG planning

[Eric K]

Based on ML and IRC discussions and the feedback that almost all of us
expect to be able to make the PTG, I have put down our team for work
sessions at the PTG.

I'm looking forward to interacting with more project teams in Atlanta.

Thanks all!

On 10/7/16, 3:24 AM, "Masahito MUROI" <muroi.masah...@lab.ntt.co.jp> wrote:

>Thanks summarizing it, Eric.
>
>Combination of 1. and 2. looks good.
>
>Basically, we'll have work sessions in PTG for next release. Other teams
>and operator could come, so it's easy for Congress team to discuss
>anything with them.
>
>Then if needed, we can have unofficial work session of Congress team at
>summit instead of mid-cycle. We don't need to consider hosts and
>location. Additionally, we could meet Congress user who has a
>presentation and nice usecase but doesn't contribute actively.
>
>best regards,
>Masahito
>
>On 2016/10/06 16:53, Thierry Carrez wrote:
>> Good summary. It is true that for small-to-medium sized teams (which did
>> not routinely organize midcycles), there is a tough choice to make.
>>
>> See a couple of remarks inline:
>>
>> Eric K wrote:
>>> Here are some of our choices as a team, as well as some first thoughts
>>>on
>>> pros and cons:
>>>
>>> 1. Do work sessions at PTGs; no organized work sessions at summits.
>>> Pro: schedule lines up wit beginning of dev cycle
>>> Pro: work room available
>>> Pro: easy to collaborate with other teams
>>> Con: extra travel for those who will continue to attend summit.
>>
>> +Pro: PTGs are organized in cheaper locations and closer to the center
>> of mass of contributors, hopefully making it less costly to travel to
>> overall
>> +Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
>> better return on travel investment
>>
>>> 2. Unofficial work session at summits; no work sessions at PTGs.
>>> Pro: For people who would be going to the summits anyway, this option
>>> reduces travel.
>>> Con: probably no official work room available.
>>> Con: happens at the middle of a dev cycle
>>>
>>> 3. Separately organize work sessions in the style of past mid-cycle
>>> sprints; no work sessions at any of the official openstack events.
>>> Pro: we can choose schedule and location
>>> Con: harder to collaborate with other teams
>>
>> +Con: extra travel for those who will continue to attend summit
>>
>
>
>-- 
>室井 雅仁(Masahito MUROI)
>Software Innovation Center, NTT
>Tel: +81-422-59-4539
>
>
>
>__
>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] [Congress] PTG planning

[Eric K]

Thanks for the additional notes, Thierry!

On 10/6/16, 12:53 AM, "Thierry Carrez" <thie...@openstack.org> wrote:

>Good summary. It is true that for small-to-medium sized teams (which did
>not routinely organize midcycles), there is a tough choice to make.
>
>See a couple of remarks inline:
>
>Eric K wrote:
>> Here are some of our choices as a team, as well as some first thoughts
>>on
>> pros and cons:
>> 
>> 1. Do work sessions at PTGs; no organized work sessions at summits.
>> Pro: schedule lines up wit beginning of dev cycle
>> Pro: work room available
>> Pro: easy to collaborate with other teams
>> Con: extra travel for those who will continue to attend summit.
>
>+Pro: PTGs are organized in cheaper locations and closer to the center
>of mass of contributors, hopefully making it less costly to travel to
>overall
>+Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
>better return on travel investment
>
>> 2. Unofficial work session at summits; no work sessions at PTGs.
>> Pro: For people who would be going to the summits anyway, this option
>> reduces travel.
>> Con: probably no official work room available.
>> Con: happens at the middle of a dev cycle
>> 
>> 3. Separately organize work sessions in the style of past mid-cycle
>> sprints; no work sessions at any of the official openstack events.
>> Pro: we can choose schedule and location
>> Con: harder to collaborate with other teams
>
>+Con: extra travel for those who will continue to attend summit
>
>-- 
>Thierry Carrez (ttx)
>
>__
>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] [Congress] PTG planning

[Eric K]

Here are some of our choices as a team, as well as some first thoughts on
pros and cons:

1. Do work sessions at PTGs; no organized work sessions at summits.
Pro: schedule lines up wit beginning of dev cycle
Pro: work room available
Pro: easy to collaborate with other teams
Con: extra travel for those who will continue to attend summit.

2. Unofficial work session at summits; no work sessions at PTGs.
Pro: For people who would be going to the summits anyway, this option
reduces travel.
Con: probably no official work room available.
Con: happens at the middle of a dev cycle

3. Separately organize work sessions in the style of past mid-cycle
sprints; no work sessions at any of the official openstack events.
Pro: we can choose schedule and location
Con: harder to collaborate with other teams

4. No work sessions at all.

On 10/5/16, 4:18 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:

>Hi all,
>
>As you know, the traditional design summit will be split into the work
>sessions at PTGs and the community forums at the summits. The release
>schedules will be re-aligned so that the PTGs coincide with the beginning
>of the dev cycle for each release.
>http://www.openstack.org/ptg
>
>As a team, we are asked to decide whether we want to have work sessions at
>the upcoming PTG in in Atlanta (Feb 20-24) to kick-off the P-cycle. We¹re
>asked to have a decision no later than Oct 16, so hopefully we can discuss
>it over ML and the next couple meetings and come up with a decision.
>
>Some more details on the schedule at the first PTG:
>> The first Project Teams Gathering will happen in Atlanta, Feb 20-24,
>> 2017. We'll provide a separate room for every (non-single-vendor)
>> project team that asks for one, and each team will be able to organize
>> its own agenda (similar to what happens at mid-cycle sprints).
>
>> Horizontal teams (Infrastructure, Documentation, QA...) and
>> cross-project workgroups will meet on Monday-Tuesday (Monday optional).
>> Vertical teams (Nova, Cinder, Swift...) will meet on Wednesday-Friday
>> (Friday optional). Teams that fall in between (Packaging, Kolla,
>> Horizon...) might be placed with horizontal or vertical teams, depending
>> on room availability. Attendees will be encouraged to pick one
>> horizontal effort and one vertical team and attend the whole week,
>> although they can of course opt to only attend a single team meeting.
>
>



__
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] [Congress] PTG planning

[Eric K]

Hi all,

As you know, the traditional design summit will be split into the work
sessions at PTGs and the community forums at the summits. The release
schedules will be re-aligned so that the PTGs coincide with the beginning
of the dev cycle for each release.
http://www.openstack.org/ptg

As a team, we are asked to decide whether we want to have work sessions at
the upcoming PTG in in Atlanta (Feb 20-24) to kick-off the P-cycle. We¹re
asked to have a decision no later than Oct 16, so hopefully we can discuss
it over ML and the next couple meetings and come up with a decision.

Some more details on the schedule at the first PTG:
> The first Project Teams Gathering will happen in Atlanta, Feb 20-24,
> 2017. We'll provide a separate room for every (non-single-vendor)
> project team that asks for one, and each team will be able to organize
> its own agenda (similar to what happens at mid-cycle sprints).

> Horizontal teams (Infrastructure, Documentation, QA...) and
> cross-project workgroups will meet on Monday-Tuesday (Monday optional).
> Vertical teams (Nova, Cinder, Swift...) will meet on Wednesday-Friday
> (Friday optional). Teams that fall in between (Packaging, Kolla,
> Horizon...) might be placed with horizontal or vertical teams, depending
> on room availability. Attendees will be encouraged to pick one
> horizontal effort and one vertical team and attend the whole week,
> although they can of course opt to only attend a single team meeting.



__
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] [Congress] ceilometer client `alarms.list()` HTTPException (HTTP N/A)

[Eric K]

Got it. Thanks for the refresher.Maybe it got re-enabled in the switch to 
support lazy polling.
If you get a chance, would you mind disabling it again for Newton?



_
From: Anusha Ramineni <anusha.ii...@gmail.com>
Sent: Friday, September 30, 2016 4:26 AM
Subject: Re: [openstack-dev] [ceilometer] [Congress] ceilometer client 
`alarms.list()` HTTPException (HTTP N/A)
To: Eric K <ekcs.openst...@gmail.com>, OpenStack Development Mailing List (not 
for usage questions) <openstack-dev@lists.openstack.org>


Hi Eric,
alarm list is not working from before. I have disabled the same in Mitaka 
https://review.openstack.org/#/c/254650/We need to support Aodh to get it 
working I suppose 
(https://blueprints.launchpad.net/congress/+spec/add-aodh-datasource-driver)

Best Regards,Anusha
On 29 September 2016 at 19:28, Julien Danjou <jul...@danjou.info> wrote:
On Mon, Sep 26 2016, Eric K wrote:

> On a fresh devstack install with ceilometer clients version 2.6.1,
> client.alarms.list() errors when other things (like client.events.list())
> succeeds.

Do you have Aodh installed?
Why not switching to aodhclient?

--
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





  __
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] [Congress] ceilometer client `alarms.list()` HTTPException (HTTP N/A)

[Eric K]

Hi all,

Looking for some help to resolve a breakage in Congress ceilometer-driver.
When Congress attempts to perform `alarms.list()` on ceilometer client,
the following exception is generated.
First suspicion is Congress-end configuration problem, but it¹s only
`alarms.list()` that fails. Others such as `events.list()` succeeds.

I¹ve reproduced it here in a small example. Any thoughts on how we could
resolve or work around it? Thanks a ton!

On a fresh devstack install with ceilometer clients version 2.6.1,
client.alarms.list() errors when other things (like client.events.list())
succeeds.


Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from keystoneauth1 import session # Version 2.12.1
>>> from keystoneauth1.identity import v2
>>> import ceilometerclient.client as cc
>>> auth = v2.Password(auth_url='http://192.168.218.145:5000/v2.0',
>>>username='admin', password='password', tenant_name='admin')
>>> sess = session.Session(auth=auth)
>>> client = cc.get_client(version='2', session=sess)
>>> client.events.list()  # succeeds
[]
>>> client.alarms.list()  # fails
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/lib/python2.7/dist-packages/ceilometerclient/v2/alarms.py",
line 83, in list
return self._list(options.build_url(self._path(), q))
  File 
"/usr/local/lib/python2.7/dist-packages/ceilometerclient/common/base.py",
line 63, in _list
resp = self.api.get(url)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py",
line 187, in get
return self.request(url, 'GET', **kwargs)
  File 
"/usr/local/lib/python2.7/dist-packages/ceilometerclient/client.py", line
473, in request
raise exc.from_response(resp, body)
ceilometerclient.exc.HTTPException: HTTPException (HTTP N/A)


Same information filed in bug:
https://bugs.launchpad.net/python-ceilometerclient/+bug/1626404



__
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] [Congress] error updating from nova

[Eric K]

Hi all,

I ran into this issue when Congress or Horizon attempts to get information
from Nova. Same thing happened on multiple devstack attempts. But I want to
make sure it's not something specific to my environment. Could someone try
to reproduce it? Thanks!
Nova client version: 6.0.0
Here¹s a bug report I filed for horizon and nova:
https://bugs.launchpad.net/nova/+bug/1626216
Here¹s the error trace I get in congress-datasources.log:
2016-09-21 13:14:25.478 ERROR congress.datasources.datasource_driver [-]
Datasource driver raised exception
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
Traceback (most recent call last):
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1384,
in poll
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
self.update_from_datasource()  # sets self.state
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1371,
in update_from_datasource
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
self.update_methods[registered_table]()
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/opt/stack/congress/congress/datasources/nova_driver.py", line 207, in

2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
self.nova_client.flavors.list())
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/novaclient/v2/flavors.py", line 132,
in list
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
return self._list("/flavors%s%s" % (detail, query_string), "flavors")
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/novaclient/base.py", line 249, in
_list
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
resp, body = self.api.client.get(url)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 187,
in get
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
return self.request(url, 'GET', **kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line 107, in
request
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
**kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 344,
in request
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 112,
in request
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
return self.session.request(url, method, **kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line 101,
in inner
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
return wrapped(*args, **kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 555,
in request
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
resp = send(**kwargs)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver   File
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 599,
in _send_request
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
raise exceptions.ConnectFailure(msg)
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
ConnectFailure: Unable to establish connection to
http://192.168.218.145:8774/v2.1/flavors/detail
2016-09-21 13:14:25.478 TRACE congress.datasources.datasource_driver
2016-09-21 13:14:25.503 INFO congress.datasources.datasource_driver [-]
nova:: finished polling



__
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] [Congress] Default devstack deployment config

[Eric K]

Thanks, Anusha!

I agree with keeping both options, just using single proc as default.

Added a bug on it: https://bugs.launchpad.net/congress/+bug/1624172

From:  Anusha Ramineni <anusha.ii...@gmail.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:  Monday, September 19, 2016 at 2:05 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [Congress] Default devstack deployment config

> Hi All,
> 
> I too agree from the development point of view, its easier if we have a single
> process.
> But I was wondering, tempest jobs we run on gate, isn't it better they run
> with 3 processes deployed, to make sure it works across processes too?
> 
> Just a thought, how about we keep both the options, so that developers can
> deploy as single process and on gate we can test it with different processes?
> 
> Best Regards,
> Anusha
> 
> On 13 September 2016 at 18:10, Aimee Ukasick <aimeeu.opensou...@gmail.com>
> wrote:
>> I completely agree with a single process deployment for DevStack. I
>> ran into issues last week with the multiple process configuration
>> while I trying to pinpoint an error.  I was using the pdb command line
>> debugger to step through Congress and Oslo Messaging, making a call
>> from the CLI. More than once the Congress API couldn't find the
>> Process Engine, which I'm sure was caused by uploading code and
>> stopping/starting services in the wrong order.  Deploying single
>> process Congress to DevStack would have saved me a lot of time.
>> 
>> aimee
>> 
>> On Tue, Sep 13, 2016 at 1:42 AM, Masahito MUROI
>> <muroi.masah...@lab.ntt.co.jp> wrote:
>>> > Hi Congress folks,
>>> >
>>> > I'm in favor of single process for devstack default. It's easy to check
>>> > logs and tests its feature.
>>> >
>>> > best regards,
>>> > Masahito
>>> >
>>> > On 2016/09/13 11:00, Tim Hinrichs wrote:
>>>> >>
>>>> >> I'd agree with a single process version of Congress for devstack.  I'd
>>>> >> say we should even do that for Newton.
>>>> >>
>>>> >> Tim
>>>> >>
>>>> >> On Mon, Sep 12, 2016 at 6:34 PM Eric K <ekcs.openst...@gmail.com
>>>> >> <mailto:ekcs.openst...@gmail.com>> wrote:
>>>> >>
>>>> >> Hi all,
>>>> >>
>>>> >> I want to get people’s thoughts regarding what we should set as
>>>> >> default devstack deployment config for Ocata.
>>>> >> At the moment, it is set to deploy three processes: API, policy, and
>>>> >> datasource-drivers.
>>>> >>
>>>> >> I see some potential arguments against that:
>>>> >>
>>>> >>  1. For most users installing via devstack, running Congress in
>>>> >> three processes bring little benefit, but rather a more complex
>>>> >> and less stable user experience. (Even if our code is perfect,
>>>> >> rabbitMQ will timeout every now and then)
>>>> >>  2. It’s not clear that we want to officially support separating the
>>>> >> API from the policy engine at this point. The supported
>>>> >> deployment options for HAHT do not need it.
>>>> >>
>>>> >> The main argument I see for deploying three processes by default is
>>>> >> that we may get more bug reports regarding the multi-process
>>>> >> deployment that way.
>>>> >>
>>>> >> Our main options for devstack default are:
>>>> >> 1. Single-process Congress (with in-mem transport).
>>>> >> 2. Two-process Congress API+Policy, datasource-drivers. (other
>>>> >> breakdowns between two processes are also possible)
>>>> >> 3. Three-process Congress.
>>>> >>
>>>> >> In the end, I think it’s a trade-off: potentially getting more bug
>>>> >> reports from users, at the expense of a more complex and less
>>>> >> polished user experience that could make a poor first impression.
>>>> &

Re: [openstack-dev] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

[Eric K]

Anusha and Aimee,

Circling back on this issue: it seems that you are seeing different things
with regards to horizon authentication using keystone v2. I think we can
make good progress if we can clarify where we stand.

Anusha said setting the auth_url explicitly to v2 works. Aimee said it
didn¹t.

So just to clarify:

1. Anusha did you mean set this line
https://github.com/openstack/congress/blob/master/congress_dashboard/api/co
ngress.py#L75
To:
`auth_url = 'http://:5000/v2.0¹` ?

2. Aimee, is that what you tried?

3. Do you still get different results?

>From Anusha¹s commit message in this patch
(https://review.openstack.org/#/c/305063/), the current code should fail
because `auth_url = getattr(settings, 'OPENSTACK_KEYSTONE_URL¹)`[L75]
grabs the .../v3 URL (devstack default), yet `auth =
keystoneclient.auth.identity.v2.Token(`[L77] expects a .../v2.0 URL. So
could we have a workaround simply by doing something like `auth_url =
auth_url.replace('v3', 'v2.0¹)`? (*)

Thanks again for all the investigative work!

Eric

(*) Another potential issue is ports:
https://ask.openstack.org/en/question/67846/difference-between-keystone-por
t-5000-and-35357/

On 7/22/16, 9:06 AM, "Aimee Ukasick"  wrote:

>All - I made the change to the auth_url that  Anusha suggested.
>Same problem as before " Cannot authorize API client"
>2016-07-22 14:13:50.835861 * calling policies_list =
>client.list_policy()*
>2016-07-22 14:13:50.836062 Unable to get policies list: Cannot
>authorize API client.
>
>I used the token from the log output to query the Congress API with
>the keystone v3 token - no issues.
>curl -X GET -H "X-Auth-Token: 18ec54ac811b49aa8265c3d535ba0095" -H
>"Cache-Control: no-cache" "http://192.168.56.103:1789/v1/policies;
>
>So I really think the problem is that the python-congressclient
>doesn't support identity v3.
>I thought it did, but then I came across this:
>"support keystone v3 api and session based authentication "
>https://bugs.launchpad.net/python-congressclient/+bug/1564361
>This is currently assigned to Anusha.
>I'd like to start work on it since I am becoming familiar with keystone
>v3.
>
>Thoughts?
>
>aimee
>
>
>
>
>On Fri, Jul 22, 2016 at 8:07 AM, Aimee Ukasick
> wrote:
>> Thanks Anusha! I will retest this today. I guess I need to learn more
>> about Horizon as well - thanks for pointing me in the right direction.
>>
>> aimee
>>
>>
>>
>> On Fri, Jul 22, 2016 at 6:30 AM, Anusha Ramineni
>> wrote:
>>> Hi Aimee,
>>>
>>> I think devstack by default configured horizon to use v3 .
>>> For V2 authentication, from the logs , auth_url doesn't seem to be set
>>> explicitly to v2 auth_url .
>>>
>>> I have always set explicit v2 auth which worked fine.
>>> For eg:- auth_url = 'http://:5000/v2.0' , for V2
>>>authentication
>>>
>>> I have raised a patch, to take the auth_url from horizon settings
>>>instead of
>>> from request.
>>> https://review.openstack.org/#/c/345828/1
>>>
>>> Please set explict v2 auth_url as mentioned above in
>>>OPENSTACK_KESYTONE_URL
>>> in /openstack_dashboard/local/local_settings.py and restart
>>>apache2
>>> server . Then v2 authentication should go through fine.
>>>
>>> For v3 , need to add relevant code for v3 authentication in
>>>contrib/horizon
>>> as presently it is hardcoded to use only v2. but yes, the code from
>>>plugin
>>> model patch is still a WIP , so doesn't work for v3 authentication I
>>>guess
>>> I'll have a look at it and let you know .
>>>
>>>
>>> Best Regards,
>>> Anusha
>>>
>>> On 21 July 2016 at 21:56, Tim Hinrichs  wrote:

 So clearly an authentication problem then.

 Anusha, do you have any ideas?  (Aimee, I think Anusha has worked with
 Keystone authentication most recently, so she's your best bet.)

 Tim

 On Thu, Jul 21, 2016 at 8:59 AM Aimee Ukasick
  wrote:
>
> The  Policy/Data Sources web page throws the same errors. I am
> planning to recheck direct API calls using v3 auth today or tomorrow.
>
> aimee
>
> On Thu, Jul 21, 2016 at 10:49 AM, Tim Hinrichs  wrote:
> > Hi Aimee,
> >
> > Do the other APIs work?  That is, is it a general problem
> > authenticating, or
> > is the problem limited to list_policies?
> >
> > Tim
> >
> > On Wed, Jul 20, 2016 at 3:54 PM Aimee Ukasick
> > 
> > wrote:
> >>
> >> Hi all,
> >>
> >> I've been working on Policy UI (Horizon): Unable to get policies
> >> list (devstack) (https://bugs.launchpad.net/congress/+bug/1602837)
> >> for the past 3 days. Anusha is correct - it's an authentication
> >> problem, but I have not been able to fix it.
> >>
> >> I grabbed the relevant code in congress.py from Anusha's horizon
> >> plugin model patchset (https://review.openstack.org/#/c/305063/3)
>and
> >> 

[openstack-dev] [Congress] Default devstack deployment config

[Eric K]

Hi all,

I want to get people¹s thoughts regarding what we should set as default
devstack deployment config for Ocata.
At the moment, it is set to deploy three processes: API, policy, and
datasource-drivers.

I see some potential arguments against that:
1. For most users installing via devstack, running Congress in three
processes bring little benefit, but rather a more complex and less stable
user experience. (Even if our code is perfect, rabbitMQ will timeout every
now and then)
2. It¹s not clear that we want to officially support separating the API from
the policy engine at this point. The supported deployment options for HAHT
do not need it.
The main argument I see for deploying three processes by default is that we
may get more bug reports regarding the multi-process deployment that way.

Our main options for devstack default are:
1. Single-process Congress (with in-mem transport).
2. Two-process Congress API+Policy, datasource-drivers. (other breakdowns
between two processes are also possible)
3. Three-process Congress.

In the end, I think it¹s a trade-off: potentially getting more bug reports
from users, at the expense of a more complex and less polished user
experience that could make a poor first impression. What does everyone
think?

Personally, I slightly favor defaulting to single process Congress because
from a typical devstack user¹s perspective, there is little reason to run
separate processes. In addition, because it is the first time we¹re
releasing our complete architecture overhaul to the wild, and it may be a
good to default to the least complex deployment for the first cycle of the
new architecture.


__
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] [Congress] PTL candidacy

[Eric K]

Hi all!

I¹m writing to announce my candidacy for Congress PTL (Ocata).

First, I¹d like to thank Tim for his outstanding leadership since the very
beginning of the project.  Under his leadership, Congress has grown from an
interesting idea to a capable service.  I would also like to thank everyone
for
their tremendous support in bringing me along as a Congress contributor,
from
first learning the codebase to leading the high-availability design and
implementation efforts.  I¹m truly grateful to be a part of such a
welcoming,
collaborative and supportive community.

For the Ocata cycle, my main focus for Congress is usability and
ease-of-adoption.  For example, by shipping Congress with pre-built policies
and templates, Congress would provide useful policy-based monitoring fresh
out-of-the-box, its time-to-value improving from weeks to under a day.  I
also
aim to continue prioritizing user engagement, cross-project collaboration,
and
code robustness.  Last but not least, I look forward to supporting our
project
members in their goals and visions for Congress.

Thank you all once again!

-- Eric J. Kao


__
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] [Congress] PTL non-candidacy

[Eric K]

Thank you so much, Tim, for spearheading and guiding the project all this
time!  I'm especially grateful for your emphasis on supporting the
development and the goals of the contributors. I hope we'll continue to
benefit from your vision and your thought-leadership in the future!

Eric

From:  Tim Hinrichs 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Monday, September 12, 2016 at 8:20 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  [openstack-dev] [Congress] PTL non-candidacy

> Hi all,
> 
> I've decided it's time to step down as PTL of Congress.  Partly because I have
> so many outside responsibilities, and partly because we have such a strong
> team, the time is right for someone else to lead the project.  We've made so
> much progress over the past couple of years, and there's so much left to do.
> I'm truly excited to see someone's ideas for setting direction and interacting
> with the community.  Should be a ton of fun!
> 
> Tim
> __
> 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] [Congress] Enabling Remote Debugging

[Eric K]

Hi Aimee,

Thanks for digging into it!

Here¹s my understanding of our conventions (and I¹m happy to hear from
others).

a. If you think it¹s just a straightforward change with zero to minimal
impact on architecture, users, and devs, then it makes sense to file a bug
or just submit a patch.
b. If you think it warrants deeper discussion in terms of design, impact,
etc., then the process is to create a spec and associated blueprint. See
this wiki for more details:
https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle

In case (b), the change should target the O-cycle because we¹re past
feature-freeze in N.
In case (a), it may make sense to get it in during the N-cycle if it has
minimal impact and will help us in the N-cycle QA process.

My guess is we¹re in case (a) because we can make sure changes have no
impact without a special flag. But I¹d also like to understand a little
better the impact of eventlet.monkey_patch(thread=False) as done in the
Keystone patch (https://review.openstack.org/#/c/18404/3/bin/keystone-all).

Enjoy the time holidays!

On 9/1/16, 11:45 AM, "Aimee Ukasick"  wrote:

>HI all - I've been trying to configure remote debugging with PyCharm
>and DevStack. It looks like some tiny modifications need to be made to
>the Congress code (3-4 files) to support remote debugging via pydevd.
>
>As far as I can tell, support has been added to Keystone, Glance,
>Nova, and Manilla (and I'm sure others).
>
>Keystone patch: https://review.openstack.org/#/c/18404/3
>Glance patch: https://review.openstack.org/#/c/18748/5
>
>I think it would be very beneficial to support remote debugging, and
>I'm willing to implement the changes needed. Should I create a bug for
>this or draft a blueprint?
>
>I'm out of office 2-5 Sept for the US Labor Day holiday, so I could
>start on this on 6 Sept.
>
>As always, I appreciate all your comments.
>
>Thanks.
>
>aimee
>
>irc:aimeeu
>
>__
>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] [oslo] RPC call not appearing to retry

[Eric K]

On 8/16/16, 9:28 AM, "Mehdi Abaakouk" <sil...@sileht.net> wrote:

>Hi,
>
>Le 2016-08-15 04:50, Eric K a écrit :
>> Hi all, I'm running into an issue with oslo-messaging PRC call not
>> appearing to retry. If I do oslo_messaging.RPCClient(transport, target,
>> timeout=5, retry=10).call(self.context, method, **kwargs) using a topic
>> with no listeners, I consistently get the MessagingTimeout exception in
>> 5
>> seconds, with no apparent retry attempt. Any tips on whether this is a
>> user error or a bug or a feature? Thanks so much!
>
>About retry, from 
>http://docs.openstack.org/developer/oslo.messaging/rpcclient.html:
>
>"By default, cast() and call() will block until the message is
>successfully sent. However, the retry parameter can be used to have
>message sending fail with a MessageDeliveryFailure after the given
>number of retries."
>
>It looks like it retries in case of MessageDeliveryFailure not
>MessagingTimeout.
>
>Cheers,
>
>-- 
>Mehdi Abaakouk
>mail: sil...@sileht.net
>irc: sileht

Thank you, Mehdi! I¹ll assume that going forward.

>From the way the doc is worded and from the example that followed, it
sounded like setting the retry parameter changes the eventual exception
thrown after the retries are exhausted, not that it retries on that
exception.
"the retry parameter can be used to have message sending fail with a
MessageDeliveryFailure after the given number of retries."

I wonder what the true intended behavior is. Thanks again!

Cheers,

Eric



__
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] [oslo] RPC call not appearing to retry

[Eric K]

Hi all, I'm running into an issue with oslo-messaging PRC call not
appearing to retry. If I do oslo_messaging.RPCClient(transport, target,
timeout=5, retry=10).call(self.context, method, **kwargs) using a topic
with no listeners, I consistently get the MessagingTimeout exception in 5
seconds, with no apparent retry attempt. Any tips on whether this is a
user error or a bug or a feature? Thanks so much!

It happens with both drivers rabbit and kombu+memory (oslo.messaging:
5.7.0; rabbitmq-server: 3.2.4-1).




__
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] [Congress] Mascot

[Eric K]

Thanks Tim!

Here¹s another idea. It¹s pretty euro-centric, but well.

Areopagus:
* a place where (in Greek Mythology) Ares was tried by the other gods for
murder.
* also the site of an early governing council in ancient Athens, at one
point charged with investigating corruption
* https://en.wikipedia.org/wiki/Areopagus
For a policy service, I think it¹s very appropriate to choose the site of a
prominent ancient council that is connected to one of the earliest
democracies (Athens). It¹s also kind of cool that the investigating
corruption is kind of like Congress identifying cases when services are
operating out of compliance with policy. Finally, it also just sounds cool.

The biggest drawback for me is that it may be hard to design a distinctive
logo based on a big rockŠ But maybe that can be overcome.
Here are some more stylized pictures a logo could be based on.
the-areopagus-where-the-city-court-would-meet-to-debate-matters-of-G38A8N.jp
g 

the-areopagus-and-the-theseum-greece-circa-1906-GCYH13.jpg
 
https://cdn.shopify.com/s/files/1/1021/8371/products/XGL8_010.jpeg?v=1447268
102

Between salamander, raven, and baboon, I¹d prefer salamander (could look
like a cute gecko) because it¹s just hard for a raven logo not to look
ominous and negative.
On the baboons, there is some dispute over whether a collection of baboons
is called a congress. Here¹s some discussion:
http://www.barrypopik.com/index.php/new_york_city/entry/a_gathering_of_baboo
ns_is_called_a_congress
From:  Tim Hinrichs 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Friday, July 15, 2016 at 5:52 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  [openstack-dev] [Congress] Mascot

> Hi all,
> 
> As a reminder, we need to come up with a list of 2-3 mascots so the OpenStack
> Foundation can choose 1 and turn it into a logo for Congress.  The mascots
> must come from the natural world (animals, plants, mountains, waterfalls,
> etc.).  Deadline is July 27.
> 
> I'll get the thread started with the following animal suggestions, all of
> which are called a 'congress' when there is a group of them.
> 
> salamander
> raven
> baboon
> 
> Any other suggestions?  Any preferences among those 3?  I'm not a fan of
> baboon.
> 
> Tim
> __
> 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] [Congress] Progress on Congress support in OPNFV Colorado

[Eric K]

Very exciting development indeed!

From:  "SULLIVAN, BRYAN L" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, June 14, 2016 at 8:58 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

Cc:  "opnfv-tech-disc...@lists.opnfv.org"

Subject:  [openstack-dev] [Congress] Progress on Congress support in OPNFV
Colorado

> Hi Congress team,
>  
> A quick update on progress at OPNFV on integrating Congress into the OPNFV
> Colorado release (Mitaka-based). With the help of RedHat (Dan Radez) and
> Canonical (Narinder Gupta, Liam Young) we are getting very close to
> upstreaming two key things to OpenStack:
> - Congress Puppet module
> 
> o  https://github.com/radez/puppet-congress has been tested successfully for
> the OPNFV Colorado release on Centos 7 hosts.
> 
> o  This will be used in the base OPNFV deploy for the Apex project (RDO-based
> installer).
> 
> o  Dan is in the process of creating the official Puppet repo at
> https://github.com/openstack/puppet-congress
> 
> - Congress JuJu Charm
> 
> o  https://github.com/gnuoy/charm-congress has been tested successfully for
> the OPNFV Colorado release on Ubuntu Trusty and Xenial hosts.
> 
> o  This will be used in the base OPNFV deploy for the JOID project
> (MAAS/JuJu-based installer).
> 
> o  Canonical has asked me to initiate the creation of the
> https://github.com/openstack/charm-congress repo to host this. I¹d appreciate
> any help/pointers as to how to get that started.
> 
>  
> This module and charm will help other OPNFV projects (e.g. Doctor) as Congress
> will be installed by default on the OPNFV platform, with the necessary
> datasource drivers and configuration ready to go.
>  
> I have three policy test cases that are working reliably for Mitaka (see
> https://git.opnfv.org/cgit/copper/tree/tests), soon to be integrated into the
> OPNFV CI/CD program, and will demo them at the upcoming OPNFV Summit in Berlin
> next week. I¹ll be adding other tests and developing a tested policy library
> once I get over the hurdles of completing the installer support (including for
> FUEL and Compass, the other two OPNFV installer projects).
>  
> Feels like it¹s been a long road, but also that we are nearing a major
> milestone!
>  
> Thanks,
> Bryan Sullivan | AT
>  
> __
> 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] [Congress] Austin recap

[Eric K]

Thanks for the summary, Tim. Very productive summit!

I¹ve added more notes and a diagram to the HA ether pad. Is that the best
way to continue the discussion?
https://etherpad.openstack.org/p/newton-congress-availability


From:  Tim Hinrichs 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, May 3, 2016 at 11:37 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  [openstack-dev] [Congress] Austin recap

> Hi all,
> 
> 
> Here¹s a quick summary of the Congress activities in Austin.  Everyone should
> feel free to chime in with corrections and things I missed.
> 
> 
> 1. Talks
> Masahito gave a talk on applying Congress for fault recovery in the context of
> NFV.
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199
> 
> 
> 
> Fabio gave a talk on applying Congress + Monasca to enforce application-level
> SLAs.
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7363
> 
> 
> 
> 2. Integrations
> We had discussions, both within the Congress Integrations fishbowl session,
> and outside of that session on potential integrations with other OpenStack
> projects.  Here's a quick overview.
> 
> 
> - Monasca (fabiog). The proposed integration: Monasca pushes data to Congress
> using the push driver to let Congress know about the alarms Monasca
> configured.  Can use multiple alarms using a single table.  Eventually we
> talked about having Congress analyze the policy to configure the alarms that
> Monasca uses, completing the loop.
> 
> 
> - Watcher (acabot). Watcher aims to optimize the placement of VMs by pulling
> data from Ceilometer/Monasca and Nova (including affinity/anti-affinity info),
> computing necessary migrations for whichever strategy is configured, and
> migrates the VMs.  Want to use Congress as a source of policies that they take
> into account when computing the necessary migrations.
> 
> 
> - Nova scheduler.  There¹s interest in policy-enabling the Nova scheduler, and
> then integrating that with Congress in the context of delegation, both to give
> Congress the ability to pull in the scheduling policy and to push the
> scheduling policy.
> 
> 
> - Mistral.  The use case for this integration is to help people create an HA
> solution for VMs.  So have Congress monitor VMs, identify when they have
> failed, and kick off a Mistral workflow to resurrect them.
> 
> 
> - Vintrage.  Vintrage does root-cause-analysis.  It provides a graph-based
> model for the structure of the datacenter (switches attached to hypervisors,
> servers attached to hypervisors, etc.) and a templating language for defining
> how to create new alarms from existing alarms.  The action item that we left
> is that the Vintrage team will initiate a mailing list thread where we discuss
> which Vintrage data might be valuable for Congress policies.
> 
> 
> 3. Working sessions
> - The new distributed architecture is nearing completion.  There seems to be 1
> blocker for having the basic functionality ready to test: at boot, Congress
> doesn¹t properly spin up datasources that have already been configured in the
> database.  As an experiment to see how close we were to completion, we started
> up the Congress server with just the API and policy engine and saw the basics
> actually working!  When we added the datasources, we found a bug where the API
> was assuming the datasources could be referenced by UUID, when in fact they
> can only be referenced by Name on the message-bus.   So while there¹s still
> quite a bit to do, we¹re getting close to having all the basics working.
> 
> 
> - We made progress on the high-availability and high-throughput design.  This
> is still very much open to design and discussion, so continuing the design on
> the mailing list would be great.  Here are the highlights.
> o  Policy engine: split into (i) active-active for queries to deal with
> high-throughput (ii) active-passive for action-execution (requiring
> leader-election, etc.).  Policy CRUD modifies DB; undecided whether API also
> informs all policy-engines, or whether they all sync from the DB.
> o  Pull datasources: no obvious need for replication, since they restart
> really fast and will just re-pull the latest data anyhow
> o  Push datasources: Need HA for ensuring the pusher can always push, e.g.
> the pusher drops the message onto oslo-messaging.  Still up for debate is
> whether we also need HA for storing the data since there is no way to ask for
> it after a restart; one suggestion is that every datasource must allow us to
> ask for the state.  HT does not require replication, since syncing the state
> between several instances would be required and would be less performant than
> a 

[openstack-dev] [Congress] Congress social at Austin 4/27

[Eric K]

Hi Congress folks,

We¹re going to have an evening get-together at Openstack Austin. Please
shoot me an email at  if you¹re planning to come.
Hope to see you there!

Information:
Date: Wednesday, April 27
Time: 6:00PM
Location: 
LAMBERTS DOWNTOWN BARBEQUE
401 West 2nd Street
Austin, Texas 78701
http://www.lambertsaustin.com/menus/


__
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] [Congress] Issue with glancev2 datasource driver

[Eric K]

Hi Bryan,

Based on our IRC conversation today, you seem to be experiencing this issue
we only recently tracked down:
https://bugs.launchpad.net/congress/+bug/1563495
The fix is in Mitaka, and still being back-ported to Liberty.
Here¹s the Liberty patch if you want to try it out:
https://review.openstack.org/#/c/305613/ (I think the patch is good despite
the dsvm failure; gating issue to be resolved)

From:  Bryan Sullivan 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, February 23, 2016 at 2:01 PM
To:  "openstack-dev@lists.openstack.org" 
Subject:  [openstack-dev] [Congress] Issue with glancev2 datasource driver

> I¹m running into an issue with the rows provided by the glancev2 driver for
> congress. There are images defined in glance (see below) but no rows are being
> returned by congress. Any idea why this might be happening?
>  
> Below I query Openstack directly, then try to get the same data thru congress.
> I am using the stable/liberty branch, installed yesterday. This is on the
> OPNFV Brahmaputra release (not devstack), and most other congress datasources
> and functions are working as expected.
>  
> Thanks for your help!
> Bryan Sullivan | AT
>  
> opnfv@jumphost:~/git/python-congressclient$ openstack image list
> +--+-+
> | ID  | Name   |
> +--+-+
> | 98705491-edda-4645-a413-129502190d56 | cirros-0.3.3-x86_64-dmz |
> | 59cf60e8-e0ce-48b1-b081-6325c1e1c52b | cirros-0.3.3-x86_64|
> +--+-+
> opnfv@jumphost:~/git/python-congressclient$ openstack congress datasource row
> list glancev2 images
>  
> opnfv@jumphost:~/git/python-congressclient$
>
> __
> 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] [Congress] Issues with Tox testing

[Eric K]

Thanks for the feedback, Bryan. Glad you got things working!

1. The instructions asking to install those packages are missing from kilo
(we¹ll fix that), but they have been there since liberty. Was it perhaps
unclear because the line is too long?
* Additionally:
* $ sudo apt-get install git gcc python-dev libxml2 libxslt1-dev libzip-dev
mysql-server python-mysqldb build-essential libssl-dev libffi-dev
2. Tempest should not be required by the tox tests.

Thanks!

From:  Bryan Sullivan 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Thursday, April 7, 2016 at 4:29 PM
To:  "openstack-dev@lists.openstack.org" 
Subject:  Re: [openstack-dev] [Congress] Issues with Tox testing

> An update: I found that there were two dependencies needed that were not clear
> in the guide at https://github.com/openstack/congress. I also installed
> Tempest which was not referenced before. If these additions are correct (they
> worked for me), they should be added to
> https://github.com/openstack/congress/blob/master/README.rst.
> 
> $ sudo apt-get install libffi-dev libssl-dev
> $ cd ~/git
> $ git clone https://github.com/openstack/tempest/
> $ cd tempest
> $ ~/git/congress/bin/pip install -r requirements.txt
> $ ~/git/congress/bin/pip install .
> 
> (not sure if both pip commands are needed - I'm not an expert on pip install)
> 
> After that, "tox -epy27" ran thru fine:
> 
> --
> -  ---
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_se
> t_policy_with_dashes   27.623
> congress.tests.policy_engines.test_vmplacement.TestComputeVmAssignment.test_se
> t_policy   27.212
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_simulate_latency  1.325
> congress.tests.dse.test_dse.TestDSE.test_policy_tables
> 1.229
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_select_100matches 1.184
> congress.tests.test_congress.TestCongress.test_policy_execute
> 1.127
> congress.tests.test_congress.TestCongress.test_datasource_api_model_execute
> 1.067
> congress.tests.policy_engines.test_agnostic_performance.TestRuntimePerformance
> .test_update_nonrecursive   0.967
> congress.tests.dse.test_dse.TestDSE.test_policy_table_publish
> 0.681
> congress.tests.datasources.test_neutron_driver.TestDataSourceDriver.test_poll_
> subscribe   0.671
> __ summary
> ___
>   py27: commands succeeded
>   congratulations :)
> 
> 
> 
> Thanks,
> Bryan Sullivan
> 
> 
> From: bls...@hotmail.com
> To: openstack-dev@lists.openstack.org
> Date: Thu, 7 Apr 2016 11:16:48 -0700
> Subject: [openstack-dev] [Congress] Issues with Tox testing
> 
> Hi Congress team,
> 
> A question for tox testing expert on the Congress team. I'm trying to run the
> tox tests as described at https://github.com/openstack/congress, specifically
> the two commands:
> 
> $ sudo pip install 'tox<1.7' $ tox -epy27
> 
> 
> 
> Due to conflicts with the OS-owned python config, I run these under my
> virtualenv created in the congress repo as:
> $ cd ~/git/congress
> $ bin/pip  install 'tox<1.7'
> $ bin/tox -epy27
> 
> 
> But in any event (whether I try to run the tox within the virtualenv or not),
> I get errors such as:
>   c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
> 
> 
> 
> What's missing in the setup for running these tests?
> 
> 
> 
> Note that I have all the config needed to run bash/CLI-based test scripts such
> as https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh
> 
> 
> 
> Thanks,
> Bryan Sullivan   
> 
> __
> 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 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] [Congress] New bug for Mitaka: Glance authentication fails after token expiry

[Eric K]

I just discovered a bug that¹s probably been around a long time but hidden
by exception suppression. https://bugs.launchpad.net/congress/+bug/1563495
When an auth attempt fails due to token expiry, Congress Glance driver
obtains a new token from keystone and sets it in Glance client, but for
some reason, Glance client continues to use the expired token and fails to
authenticate. Glance data stops flowing to Congress. It might explain the
issue Bryan Sullivan ran into
(http://lists.openstack.org/pipermail/openstack-dev/2016-February/087364.ht
ml).

I haven¹t been able to nail down whether it¹s a Congress datasource driver
issue or a Glance client issue. A few more eyes on it would be great.
Thanks!



__
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] [Congress] Push Type Driver implementation

[Eric K]

I got the same behavior Tim Hinrichs did using DoctorDriver.

The problem when listing datasources does not occur with the basic
PushDriver in progress, but it has other issues when pushing and listing
data. See 

From:  Tim Hinrichs 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Thursday, March 24, 2016 at 10:34 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [Congress] Push Type Driver implementation

> I tried the doctorDriver again.  This time I was successful!  I'm still
> getting an error when listing the datasources though.  I tried updating and
> installing my client, but no change.
> 
> // Create the datasource
> $ openstack congress datasource create doctor doctor
> +-+--+
> | Field   | Value|
> +-+--+
> | config  | None |
> | description | None |
> | driver  | doctor   |
> | enabled | True |
> | id  | 3717095c-25a7-4fe2-8f18-25d845b11c60 |
> | name| doctor   |
> | type| None |
> +-+--+
> 
> // Push data
> $ curl -g -i -X PUT
> http://localhost:1789/v1/data-sources/3717095c-25a7-4fe2-8f18-25d845b11c60/tab
> les/events/rows -H "User-Agent: python-congressclient" -H "Content-Type:
> application/json" -H "Accept: application/json" -d  '[
>> >   {
>> > "id": "0123-4567-89ab",
>> > "time": "2016-02-22T11:48:55Z",
>> > "type": "compute.host.down",
>> > "details": {
>> > "hostname": "compute1",
>> > "status": "down",
>> > "monitor": "zabbix1",
>> > "monitor_event_id": "111"
>> > }
>> >   }
>> > ]'
> HTTP/1.1 200 OK
> Content-Type: application/json; charset=UTF-8
> Content-Length: 0
> X-Openstack-Request-Id: req-47c6dfdf-74cd-4101-829a-657b6aea1e2c
> Date: Thu, 24 Mar 2016 18:28:31 GMT
> 
> 
> // Ask for contents of table that we pushed
> $ openstack congress datasource row list doctor events
> ++--+--+--++--
> ---+--+
> | id | time | type | hostname | status |
> monitor | monitor_event_id |
> ++--+--+--++--
> ---+--+
> | 0123-4567-89ab | 2016-02-22T11:48 | compute.host.dow | compute1 | down   |
> zabbix1 | 111  |
> || :55Z | n|  ||
> |  |
> ++--+--+--++--
> ---+--+
> 
> 
> // List the datasources
> $ openstack congress datasource list
> 'NoneType' object has no attribute 'items'
> 
> Tim
> 
> 
> On Thu, Mar 17, 2016 at 5:56 PM Tim Hinrichs  wrote:
>> I tried the doctor driver out.  I just added the file to
>> congress/datasources, and set up /etc/congress/congress.conf to include
>> congress.datasources.doctor_driver.DoctorDriver.
>> 
>> I could create a new doctor driver, but afterwards I couldn't list all the
>> datasources, and I couldn't push any data to it.  See transcript below.
>> 
>> $ openstack congress datasource create doctor doctor
>> +-+--+
>> | Field   | Value|
>> +-+--+
>> | config  | None |
>> | description | None |
>> | driver  | doctor   |
>> | enabled | True |
>> | id  | 906c6327-15f1-4f3c-aa51-1590540c06b9 |
>> | name| doctor   |
>> | type| None |
>> +-+--+
>> 
>> $ openstack congress datasource list
>> 'NoneType' object has no attribute 'items'
>> 
>> The other problem I saw was that the schema was fixed for the doctor driver.
>> So I tried to create a push driver that would accept any collection of
>> tuples.  This wouldn't allow the user to push arbitrary JSON, but they could
>> push any tuples they'd like.  While experimenting, I fixed the problem
>> mentioned above by adding a single (unnecessary) configuration option.  Then
>> I ran into a Datasource not found problem.  I pushed the code to review so we
>> can all take a look.
>> 
>> https://review.openstack.org/294348
>> 
>> $ curl -g -i -X PUT
>> 

[openstack-dev] [Congress] HOL test completed

[Eric K]

Happy to report that everything in Congress HOL* works as expected after all
the merges today**.

*https://docs.google.com/document/d/1ispwf56bX8sy9T0KZyosdHrSR9WHEVA1oGEIYA2
2Orw/pub
**commit 5e2c7cde598fcb4ed781a211fb421a5e94afb406


__
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] [Congress] Python 3 ready

[Eric K]

Thanks, Victor. Congrats to everyone who worked on the port =)

Replacing antlr3 is an important TODO item, but IMHO separate from
supporting Python 3.

A Python 3 port of antlr3 was available from the antlr community so we
used it, with the understanding that antlr3 needs replacing sooner rather
than later.

At the moment, there is no obvious candidate for replacing antlr3. antlr4
would be a natural candidate, except that it dropped support for abstract
syntax trees, so it would require a major re-write of Congress grammar and
compiler code.

I¹m exploring the possibility of using Grako as a replacement for antlr3.

Additional thoughts and suggestions on antlr3 replacement always
appreciated =)

-Eric

On 12/4/15, 3:45 AM, "Victor Stinner" <vstin...@redhat.com> wrote:

>Hi,
>
>Le 04/12/2015 05:12, Eric K a écrit :
>> Congress can finally pass python34 gating.
>>
>> Here¹s the last patch needed to make it happen.
>> https://review.openstack.org/#/c/253298/
>
>Great job :-) Congrats.
>
>I see that antlr3 was ported to Python 3 in the commit
>0576d774a49dd310970974d0c881e8bd4915c2eb. This part blocked me, I don't
>know Java and ANTLR upstream development is now focused in the version 4.
>
>Victor
>
>__
>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] [Congress] Python 3 ready

[Eric K]

Congress can finally pass python34 gating.

Here¹s the last patch needed to make it happen.
https://review.openstack.org/#/c/253298/


__
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