[openstack-dev] [congress] temporary change of meeting time

[Eric K]

Sorry for the rather late announcement. We're moving this week's
Congress team meeting from Friday 4AM UTC to Thursday 10AM UTC in
order to accommodate the summit local time zone. Thanks!

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] [congress] 4AM UTC meeting today 9/28

[Eric K]

Hi all, the Congress team meeting is transitioning to Fridays 4AM UTC
on even weeks (starting 10/5). During this week's transition, we'll
have a special transition meeting today Friday at 4AM UTC (instead of
previous 2:30AM UTC) even though it's an odd week.

Thank you!

Eric 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

[openstack-dev] [congress] proposed new meeting time

[Eric K]

Hi all,

Following discussions in IRC meetings, here is a proposed new meeting
time for Congress project:
On even weeks, Friday UTC 4AM (from the current UTC 2:30AM)

The new time would make it easier for India while still good for Asia
Pacific. The time continues to be bad for Europe and Eastern Americas.
We can add another meeting time in the off week if there is interest.

Please respond if you have any additional comments!

Eric 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

[openstack-dev] [congress] no IRC meeting 9/14 during PTG week

[Eric K]

Let's resume on 9/21. 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

[openstack-dev] [congress] meeting cancelled 8/24

[Eric K]

Hi all,
I¹m not going to be able to make the meeting this week.

Let¹s resume next week =)

I'm still available by email.

Cheers!



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

[openstack-dev] congress-dashboard 3.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for congress-dashboard for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


http://git.openstack.org/cgit/openstack/congress-dashboard/log/?h=stable/rocky

Release notes for congress-dashboard can be found at:

http://docs.openstack.org/releasenotes/congress-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/congress

and tag it *rocky-rc-potential* to bring it to the congress-dashboard
release crew's attention.


__
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 8.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/rocky

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/




__
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] meeting cancelled

[Eric K]

Hi all,
I’m not going to be able to make the meeting this week.

Let’s resume next week =)

I’m still available by email.

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

[openstack-dev] [Congress] updated backlog

[Eric K]

Here's an updated backlog following Rocky discussions.
https://etherpad.openstack.org/p/congress-task-priority


Please feel free to comment and suggest additions/deletions and changes in
priority.   



__
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 3/23

[Eric K]

IRC weekly meeting resumes on 3/30.
__
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 team meeting this week 3/1

[Eric K]

Cancelled for PTG



__
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] congress 7.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/queens

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/




__
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] congress-dashboard 2.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for congress-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:


http://git.openstack.org/cgit/openstack/congress-dashboard/log/?h=stable/queens

Release notes for congress-dashboard can be found at:

http://docs.openstack.org/releasenotes/congress-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/congress

and tag it *queens-rc-potential* to bring it to the congress-dashboard
release crew's attention.


__
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] congress 7.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/queens

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/




__
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][requirements][RFE] adding tenacity to congress requirements

[Eric K]

Looking to add tenacity to congress requirements because it's needed by a
forthcoming bug fix. No change to requirements repo. Does this need an
exception? Thanks a lot!

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

Eric 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] generic push driver

[Afek, Ifat (Nokia - IL/Kfar Sava)]

From: Eric K 
Date: Tuesday, 9 January 2018 at 0:43

Hi Ifat,

From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
mailto:ifat.a...@nokia.com>>
Date: Sunday, January 7, 2018 at 4:00 AM


Hi Eric,

I have two questions:


1.  An alarm is usually raised on a resource, and in Vitrage we can send 
you the details of that resource. Is there a way in Congress for the alarm to 
reference a resource that exists in another table? And what if the resource 
does not exist in Congress?
First, the columns I chose are just a minimal sample to illustrate the generic 
nature of the driver. In use with vitrage, we would probably also want to 
include columns such as `resource_id`. Does that address the need to reference 
a resource? That resource referenced by ID may or may not exist in another part 
of Congress. It would be the job of the policy to resolve references when 
taking appropriate actions. If referential integrity is needed, additional 
policy rules can be specified to catch breakage.

[Ifat] Ok, sounds good.

This brings up a related question I had about vitrage:
Looking at the vertex properties listed here: 
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py#L17

Where can I find more information about the type and content of data in each 
property?

Exapmle:
- is the `resource` property an ID string or a python object reference?

[Ifat] Most of the properties are key-value strings on the vertex in the entity 
graph. The RESOURCE is a special property that is added on an alarm for the use 
of the notifier. It holds the entire resource object, so the notifier could use 
its properties when sending notifications.

- what does the property `is_real_vitrage_id`
represent?

[Ifat] It represents old code that should be deleted ;-) please ignore it

- what is the difference between `resource_id` and `vitrage_resource_id` ?

[Ifat] resource_id is the id of the resource as retrieved by the datasource, 
e.g. the Nova instance id
 vitrage_id is the id of the resource inside Vitrage. This is the id 
that Vitrage uses to identify its resources. For a Nova instance, vitrage_id 
will be different from its resource_id.
 vitrage_resource_id is used only on alarms, and holds the vitrage_id 
of the resource of the alarm.



2.  Do you plan to support also updateRows? This can be useful for alarm 
state changes.
Are you thinking about updating an entire row or updating a specific field of a 
row? That is, update
Row {"id":"1-1", "name":"name1", "state":"active", "severity":1} to become 
{"id":"1-1", "name":"name1", "state":"active", "severity":100}
Vs
Update the severity field of row with id "1-1" to severity 100.
Both could be supported, but the second one is more complex to support 
efficiently.

[Ifat] It’s really up to you, I think both would satisfy the use case. The 
Congress notifier will be written based on your selected implementation.


__
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] generic push driver

[Eric K]

From:  Tim Hinrichs 
Date:  Monday, January 8, 2018 at 7:31 AM
To:  Eric Kao 
Cc:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [congress] generic push driver

> It's probably worth considering PATCH instead of PUT for updating the table.
Ah right of course. PATCH makes more sense here.
> 
> http://restcookbook.com/HTTP%20Methods/patch/
> 
> You could also think about using JSON-patch to describe the requested update.
> It provides fine-grained update semantics:
> 
> https://tools.ietf.org/html/rfc6902
Hmm it would be very nice to follow an existing standard. Unfortunately the
json patch path specifications seem like an awkward fit with the set
semantics of congress tables. Removal, for example, must be done by
specifying the array index of the row to be removed. But perhaps we can
borrow the style of json patch for patching sets. For example:
PATCH '/v1/data-sources/vitrage/tables/alarms' with body:
[
  {
"op":"add",
"path":"/",
"value":{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
}
  },
  {
"op":"add",
"path":"/",
"value":[
  "1-2",
  "name2",
  "active",
  2
]
  },
  {
"op":"remove",
"path":"/",
"value":[
  "1-2",
  "name2",
  "active",
  2
]
  }
]

Would that work well? At least there will be well-defined semantic based on
sequential operation.
> 
> Tim
> 
> On Fri, Jan 5, 2018 at 5:50 PM Eric K  wrote:
>> We've been discussing generic push drivers for Congress for quite a while.
>> Finally sketching out something concrete and looking for some preliminary
>> feedback. Below are sample interactions with a proposed generic push driver.
>> A generic push driver could be used to receive push updates from vitrage,
>> monasca, and many other sources.
>> 
>> 1. creating a datasource:
>> 
>> congress datasource create generic_push_driver vitrage --config schema='
>> {
>>   "tables":[
>> {
>>   "name":"alarms",
>>   "columns":[
>> "id",
>> "name",
>> "state",
>> "severity",
>>   ]
>> }
>>   ]
>> }
>> '
>> 
>> 2. Update an entire table:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "rows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> Note that a row can be either a {} or []
>> 
>> 
>> 3. perform differential update:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "addrows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> 
>> OR
>> 
>> {
>>   "deleterows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> 
>> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together
>> with some well defined semantics. Alternatively we may mandate that each
>> request can have only one of the three pieces.
>> 
>> Note 2: we leave it as the responsibility of the sender to send and confirm
>> the requests for differential updates in correct order. We could add
>> sequencing in future work.


__
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] generic push driver

[Eric K]

Hi Ifat,
From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Sunday, January 7, 2018 at 4:00 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [congress] generic push driver

> Hi Eric,
>  
> I have two questions:
>  
> 1.  An alarm is usually raised on a resource, and in Vitrage we can send
> you the details of that resource. Is there a way in Congress for the alarm to
> reference a resource that exists in another table? And what if the resource
> does not exist in Congress?

First, the columns I chose are just a minimal sample to illustrate the
generic nature of the driver. In use with vitrage, we would probably also
want to include columns such as `resource_id`. Does that address the need to
reference a resource? That resource referenced by ID may or may not exist in
another part of Congress. It would be the job of the policy to resolve
references when taking appropriate actions. If referential integrity is
needed, additional policy rules can be specified to catch breakage.

This brings up a related question I had about vitrage:
Looking at the vertex properties listed here:
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py
#L17

Where can I find more information about the type and content of data in each
property?

Exapmle:
- is the `resource` property an ID string or a python object reference?
- what does the property `is_real_vitrage_id` represent?
- what is the difference between `resource_id` and `vitrage_resource_id` ?

> 2.  Do you plan to support also updateRows? This can be useful for alarm
> state changes.

Are you thinking about updating an entire row or updating a specific field
of a row? That is, update
Row {"id":"1-1", "name":"name1", "state":"active", "severity":1} to become
{"id":"1-1", "name":"name1", "state":"active", "severity":100}
Vs
Update the severity field of row with id "1-1" to severity 100.
Both could be supported, but the second one is more complex to support
efficiently.

Thanks!
Eric
>  
> Thanks,
> Ifat
>  
>  
> 
> From: Eric K 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Saturday, 6 January 2018 at 3:50
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [congress] generic push driver
> 
>  
> 
> We've been discussing generic push drivers for Congress for quite a while.
> Finally sketching out something concrete and looking for some preliminary
> feedback. Below are sample interactions with a proposed generic push driver. A
> generic push driver could be used to receive push updates from vitrage,
> monasca, and many other sources.
> 
>  
> 
> 1. creating a datasource:
> 
>  
> 
> congress datasource create generic_push_driver vitrage --config schema='
> 
> {
> 
>   "tables":[
> 
> {
> 
>   "name":"alarms",
> 
>   "columns":[
> 
> "id",
> 
> "name",
> 
> "state",
> 
> "severity",
> 
>   ]
> 
> }
> 
>   ]
> 
> }
> 
> '
> 
>  
> 
> 2. Update an entire table:
> 
>  
> 
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> 
> {
> 
>   "rows":[
> 
> {
> 
>   "id":"1-1",
> 
>   "name":"name1",
> 
>   "state":"active",
> 
>   "severity":1
> 
> },
> 
> [
> 
>   "1-2",
> 
>   "name2",
> 
>   "active",
> 
>   2
> 
> ]
> 
>   ]
> 
> }
> 
> Note that a row can be either a {} or []
> 
>  
> 
>  
> 
> 3. perform differential update:
> 
>  
> 
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> 
> {
> 
>   "addrows":[
> 
> {
> 
>   "id":"1-1",
> 
>   "name":"name1",
> 
>   "state":"active",
> 
>   "severity":1
> 
> },
> 
> [
> 
>   "1-2",
> 
>   "name2",
> 
>   "active",
> 
>   2
> 
> ]
> 
>   ]
> 
> }
> 
>  
> 
> OR
> 
>  
> 
> {
> 
>   "deleterows":[
> 
> {
>

Re: [openstack-dev] [congress] generic push driver

[Tim Hinrichs]

It's probably worth considering PATCH instead of PUT for updating the table.

http://restcookbook.com/HTTP%20Methods/patch/

You could also think about using JSON-patch to describe the requested
update.  It provides fine-grained update semantics:

https://tools.ietf.org/html/rfc6902

Tim

On Fri, Jan 5, 2018 at 5:50 PM Eric K  wrote:

> We've been discussing generic push drivers for Congress for quite a while.
> Finally sketching out something concrete and looking for some preliminary
> feedback. Below are sample interactions with a proposed generic push
> driver. A generic push driver could be used to receive push updates from
> vitrage, monasca, and many other sources.
>
> 1. creating a datasource:
>
> congress datasource create generic_push_driver vitrage --config schema='
> {
>   "tables":[
> {
>   "name":"alarms",
>   "columns":[
> "id",
> "name",
> "state",
> "severity",
>   ]
> }
>   ]
> }
> '
>
> 2. Update an entire table:
>
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> {
>   "rows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
> Note that a row can be either a {} or []
>
>
> 3. perform differential update:
>
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> {
>   "addrows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
>
> OR
>
> {
>   "deleterows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
>
> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used
> together with some well defined semantics. Alternatively we may mandate
> that each request can have only one of the three pieces.
>
> Note 2: we leave it as the responsibility of the sender to send and
> confirm the requests for differential updates in correct order. We could
> add sequencing in future work.
>
__
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] generic push driver

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Eric,

I have two questions:


1.   An alarm is usually raised on a resource, and in Vitrage we can send 
you the details of that resource. Is there a way in Congress for the alarm to 
reference a resource that exists in another table? And what if the resource 
does not exist in Congress?

2.   Do you plan to support also updateRows? This can be useful for alarm 
state changes.

Thanks,
Ifat


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

Date: Saturday, 6 January 2018 at 3:50
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [congress] generic push driver

We've been discussing generic push drivers for Congress for quite a while. 
Finally sketching out something concrete and looking for some preliminary 
feedback. Below are sample interactions with a proposed generic push driver. A 
generic push driver could be used to receive push updates from vitrage, 
monasca, and many other sources.

1. creating a datasource:

congress datasource create generic_push_driver vitrage --config schema='
{
  "tables":[
{
  "name":"alarms",
  "columns":[
"id",
"name",
"state",
"severity",
  ]
}
  ]
}
'

2. Update an entire table:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "rows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}
Note that a row can be either a {} or []


3. perform differential update:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "addrows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

OR

{
  "deleterows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together 
with some well defined semantics. Alternatively we may mandate that each 
request can have only one of the three pieces.

Note 2: we leave it as the responsibility of the sender to send and confirm the 
requests for differential updates in correct order. We could add sequencing in 
future work.
__
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] generic push driver

[Eric K]

We've been discussing generic push drivers for Congress for quite a while.
Finally sketching out something concrete and looking for some preliminary
feedback. Below are sample interactions with a proposed generic push
driver. A generic push driver could be used to receive push updates from
vitrage, monasca, and many other sources.

1. creating a datasource:

congress datasource create generic_push_driver vitrage --config schema='
{
  "tables":[
{
  "name":"alarms",
  "columns":[
"id",
"name",
"state",
"severity",
  ]
}
  ]
}
'

2. Update an entire table:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "rows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}
Note that a row can be either a {} or []


3. perform differential update:

PUT '/v1/data-sources/vitrage/tables/alarms' with body:
{
  "addrows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

OR

{
  "deleterows":[
{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
},
[
  "1-2",
  "name2",
  "active",
  2
]
  ]
}

Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used
together with some well defined semantics. Alternatively we may mandate
that each request can have only one of the three pieces.

Note 2: we leave it as the responsibility of the sender to send and confirm
the requests for differential updates in correct order. We could add
sequencing in future work.
__
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 this week

[Eric K]

Hi all,
Just a heads up that there will be no Congress team meeting this week
12/29. We'll be back next year on 1/5!

-ekcs



__
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] physical or virtual sessions

[Eric K]

Hi all,

It's that time again to figure out whether we'd hold physical sessions at
the PTG (February 26-March 2nd at Croke Park in Dublin, Ireland).

If you're interested in participating, please respond to the following.
1. What do you prefer between physical sessions at the PTG and remote
virtual sessions*.
2. If we hold physical sessions at the PTG, do you expect to attend?
3. If we hold virtual sessions* at the PTG, do you expect to attend?
4. Any other thoughts or comments?

Thank you!

*virtual sessions would likely be a shorter time (1-2 hrs) per day and
spread out over more days to accommodate different time zones.



__
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] time change for IRC meeting

[Eric K]

Hi all,

As previously discussed over, we'll move the weekly Congress team meeting
to the new time of Fridays 02:30 UTC, with the first new meeting on
November 3rd. Same channel #openstack-meeting.
Just to reiterate, there will be no meeting on November 2nd 00:00 (old
meeting time).

As always, collaborative list of meeting topics is kept here:
https://etherpad.openstack.org/p/congress-meeting-topics

See you all!

-Eric Kao


On 10/19/17, 11:13 AM, "Eric K"  wrote:

>Hi all,
>
>Here is a proposal (no actual change until further notice) to move the
>weekly Congress team meeting from Thursdays 00:00 UTC to Fridays 02:30 UTC
>in order to make the meeting time more bearable for India while still
>being workable for East Asia and the Americas. The time remains very bad
>for Europe and Africa (if there is interest, we can also set up for some
>weeks a meeting time that works better for Europe and Africa; please let
>us know!).
>
>Please express your comments and suggestions here. Thanks!
>
>-Eric 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

[openstack-dev] [Congress] proposed change to IRC meeting time

[Eric K]

Hi all,

Here is a proposal (no actual change until further notice) to move the
weekly Congress team meeting from Thursdays 00:00 UTC to Fridays 02:30 UTC
in order to make the meeting time more bearable for India while still
being workable for East Asia and the Americas. The time remains very bad
for Europe and Africa (if there is interest, we can also set up for some
weeks a meeting time that works better for Europe and Africa; please let
us know!).

Please express your comments and suggestions here. Thanks!

-Eric 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] Is it possible that congress policy do live-migration

[Eric K]

Hi Houzhian,

Great the see people doing fault tolerance with Congress. That's how
Congress is used in by the OpNFV Doctor project
(https://wiki.opnfv.org/display/doctor)

I just tested the same rule on Pike release and it seems Congress delivered
the correct request to nova. Do you have the Congress and Nova logs that can
help us determine what happened?
Also which version are you on and what environment are you running in?

Cheers!

Eric Kao

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

Date:  Wednesday, October 18, 2017 at 12:51 AM
To:  "openstack-dev@lists.openstack.org" 
Subject:  [openstack-dev] Is it possible that congress policy do
live-migration

>  
>  
> 
> Hey guys, thanks for your efforts on OpenStack Congress, I am very puzzled
> about policy of Congress on recent days and I decided to ask you for some
> help, I am looking forward to your reply.
> 
> openstack congress policy rule create \
> --name live_migrate_vm classification \
> 
> 'execute[nova:servers.live_migrate(vmid,"overcloud-novacompute-1.opnfvlf.org",
> "False","False")] :-
> host_down(host),
> active_instance_in_host(vmid, host)'
> 
> 
> Is this a valid policy? Is there some connection between nova client api and
> execute in congress policy which are allowed to use? I noticed that
> nova pause vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> nova migrate vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> there exist nova live-migration vmid
> but I can not add execute[nova:servers.live-migration(vmid,other params
> maybe)] to congress policy, nova:servers.live-migrate(vmid,other params) can
> be added successfuly but it didn't do live migration jobs, nothing happened.I
> am confused about this,
> Am I able to use congress to do some automatic fault recovery like live
> migration?
> 
>
> 发自网易邮箱大师
> 
> 
> __
> 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] Is it possible that congress policy do live-migration

[Tim Hinrichs]

Adding [Congress] to the subject line for proper filtering...

Congress lets you execute most of the Nova client API calls.  You use the
same arguments you would use for the Nova client.  Here are the docs for
the live-migration API: scroll down to live-migrate.

https://docs.openstack.org/python-novaclient/latest/reference/api/novaclient.v2.servers.html

Congress doesn't let you pass in keyword args like host="foo" (others will
correct me if that's changed recently), so you will need to figure out what
non-keyword arguments live-migration allows you to pass.  It wasn't clear
to me from the docs.

Tim

On Wed, Oct 18, 2017 at 12:53 AM houzhian  wrote:

>
> Hey guys, thanks for your efforts on OpenStack Congress, I am very puzzled
> about policy of Congress on recent days and I decided to ask you for some
> help, I am looking forward to your reply.
>
> openstack congress policy rule create \
> --name live_migrate_vm classification \
> 'execute[nova:servers.live_migrate(vmid,"
> overcloud-novacompute-1.opnfvlf.org","False","False")] :-
> host_down(host),
> active_instance_in_host(vmid, host)'
>
>
> Is this a valid policy? Is there some connection between nova client api
> and execute in congress policy which are allowed to use? I noticed that
> nova pause vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> nova migrate vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> there exist nova live-migration vmid
> but I can not add execute[nova:servers.live-migration(vmid,other params
> maybe)] to congress policy, nova:servers.live-migrate(vmid,other params)
> can be added successfuly but it didn't do live migration jobs, nothing
> happened.I am confused about this,
> Am I able to use congress to do some automatic fault recovery like live
> migration?
>
> 发自网易邮箱大师
>
> __
> 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] drivers conf discussion

[Eric K]

Continuing from the 10/5 IRC discussion on drivers conf, here I've laid
out some decision points and incomplete pros and cons.
If you're interested, please add relevant pros and cons as well as further
discussion on your thoughts and preferences on the decision points. Thanks!

https://etherpad.openstack.org/p/congress-driver-conf



__
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 agenda 2017-09-21

[Eric K]

Hi all,

Looking forward to catching up at our IRC meeting tomorrow after a
productive PTG!

It¹d be helpful to look at these items ahead of the meeting:
- A work-in-progress list of priorities for Queens we can discuss and
finish in our meeting.
https://etherpad.openstack.org/p/congress-task-priority
- QoS neutron driver patch. We can discuss outstanding comments and move
toward a merge-ready patch. https://review.openstack.org/#/c/488992/
- A proposed blueprint for having a tier of ³unoffcial² drivers for
congress. We can discuss and decide.
https://blueprints.launchpad.net/congress/+spec/separate-unofficial-drivers



Feel free to add any other topics at the usual place:
https://etherpad.openstack.org/p/congress-meeting-topics
Also feel free to take a look at this bullet-list summary of the PTG
discussions and bring up any point for further discussion at our meeting:
https://etherpad.openstack.org/p/congress-ptg-queens

Cheers,
Eric Kao (ekcs)



__
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 hours and remote attendee instructions

[Eric K]

Hi all,

If you¹re looking to join the Congress discussions at the PTG, please
follow the URL to join the conferencing meeting.
URL: https://bluejeans.com/122291516
Meeting Id: 122291516
Phone Number: +1.408.740.7256

No sign-up necessary. Once you join the room, you will have the option to
use computer audio over the internet or call in to a telephone number
(local number available for several countries).
Contact us at the #congress IRC channel if you have questions or need
assistance.

General hours:
Sep 13-14:
9:00 - 10:50; 14:00 - 17:00 (local time Mountain Daylight Time)
15:00 - 16:50; 20:00 - 23:00 (UTC)

Updates will be added to planning etherpad:
https://etherpad.openstack.org/p/congress-ptg-queens

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

[openstack-dev] [congress] no congress meeting on 9/14

[Eric K]

To accommodate people at PTG



__
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] congress 6.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/pike

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/




__
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] congress-dashboard 1.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for congress-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/congress-dashboard/log/?h=stable/pike

Release notes for congress-dashboard can be found at:

http://docs.openstack.org/releasenotes/congress-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/congress

and tag it *pike-rc-potential* to bring it to the congress-dashboard
release crew's attention.


__
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] Using congress to improve the consistency of configuration files.

[Tim Hinrichs]

Hi Valentin,

Sounds like an interesting use case.  Typically we've focused on
information available through APIs.  In this case the information would be
pulled off the disks of the machines running each service.

Here's the info for our weekly meeting.  If you can make that, it's a good
place to start.

http://eavesdrop.openstack.org/#Congress_Team_Meeting

Tim



On Mon, Jul 10, 2017 at 4:31 AM  wrote:

> Hi Eric,
>
> Here is the blueprint :
>
> https://blueprints.launchpad.net/congress/+spec/configuration-files-validation
>
> As Pierre Crégut presented it in his reply to Clint, the use of Congress
> we suggested and config management systems complement one another.
>
> Essentially, the latter reproduce delimited and *likely* valid
> configurations.
> But there is little formal validation and you'd rely on tests as soon as
> you
> have to make a change. Tests should be used in validation but are not
> best-suited to cover many constraints.
>
> By means of Congress, we could aggregate a lot of informal requirements
> and rules to define what a valid state is, in a more manageable way.
> We think that a declarative approach to the validation of configuration
> files would be very fitting.
>
> We'd also like to discuss the prototype and how to improve its design with
> the Congress team.
>
> V. Matton.
>
> Le 07/07/2017 à 01:16, Eric K a écrit :
>
> Hi Valentin,
>
> Very cool to hear about your use case and vision! It definitely sounds
> like the kind of use case Congress is well-equipped to solve using a
> flexible, declarative rule language.
>
> I'd love to explore the use case further (and where it fits along side
> config management systems as Clint mentioned). I'm especially curious to
> learn more about the prototype and see how I can be of help from Congress
> team.
>
> I did not see the blueprint link in the original message; missed paste
> perhaps?
>
> -Eric Kao (ekcs)
>
>
>
> On 7/4/17, 6:29 AM, "valentin.mat...@orange.com" 
>  
>  wrote:
>
>
> We would like to use congress to check the consistency of the
> configuration files used by the various Openstack services on different
> nodes.
>
> Although installers do a great job for ensuring that the initial
> definition of those files are correct, it may be necessary to tweak
> those files on running instances
> or to use templates that are out of the bounds of the pre-configured
> use-cases. Then the administrator must modify the configuration without
> any safety net.
>
> Congress is such a safety net but it ensures policies on live resources
> deployed in the cloud, not on how the cloud is configured but we think
> that it could be extended
> to perform such verification with the adequate datasource.
> So we propose a new datasource that will query each node to fetch its
> configuration files as long as they follow oslo.config requirements and
> structure.
> As a first step we propose to use agents deployed on the different nodes
> explicitly configured with the list of configuration files that push
> those files to the central
> congress service. Later on, oslo.config could be modified to provide a
> hook used to push config files directly from running services.
>
> The new datasource displays not only the option values, the file, host
> where they are defined but also the associated metadata so that generic
> rules can be defined.
> It is then possible to define rules:
> - that constrain the value of options between different nodes
> - that constrain the values between different services or different
> service plugins.
> - it is even possible to use the knowledge of those configuration
> options to check policies on live resources (for example when there is a
> limitation or a bug in a given
> driver).
>
> We have a working prototype and the corresponding specification along
> those principles that we would like to share. An initial blueprint has
> been submitted here:
> Please feel free to react
>
> V. Matton
>
> __
> ___
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.
>
>
> 

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[valentin.matton]

  
  
Hi Eric,
  
  Here is the blueprint : 
https://blueprints.launchpad.net/congress/+spec/configuration-files-validation
  
  As Pierre Crégut presented it in his reply to Clint, the use of
  Congress 
  we suggested and config management systems complement one another.
 Essentially, the latter reproduce delimited and likely
  valid configurations. 
  But there is little formal validation and you'd rely on tests as
  soon as you
  have to make a change. Tests should be used in validation but are
  not 
  best-suited to cover many constraints.

 By means of Congress, we could aggregate a lot of informal
  requirements 
  and rules to define what a valid state is, in a more manageable
  way. 
  We think that a declarative approach to the validation of
  configuration 
  files would be very fitting.
  
  We'd also like to discuss the prototype and how to improve its
  design with the Congress team.
  
  V. Matton.

Le 07/07/2017 à 01:16, Eric K a écrit :


  Hi Valentin,

Very cool to hear about your use case and vision! It definitely sounds
like the kind of use case Congress is well-equipped to solve using a
flexible, declarative rule language.

I'd love to explore the use case further (and where it fits along side
config management systems as Clint mentioned). I'm especially curious to
learn more about the prototype and see how I can be of help from Congress
team.

I did not see the blueprint link in the original message; missed paste
perhaps?

-Eric Kao (ekcs)



On 7/4/17, 6:29 AM, "valentin.mat...@orange.com"
 wrote:


  
We would like to use congress to check the consistency of the
configuration files used by the various Openstack services on different
nodes.

Although installers do a great job for ensuring that the initial
definition of those files are correct, it may be necessary to tweak
those files on running instances
or to use templates that are out of the bounds of the pre-configured
use-cases. Then the administrator must modify the configuration without
any safety net.

Congress is such a safety net but it ensures policies on live resources
deployed in the cloud, not on how the cloud is configured but we think
that it could be extended
to perform such verification with the adequate datasource.
So we propose a new datasource that will query each node to fetch its
configuration files as long as they follow oslo.config requirements and
structure.
As a first step we propose to use agents deployed on the different nodes
explicitly configured with the list of configuration files that push
those files to the central
congress service. Later on, oslo.config could be modified to provide a
hook used to push config files directly from running services.

The new datasource displays not only the option values, the file, host
where they are defined but also the associated metadata so that generic
rules can be defined.
It is then possible to define rules:
- that constrain the value of options between different nodes
- that constrain the values between different services or different
service plugins.
- it is even possible to use the knowledge of those configuration
options to check policies on live resources (for example when there is a
limitation or a bug in a given
driver).

We have a working prototype and the corresponding specification along
those principles that we would like to share. An initial blueprint has
been submitted here:
Please feel free to react

V. Matton

__
___

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.


__
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)
Unsu

Re: [openstack-dev] [congress] Using congress to improve the consistency of configuration files.

[Eric K]

Hi Valentin,

Very cool to hear about your use case and vision! It definitely sounds
like the kind of use case Congress is well-equipped to solve using a
flexible, declarative rule language.

I'd love to explore the use case further (and where it fits along side
config management systems as Clint mentioned). I'm especially curious to
learn more about the prototype and see how I can be of help from Congress
team.

I did not see the blueprint link in the original message; missed paste
perhaps?

-Eric Kao (ekcs)



On 7/4/17, 6:29 AM, "valentin.mat...@orange.com"
 wrote:

>We would like to use congress to check the consistency of the
>configuration files used by the various Openstack services on different
>nodes.
>
>Although installers do a great job for ensuring that the initial
>definition of those files are correct, it may be necessary to tweak
>those files on running instances
>or to use templates that are out of the bounds of the pre-configured
>use-cases. Then the administrator must modify the configuration without
>any safety net.
>
>Congress is such a safety net but it ensures policies on live resources
>deployed in the cloud, not on how the cloud is configured but we think
>that it could be extended
>to perform such verification with the adequate datasource.
>So we propose a new datasource that will query each node to fetch its
>configuration files as long as they follow oslo.config requirements and
>structure.
>As a first step we propose to use agents deployed on the different nodes
>explicitly configured with the list of configuration files that push
>those files to the central
>congress service. Later on, oslo.config could be modified to provide a
>hook used to push config files directly from running services.
>
>The new datasource displays not only the option values, the file, host
>where they are defined but also the associated metadata so that generic
>rules can be defined.
>It is then possible to define rules:
>- that constrain the value of options between different nodes
>- that constrain the values between different services or different
>service plugins.
>- it is even possible to use the knowledge of those configuration
>options to check policies on live resources (for example when there is a
>limitation or a bug in a given
>driver).
>
>We have a working prototype and the corresponding specification along
>those principles that we would like to share. An initial blueprint has
>been submitted here:
>Please feel free to react
>
>V. Matton
>
>__
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>
>__
>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] Using congress to improve the consistency of configuration files.

[pierre.cregut]

This is the classical divide between workflows and business rule engines 
and we
think that both are useful. While the first are invaluable to make a 
system reach
a correct state, the second describe in a more declarative way what a 
correct
state is and can also be used as a global model of the set of correct 
configurations.
A workflow engine will bring you to a reproducible state but this state 
is correct only

because some rules have been verified beforehand. Workflows are also often
designed in silos. When you need to combine playbooks, interactions may 
lead to
unexpected problems. Testing is necessary but if you can capture 
invariants (types)

you will spend less time and get better confidence on your deployments.

The difference of roles already exist between an orchestrator such as 
Heat and

Congress. You could use Heat in such a way  templates only describe correct
configurations according to your policies and test your templates to 
ensure they
do follow your rules but you will still use Congress as the place to 
describe the

policy and a way to check compliance.

Because we have thousands of options with requirements that are not all
functionals and coming from different sources (project, vendors, 
security team,

global and local design, ops knowledge) we should try to find ways to make
knowledge explicit, declarative and composable rather than bury it in
imperative procedures. The bet is that formalized rules will be much easier
to capitalize on than informal documentation. May be in the future, a 
lot of

rules could be supplied directly by OpenStack projects when options are
defined as a companion to the informal help descriptions.

Regards,

Pierre Crégut


On 07/04/2017 05:17 PM, Clint Byrum wrote:

Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:

We would like to use congress to check the consistency of the
configuration files used by the various Openstack services on different
nodes.

Although installers do a great job for ensuring that the initial
definition of those files are correct, it may be necessary to tweak
those files on running instances
or to use templates that are out of the bounds of the pre-configured
use-cases. Then the administrator must modify the configuration without
any safety net.


While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.






--
--

Orange Logo

*Pierre Crégut*
IMT/OLN/WTC/IEE/NAVI
tél. +33 (0)2 96 07 19 76
pierre.cre...@orange.com 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] Using congress to improve the consistency of configuration files. (OpenStack-dev Digest, Vol 63, Issue 5)

[pierre.cregut]

  
  
This is the classical divide between workflows and business rule
  engines and we think that both are useful. While the first are
  invaluable to make a system reach a correct state, the second
  describe in a more declarative way what a correct state is and can
  also be used as a global model of the set of correct
  configurations. A workflow engine will bring you to a reproducible
  state but this state is correct only because some rules have been
  verified beforehand. Workflows are also often designed in silos.
  When you need to combine playbooks, interactions may lead to
  unexpected problems. Testing is necessary but if you can capture
  invariants (types) you will spend less time and get better
  confidence on your deployments.
  
  The difference of roles already exist between an orchestrator such
  as Heat and Congress. You could use Heat in such a way  templates
  only describe correct configurations according to your policies
  and test your templates to ensure they do follow your rules but
  you will still use Congress as the place to describe the policy
  and a way to check compliance.
  
  Because we have thousands of options with requirements that are
  not all functionals and coming from different sources (project,
  vendors, security team, global and local design, ops knowledge) we
  should try to find ways to make knowledge explicit, declarative
  and composable rather than bury it in imperative procedures. The
  bet is that formalized rules will be much easier to capitalize on
  than informal documentation. May be in the future, a lot of rules
  could be supplied directly by OpenStack projects when options are
  defined as a companion to the informal help descriptions. 

Regards,

Pierre Crégut

On 07/04/2017 05:17 PM, Clint Byrum
  wrote:


  Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:

  
We would like to use congress to check the consistency of the 
configuration files used by the various Openstack services on different 
nodes.

Although installers do a great job for ensuring that the initial 
definition of those files are correct, it may be necessary to tweak 
those files on running instances
or to use templates that are out of the bounds of the pre-configured 
use-cases. Then the administrator must modify the configuration without 
any safety net.


  
  
While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.







-- 
  
  
  -- 
  

 Pierre
Crégut
  IMT/OLN/WTC/IEE/NAVI
  tél. +33 (0)2 96 07 19 76
  pierre.cre...@orange.com
  

  _

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


__
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] Using congress to improve the consistency of configuration files.

[Clint Byrum]

Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:
> We would like to use congress to check the consistency of the 
> configuration files used by the various Openstack services on different 
> nodes.
> 
> Although installers do a great job for ensuring that the initial 
> definition of those files are correct, it may be necessary to tweak 
> those files on running instances
> or to use templates that are out of the bounds of the pre-configured 
> use-cases. Then the administrator must modify the configuration without 
> any safety net.
> 

While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.

__
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] Using congress to improve the consistency of configuration files.

[valentin.matton]

We would like to use congress to check the consistency of the 
configuration files used by the various Openstack services on different 
nodes.


Although installers do a great job for ensuring that the initial 
definition of those files are correct, it may be necessary to tweak 
those files on running instances
or to use templates that are out of the bounds of the pre-configured 
use-cases. Then the administrator must modify the configuration without 
any safety net.


Congress is such a safety net but it ensures policies on live resources 
deployed in the cloud, not on how the cloud is configured but we think 
that it could be extended

to perform such verification with the adequate datasource.
So we propose a new datasource that will query each node to fetch its 
configuration files as long as they follow oslo.config requirements and 
structure.
As a first step we propose to use agents deployed on the different nodes 
explicitly configured with the list of configuration files that push 
those files to the central
congress service. Later on, oslo.config could be modified to provide a 
hook used to push config files directly from running services.


The new datasource displays not only the option values, the file, host 
where they are defined but also the associated metadata so that generic 
rules can be defined.

It is then possible to define rules:
- that constrain the value of options between different nodes
- that constrain the values between different services or different 
service plugins.
- it is even possible to use the knowledge of those configuration 
options to check policies on live resources (for example when there is a 
limitation or a bug in a given

driver).

We have a working prototype and the corresponding specification along 
those principles that we would like to share. An initial blueprint has 
been submitted here:

Please feel free to react

V. Matton

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


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

Re: [openstack-dev] [Openstack-dev] [Congress] [Designate]

[Tim Hinrichs]

This error happens happens when the translator thinks there's an
object/dictionary when in actuality there's just a string.  I don't know of
a good way to know where in the translator the problem is, other than
simplifying the input and the translator and rerunning (which you're
already doing).

Tim

On Thu, Jun 15, 2017 at 12:52 AM Carmine Annunziata <
carmine.annunziat...@gmail.com> wrote:

> Hi everyone,
> I wrote a congress datasource driver and its unit test for designate, but
> i got the following errors in the method test_update_from_datasource. It's
> something wrong in the translation.
> Here is the traceback:
>
>  File "congress/tests/datasources/test_designate_driver.py", line 34, in
> setUp
> self.driver = designate_driver.DesignateDriver(args=args)
>   File "congress/datasources/designate_driver.py", line 150, in __init__
> super(DesignateDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 1282, in __init__
> super(PollingDataSourceDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 324, in __init__
> self.initialize_translators()
>   File "congress/datasources/datasource_driver.py", line 1324, in
> initialize_translators
> self.register_translator(translator)
>   File "congress/datasources/datasource_driver.py", line 457, in
> register_translator
> self._validate_translator(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 389, in
> _validate_hdict_type
> self._validate_translator(subtranslator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 386, in
> _validate_hdict_type
> self.check_params(field_translator.keys(),
> AttributeError: 'str' object has no attribute 'keys'
>
> Thank you,
> Carmine
> __
> 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] [Openstack-dev] [Congress] [Designate]

[Eric K]

Hi Carmine,

Yes, I¹d guess that the translator you defined attempted to go deeper than
the structure obtained by API. If you push the changes to
review.openstack.org you may get better feedback =)

Eric

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

Date:  Thursday, June 15, 2017 at 12:51 AM
To:  
Subject:  [openstack-dev] [Openstack-dev] [Congress] [Designate]

> Hi everyone,
> I wrote a congress datasource driver and its unit test for designate, but i
> got the following errors in the method test_update_from_datasource. It's
> something wrong in the translation.
> Here is the traceback:
> 
>  File "congress/tests/datasources/test_designate_driver.py", line 34, in setUp
> self.driver = designate_driver.DesignateDriver(args=args)
>   File "congress/datasources/designate_driver.py", line 150, in __init__
> super(DesignateDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 1282, in __init__
> super(PollingDataSourceDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 324, in __init__
> self.initialize_translators()
>   File "congress/datasources/datasource_driver.py", line 1324, in
> initialize_translators
> self.register_translator(translator)
>   File "congress/datasources/datasource_driver.py", line 457, in
> register_translator
> self._validate_translator(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 389, in
> _validate_hdict_type
> self._validate_translator(subtranslator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 386, in
> _validate_hdict_type
> self.check_params(field_translator.keys(),
> AttributeError: 'str' object has no attribute 'keys'
> 
> Thank you,
> Carmine
> __
> 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] [Openstack-dev] [Congress] [Designate]

[Carmine Annunziata]

Hi everyone,
I wrote a congress datasource driver and its unit test for designate, but i
got the following errors in the method test_update_from_datasource. It's
something wrong in the translation.
Here is the traceback:

 File "congress/tests/datasources/test_designate_driver.py", line 34, in
setUp
self.driver = designate_driver.DesignateDriver(args=args)
  File "congress/datasources/designate_driver.py", line 150, in __init__
super(DesignateDriver, self).__init__(name, args=args)
  File "congress/datasources/datasource_driver.py", line 1282, in __init__
super(PollingDataSourceDriver, self).__init__(name, args=args)
  File "congress/datasources/datasource_driver.py", line 324, in __init__
self.initialize_translators()
  File "congress/datasources/datasource_driver.py", line 1324, in
initialize_translators
self.register_translator(translator)
  File "congress/datasources/datasource_driver.py", line 457, in
register_translator
self._validate_translator(translator, related_tables)
  File "congress/datasources/datasource_driver.py", line 446, in
_validate_translator
self._validate_by_translation_type(translator, related_tables)
  File "congress/datasources/datasource_driver.py", line 428, in
_validate_by_translation_type
self._validate_hdict_type(translator, related_tables)
  File "congress/datasources/datasource_driver.py", line 389, in
_validate_hdict_type
self._validate_translator(subtranslator, related_tables)
  File "congress/datasources/datasource_driver.py", line 446, in
_validate_translator
self._validate_by_translation_type(translator, related_tables)
  File "congress/datasources/datasource_driver.py", line 428, in
_validate_by_translation_type
self._validate_hdict_type(translator, related_tables)
  File "congress/datasources/datasource_driver.py", line 386, in
_validate_hdict_type
self.check_params(field_translator.keys(),
AttributeError: 'str' object has no attribute 'keys'

Thank you,
Carmine
__
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] policy monitoring panel design

[Eric K]

Here's a quick & rough mock-up I put up based on the discussions at Atlanta
PTG.

https://wireframepro.mockflow.com/view/congress-policy-monitor

Anyone can view and comment. To make changes, please sign-up and email me
to get access.
__
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] policy library tasks

[Eric K]

Hi all!

I have organized the tasks for policy library here:
https://bugs.launchpad.net/congress/+bugs?field.tag=policy-lib
Please take a look and feel free to pick up, comment, modify, etc.

The four non-GUI high importance items are essential for rolling out this
feature.
The high importance GUI item
(https://bugs.launchpad.net/congress/+bug/1670535) would be really great
to have for usability and demo-ability.

The medium importance items relate to supporting policy library CRUD and
are desirable but not essential.

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] [congress] queens PTG

[Eric K]

Hi Congress folks,

As mentioned in previous meetings, we need to decide this week whether to have 
work sessions at the next PTG (expected to be September 11-15, 2017 in Denver, 
CO).

Please reply to me 1) whether you think we should have sessions at the PTG and 
2) if we have sessions whether you expect to attend.

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] meeting topics

[Eric K]

Hi all,

Even though some of us are at the OS summit and may not make the meeting,
let¹s have a meeting anyway for those of us who can make it.

As usual, the collaborative list of topics are kept here:
https://etherpad.openstack.org/p/congress-meeting-topics


__
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] meeting topics

[Eric K]

Hi all,

Proposed topics for the next congress irc meeting are tracked in this
etherpad: https://etherpad.openstack.org/p/congress-meeting-topics
Feel free to add additional topics and/or comment on existing ones. 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

[openstack-dev] [Congress] Tempest test (congress-datasources)

[Carmine Annunziata]

Carmine
-- Messaggio inoltrato --
Da: "Carmine Annunziata" 
Data: 16 apr 2017 18:21
Oggetto: Tempest test (congress-datasources)
A: "Tim Hinrichs" 
Cc: "Eric K" 

Hi guys,
I'm trying to write the tempest test for magnum in the
scenario/congress_datasources dir. Which test_driver may I use for base off
of?

Thank you,
-- 
Carmine
__
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] meeting topics

[Eric K]

Hi all,

Proposed topics for the next congress irc meeting are tracked in this
etherpad: https://etherpad.openstack.org/p/congress-meeting-topics
Feel free to add additional topics and/or comment on existing ones. 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

[openstack-dev] [congress] DST transition reminder

[Eric K]

Hi all,

Friendly reminder that for US folks the IRC meeting this week is one hour
³later² (5PM PST, 8PM EST) due DST.

Proposed topics for the next congress irc meeting are tracked in this
etherpad: https://etherpad.openstack.org/p/congress-meeting-topics
Feel free to add additional topics and/or comment on existing ones. 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

[openstack-dev] [congress] meeting topics

[Eric K]

Hi all,

Proposed topics for the next congress irc meeting are tracked in this
etherpad: https://etherpad.openstack.org/p/congress-meeting-topics
Feel free to add additional topics and/or comment on existing ones. 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

[openstack-dev] [congress] Pike tasks

[Eric K]

Hi all,

Based on our discussions at the PTG, I have set up some tasks for Pike.
https://bugs.launchpad.net/congress/+bugs?field.tag=pike-goal

Feel free to adjust them (text, priority, target, assignee, etc.) or suggest
changes as you see fit.


__
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] Friday aquarium trip

[Eric K]

For those interested, a few of us at the PTG are going to the Georgia Aquarium 
Friday (2/24) morning. All welcome!
Meet at Sheraton hotel lobby at 9:30AM.
Purchase your ticket in advance here for early bird pricing (valid for entering 
before 11am):  
https://estore.georgiaaquarium.org/webstore/shop/viewitems.aspx?cg=store&c=ebd
__
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] Ocata retrospective brainstorm

[Eric K]

Hi Congress folks,

At the PTG, we¹ll be starting with an Ocata retrospective to look at what we
may want to do more/less/same to make our work easier and better going
forward.

Feel free to get a head-start by thinking about what you¹d like to see us do
more/less/same of and putting them down in this ethercalc. All aspects
welcome =)

https://ethercalc.openstack.org/0mhh0iv0oz4b

See you all 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

[openstack-dev] [Congress] no IRC meeting this week

[Eric K]

Congress IRC meeting cancelled this week for the PTG. Meeting will resume
next week (Mar 2 UTC). 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

[openstack-dev] [congress] congress 5.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/ocata

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/



__
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 Friday activities

[Masahito MUROI]

Hi Eric,

Both looks interesting, so I'm ok for either.  If I need to pick one of 
them, I prefer the Aquarium.


Masahito

On 2017/02/16 8:06, Eric K wrote:

Hi all,

Here are some options (thinrichs originally suggested) we could consider
for a Friday daytime outing for those interested.

Anyone interested?
Any other ideas?

Georgia Aquarium
- 1st or 2nd largest aquarium in the world.
- #1 on tripAdvisor
- $31.95+tax/adult (advanced online purchase)
http://www.georgiaaquarium.org
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia_Aquarium-Atlanta_Georgia.html

Atlanta Botanical Garden
- #3 on tripAdvisor
- $21.95+tax/adult
http://atlantabg.org
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta_Botanical_Garden-Atlanta_Georgia.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




--
室井 雅仁(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-dev] [Congress] PTG Friday activities

[Eric K]

Hi all,

Here are some options (thinrichs originally suggested) we could consider for
a Friday daytime outing for those interested.

Anyone interested?
Any other ideas?

Georgia Aquarium
- 1st or 2nd largest aquarium in the world.
- #1 on tripAdvisor
- $31.95+tax/adult (advanced online purchase)
http://www.georgiaaquarium.org
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia
_Aquarium-Atlanta_Georgia.html

Atlanta Botanical Garden
- #3 on tripAdvisor
- $21.95+tax/adult
http://atlantabg.org
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta
_Botanical_Garden-Atlanta_Georgia.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] [Congress] PTG rough schedule

[Eric K]

Hi all!

I've put down a rough proposed schedule for our PTG sessions in the
etherpad (https://etherpad.openstack.org/p/congress-ptg-pike) and also
copied below. Please feel free to think about and express how you like &
dislike the proposed schedule and we¹ll finalize it in the IRC meeting. In
any case, it¹ll be more of a loose guide than a strict schedule. Thanks!

Wednesday:
9-10: ocata retrospective. what do we want to do more of? less of?
10-lunch:
- testing, quality, maturity and maintenance (TQMM)
- community
after lunch:
- new concepts (1st pass)
- integration features

Thursday:
before lunch:
- new concepts (2nd pass)
- policy library
after lunch:
- internal features
- UI features
last hour: Pike priorities



__
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 pre-discussions

[Eric K]

Hi all!

In preparing for the PTG discussions, how about we do the following things
between now and the Congress PTG sessions?
Etherpad: https://etherpad.openstack.org/p/congress-ptg-pike

1. If you¹re interested in starting the discussion on an item, put [init:
your_name_or_nick] at the start of the etherpad item, do some preliminary
thinking/investigation, possibly add some notes to the etherpad, and be
ready to start the discussion on the item. Multiple people can volunteer for
the same item.
2. If you think a certain item is important to discuss at the PTG, put (+1
your_name_or_nick) at the start of the etherpad item. If we can¹t get to all
the items, we can use these votes as a rough guide to priority.
3. (We¹ve already been doing this.) Continue thinking, commenting, asking
questions about the items on the etherpad.


__
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 Activities options

[Tim Hinrichs]

Hi all,

At the last IRC I volunteered to pick out a couple of group activities for
the upcoming PTG.  First cut is below.  I could imagine dinner, an outing,
or both.

Restaurants
---
Two options jumped out at me.  If neither of these seems good I can keep
looking.

1. Desta Ethiopian Kitchen
# 10 on Trip Advisor
Ethiopian
20 min drive
Vegetarian-friendly
https://www.tripadvisor.com/Restaurant_Review-g60898-d1597692-Reviews-Desta_Ethiopian_Kitchen-Atlanta_Georgia.html

2. R. Thomas Deluxe Grill
#185 on TripAdvisor
American; large menu; "visually stimulating" restaurant
12 min drive
Vegetarian-friendly
https://www.tripadvisor.com/Restaurant_Review-g60898-d435430-Reviews-R_Thomas_Deluxe_Grill-Atlanta_Georgia.html

Outings
--
1. Botanical gardens
# 3 on TripAdvisor
13 min drive
open 9a-5p
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta_Botanical_Garden-Atlanta_Georgia.html

2. Aquarium
#1 on TripAdvisor
1 mile from PTG hotel
open 10a-5p
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia_Aquarium-Atlanta_Georgia.html

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

Re: [openstack-dev] [Congress][olso][oslo.messaging] Dynamically Determine Rabbit Transport URL?

[Clint Byrum]

Excerpts from Jay Pipes's message of 2017-02-06 16:23:51 -0500:
> On 02/06/2017 04:09 PM, Aimee Ukasick wrote:
> > Thanks, Clint, for your quick response. Questions inline.
> > On 02/06/2017 01:32 PM, Clint Byrum wrote:
> >> Excerpts from Aimee Ukasick's message of 2017-02-06 12:57:28 -0600:
> >>> Hi everyone - from the Congress standalone installation guide
> >>> (http://docs.openstack.org/developer/congress/README.html#installing-congress):
> >>>
> >>> ---
> >>> To use RabbitMQ with Congress, set the transport_url in the “From
> >>> oslo.messaging” section according to your setup:
> >>> transport_url = rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:5672
> >>> ---
> >>>
> >>> Is there a CLI or API call to determine the Rabbit userID, password,
> >>> host, and port from a running OpenStack installation? My colleague and I
> >>> are working on standalone Congress installation scripts (bash), and we
> >>> are trying to figure how to dynamically determine the RABBIT_USERID,
> >>> RABBIT_PASSWORD, RABBIT_HOST, and port.  We really don't want to resort
> >>> to pulling the transport URL out of another service's conf file
> >>> (nova.conf, heat.conf, keystone.conf, etc).
> >>>
> >>> There is a rabbitmqctl
> >>> https://www.rabbitmq.com/man/rabbitmqctl.1.man.html  but that doesn't
> >>> have the commands for finding userID, password, host, and port.
> >
> >>
> >> Those conf files get it from the same place you should: Config
> >> management. You need to inject it into your bash however you inject
> >> details of the environment into anything else.
> >>
> >
> > I'm relatively new to OpenStack, so please pardon my ignorance. What do
> > you mean by config management? We don't have any details about how
> > OpenStack has been installed - it may have been installed by an OPNFV
> > Installer, an OpenStack installer, or some other way. We are looking for
> > an installer-agnostic means of determining: 1) where Rabbit is installed
> > and running as a service (rabbit_host); and 2) how to obtain the rabbit
> > UserID and password so we can configure the transport_url.
> >
> > Also, my colleague and I can't assume that Congress or Tacker or another
> > OpenStack service is going to be installed on the Controller node. What
> > if we are installing the OpenStack service in a Docker container that's
> > not on the Controller? We aren't OpenStack experts, so any guidance is
> > greatly appreciated.
> 
> Hi Aimee,
> 
> I think what Clint is saying is that storing and retrieving the 
> configuration information for things like rabbitmq (or databases and 
> things like that) is not in the purview of OpenStack itself, but rather 
> is the responsibility of the tooling that you used to deploy OpenStack 
> (and other applications) in your environment.
> 
> Whether it's Chef, Puppet, SaltStack, Ansible, or any other 
> configuration management tool, each one generally has one or more 
> methods to grab and store sensitive configuration information. Same for 
> things like Kubernetes and Terraform. Each uses different ways of 
> storing and distributing that information.
> 
> Depending on how your infrastructure was deployed, you will need to use 
> the method appropriate to that configuration management system.

^^ yeah, what Jay said.

__
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][olso][oslo.messaging] Dynamically Determine Rabbit Transport URL?

[Jay Pipes]

On 02/06/2017 04:09 PM, Aimee Ukasick wrote:

Thanks, Clint, for your quick response. Questions inline.
On 02/06/2017 01:32 PM, Clint Byrum wrote:

Excerpts from Aimee Ukasick's message of 2017-02-06 12:57:28 -0600:

Hi everyone - from the Congress standalone installation guide
(http://docs.openstack.org/developer/congress/README.html#installing-congress):

---
To use RabbitMQ with Congress, set the transport_url in the “From
oslo.messaging” section according to your setup:
transport_url = rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:5672
---

Is there a CLI or API call to determine the Rabbit userID, password,
host, and port from a running OpenStack installation? My colleague and I
are working on standalone Congress installation scripts (bash), and we
are trying to figure how to dynamically determine the RABBIT_USERID,
RABBIT_PASSWORD, RABBIT_HOST, and port.  We really don't want to resort
to pulling the transport URL out of another service's conf file
(nova.conf, heat.conf, keystone.conf, etc).

There is a rabbitmqctl
https://www.rabbitmq.com/man/rabbitmqctl.1.man.html  but that doesn't
have the commands for finding userID, password, host, and port.




Those conf files get it from the same place you should: Config
management. You need to inject it into your bash however you inject
details of the environment into anything else.



I'm relatively new to OpenStack, so please pardon my ignorance. What do
you mean by config management? We don't have any details about how
OpenStack has been installed - it may have been installed by an OPNFV
Installer, an OpenStack installer, or some other way. We are looking for
an installer-agnostic means of determining: 1) where Rabbit is installed
and running as a service (rabbit_host); and 2) how to obtain the rabbit
UserID and password so we can configure the transport_url.

Also, my colleague and I can't assume that Congress or Tacker or another
OpenStack service is going to be installed on the Controller node. What
if we are installing the OpenStack service in a Docker container that's
not on the Controller? We aren't OpenStack experts, so any guidance is
greatly appreciated.


Hi Aimee,

I think what Clint is saying is that storing and retrieving the 
configuration information for things like rabbitmq (or databases and 
things like that) is not in the purview of OpenStack itself, but rather 
is the responsibility of the tooling that you used to deploy OpenStack 
(and other applications) in your environment.


Whether it's Chef, Puppet, SaltStack, Ansible, or any other 
configuration management tool, each one generally has one or more 
methods to grab and store sensitive configuration information. Same for 
things like Kubernetes and Terraform. Each uses different ways of 
storing and distributing that information.


Depending on how your infrastructure was deployed, you will need to use 
the method appropriate to that configuration management system.


Best,
-jay

__
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][olso][oslo.messaging] Dynamically Determine Rabbit Transport URL?

[Aimee Ukasick]

Thanks, Clint, for your quick response. Questions inline.
On 02/06/2017 01:32 PM, Clint Byrum wrote:
> Excerpts from Aimee Ukasick's message of 2017-02-06 12:57:28 -0600:
>> Hi everyone - from the Congress standalone installation guide
>> (http://docs.openstack.org/developer/congress/README.html#installing-congress):
>>
>> ---
>> To use RabbitMQ with Congress, set the transport_url in the “From
>> oslo.messaging” section according to your setup:
>> transport_url = rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:5672
>> ---
>>
>> Is there a CLI or API call to determine the Rabbit userID, password,
>> host, and port from a running OpenStack installation? My colleague and I
>> are working on standalone Congress installation scripts (bash), and we
>> are trying to figure how to dynamically determine the RABBIT_USERID,
>> RABBIT_PASSWORD, RABBIT_HOST, and port.  We really don't want to resort
>> to pulling the transport URL out of another service's conf file
>> (nova.conf, heat.conf, keystone.conf, etc).
>>
>> There is a rabbitmqctl
>> https://www.rabbitmq.com/man/rabbitmqctl.1.man.html  but that doesn't
>> have the commands for finding userID, password, host, and port.

> 
> Those conf files get it from the same place you should: Config
> management. You need to inject it into your bash however you inject
> details of the environment into anything else.
> 

I'm relatively new to OpenStack, so please pardon my ignorance. What do
you mean by config management? We don't have any details about how
OpenStack has been installed - it may have been installed by an OPNFV
Installer, an OpenStack installer, or some other way. We are looking for
an installer-agnostic means of determining: 1) where Rabbit is installed
and running as a service (rabbit_host); and 2) how to obtain the rabbit
UserID and password so we can configure the transport_url.

Also, my colleague and I can't assume that Congress or Tacker or another
OpenStack service is going to be installed on the Controller node. What
if we are installing the OpenStack service in a Docker container that's
not on the Controller? We aren't OpenStack experts, so any guidance is
greatly appreciated.

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][olso][oslo.messaging] Dynamically Determine Rabbit Transport URL?

[Clint Byrum]

Excerpts from Aimee Ukasick's message of 2017-02-06 12:57:28 -0600:
> Hi everyone - from the Congress standalone installation guide
> (http://docs.openstack.org/developer/congress/README.html#installing-congress):
> 
> ---
> To use RabbitMQ with Congress, set the transport_url in the “From
> oslo.messaging” section according to your setup:
> transport_url = rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:5672
> ---
> 
> Is there a CLI or API call to determine the Rabbit userID, password,
> host, and port from a running OpenStack installation? My colleague and I
> are working on standalone Congress installation scripts (bash), and we
> are trying to figure how to dynamically determine the RABBIT_USERID,
> RABBIT_PASSWORD, RABBIT_HOST, and port.  We really don't want to resort
> to pulling the transport URL out of another service's conf file
> (nova.conf, heat.conf, keystone.conf, etc).
> 
> There is a rabbitmqctl
> https://www.rabbitmq.com/man/rabbitmqctl.1.man.html  but that doesn't
> have the commands for finding userID, password, host, and port.

Those conf files get it from the same place you should: Config
management. You need to inject it into your bash however you inject
details of the environment into anything else.

__
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][olso][oslo.messaging] Dynamically Determine Rabbit Transport URL?

[Aimee Ukasick]

Hi everyone - from the Congress standalone installation guide
(http://docs.openstack.org/developer/congress/README.html#installing-congress):

---
To use RabbitMQ with Congress, set the transport_url in the “From
oslo.messaging” section according to your setup:
transport_url = rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:5672
---

Is there a CLI or API call to determine the Rabbit userID, password,
host, and port from a running OpenStack installation? My colleague and I
are working on standalone Congress installation scripts (bash), and we
are trying to figure how to dynamically determine the RABBIT_USERID,
RABBIT_PASSWORD, RABBIT_HOST, and port.  We really don't want to resort
to pulling the transport URL out of another service's conf file
(nova.conf, heat.conf, keystone.conf, etc).

There is a rabbitmqctl
https://www.rabbitmq.com/man/rabbitmqctl.1.man.html  but that doesn't
have the commands for finding userID, password, host, and port.

Any ideas or other places I should look/ask for help is greatly appreciated.

Thanks!


Aimee Ukasick
AT&T Open Source

__
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] congress 5.0.0.0rc1 (ocata)

[Eric K]

RC1 released. Great job everyone for getting our fixes in!

Let¹s continue testing and reporting bugs to make sure Ocata is a
rock-solid release!

On 2/2/17, 5:01 PM, "no-re...@openstack.org" 
wrote:

>
>Hello everyone,
>
>A new release candidate for congress for the end of the Ocata
>cycle is available!  You can find the source code tarball at:
>
>https://tarballs.openstack.org/congress/
>
>Unless release-critical issues are found that warrant a release
>candidate respin, this candidate will be formally released as the
>final Ocata release. You are therefore strongly
>encouraged to test and validate this tarball!
>
>Alternatively, you can directly test the stable/ocata release
>branch at:
>
>http://git.openstack.org/cgit/openstack/congress/log/?h=stable/ocata
>
>Release notes for congress can be found at:
>
>http://docs.openstack.org/releasenotes/congress/
>
>
>
>__
>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] congress 5.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/ocata

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/



__
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] ocata client causes feature regression with pre-ocata server

[Eric K]

Thanks Tim and Monty!

I also agree with ( c ). Here’s a simple patch doing that:
https://review.openstack.org/#/c/424385/

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

Date:  Monday, January 23, 2017 at 7:55 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [congress] ocata client causes feature
regression with pre-ocata server

> At some point the client sometimes made multiple API calls.  I think (c) seems
> right too.  
> 
> Tim 
> 
> On Sun, Jan 22, 2017 at 1:15 AM Monty Taylor  wrote:
>> On 01/21/2017 04:07 AM, Eric K wrote:
>>> > Hi all,
>>> >
>>> > I was getting ready to request release of congress client, but I
>>> > remembered that the new client causes feature regression if used with
>>> > older versions of congress. Specifically, new client with pre-Ocata
>>> > congress cannot refer to datasource by name, something that could be done
>>> > with pre-Ocata client.
>>> >
>>> > Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
>>> > <https://review.openstack.org/#/c/407329/4>
>>> >
>>> > A few questions:
>>> >
>>> > Are we okay with the regression? Seems like it could cause a fair bit of
>>> > annoyance for users.
>> 
>> This is right. New client lib should always continue to work with old
>> server. (A user should be able to just pip install python-congressclient
>> and have it work regardless of when their operator decides to upgrade or
>> not upgrade their cloud)
>> 
>>> >1. If we¹re okay with that, what¹s the best way to document that
>>> > pre-Ocata congress should be used with pre-Ocata client?
>>> >2. If not, how we avoid the regression? Here are some candidates I can
>>> > think of.
>>> >   a. Client detects congress version and act accordingly. I don¹t
>>> > think this is possible, nor desirable for client to be concerned with
>>> > congress version not just API version.
>>> >   b. Release backward compatible API version 1.1 that supports
>>> > getting datasource by name_or_id. Then client will take different paths
>>> > depending on API version.
>>> >   c. If datasource not found, client falls back on old method of
>>> > retrieving list of datasources to resolve name into UUID. This would work,
>>> > but causes extra API & DB call in many cases.
>>> >   d. Patch old versions of Congress to support getting datasource
>>> > by name_or_id. Essentially, it was always a bug that the API didn¹t
>>> > support name_or_id.
>> 
>> I'm a fan of d - but I don't believe it will help - since the problem
>> will still manifest for users who do not have control over the server
>> installation.
>> 
>> I'd suggest c is the most robust. It _is_ potentially more expensive -
>> but that's a good motivation for the deployer to upgrade their
>> installation of congress without negatively impacting the consumer in
>> the  meantime.
>> 
>> Monty
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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

Re: [openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

[Tim Hinrichs]

At some point the client sometimes made multiple API calls.  I think (c)
seems right too.

Tim

On Sun, Jan 22, 2017 at 1:15 AM Monty Taylor  wrote:

> On 01/21/2017 04:07 AM, Eric K wrote:
> > Hi all,
> >
> > I was getting ready to request release of congress client, but I
> > remembered that the new client causes feature regression if used with
> > older versions of congress. Specifically, new client with pre-Ocata
> > congress cannot refer to datasource by name, something that could be done
> > with pre-Ocata client.
> >
> > Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> > 
> >
> > A few questions:
> >
> > Are we okay with the regression? Seems like it could cause a fair bit of
> > annoyance for users.
>
> This is right. New client lib should always continue to work with old
> server. (A user should be able to just pip install python-congressclient
> and have it work regardless of when their operator decides to upgrade or
> not upgrade their cloud)
>
> >1. If we¹re okay with that, what¹s the best way to document that
> > pre-Ocata congress should be used with pre-Ocata client?
> >2. If not, how we avoid the regression? Here are some candidates I can
> > think of.
> >   a. Client detects congress version and act accordingly. I don¹t
> > think this is possible, nor desirable for client to be concerned with
> > congress version not just API version.
> >   b. Release backward compatible API version 1.1 that supports
> > getting datasource by name_or_id. Then client will take different paths
> > depending on API version.
> >   c. If datasource not found, client falls back on old method of
> > retrieving list of datasources to resolve name into UUID. This would
> work,
> > but causes extra API & DB call in many cases.
> >   d. Patch old versions of Congress to support getting datasource
> > by name_or_id. Essentially, it was always a bug that the API didn¹t
> > support name_or_id.
>
> I'm a fan of d - but I don't believe it will help - since the problem
> will still manifest for users who do not have control over the server
> installation.
>
> I'd suggest c is the most robust. It _is_ potentially more expensive -
> but that's a good motivation for the deployer to upgrade their
> installation of congress without negatively impacting the consumer in
> the  meantime.
>
> Monty
>
> __
> 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] ocata client causes feature regression with pre-ocata server

[Monty Taylor]

On 01/21/2017 04:07 AM, Eric K wrote:
> Hi all,
> 
> I was getting ready to request release of congress client, but I
> remembered that the new client causes feature regression if used with
> older versions of congress. Specifically, new client with pre-Ocata
> congress cannot refer to datasource by name, something that could be done
> with pre-Ocata client.
> 
> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> 
> 
> A few questions:
> 
> Are we okay with the regression? Seems like it could cause a fair bit of
> annoyance for users.

This is right. New client lib should always continue to work with old
server. (A user should be able to just pip install python-congressclient
and have it work regardless of when their operator decides to upgrade or
not upgrade their cloud)

>1. If we¹re okay with that, what¹s the best way to document that
> pre-Ocata congress should be used with pre-Ocata client?
>2. If not, how we avoid the regression? Here are some candidates I can
> think of. 
>   a. Client detects congress version and act accordingly. I don¹t
> think this is possible, nor desirable for client to be concerned with
> congress version not just API version.
>   b. Release backward compatible API version 1.1 that supports
> getting datasource by name_or_id. Then client will take different paths
> depending on API version.
>   c. If datasource not found, client falls back on old method of
> retrieving list of datasources to resolve name into UUID. This would work,
> but causes extra API & DB call in many cases.
>   d. Patch old versions of Congress to support getting datasource
> by name_or_id. Essentially, it was always a bug that the API didn¹t
> support name_or_id.

I'm a fan of d - but I don't believe it will help - since the problem
will still manifest for users who do not have control over the server
installation.

I'd suggest c is the most robust. It _is_ potentially more expensive -
but that's a good motivation for the deployer to upgrade their
installation of congress without negatively impacting the consumer in
the  meantime.

Monty

__
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] ocata client causes feature regression with pre-ocata server

[Eric K]

Hi Tim,
I thought something like that would work. But actually python-congressclient
is not a listed requirement of congress server, no vice versa. Which is
correct in the sense that installing and running one does not require
installing the other on the same machine.

From:  Tim Hinrichs 
Date:  Saturday, January 21, 2017 at 2:33 PM
To:  Eric Kao , "OpenStack Development Mailing
List (not for usage questions)" 
Subject:  Re: [congress] ocata client causes feature regression with
pre-ocata server

> How about we go into the preocata server and change requirements.txt to ensure
> it only supports the older clients. Something like...
> 
> Python-congressclient>2.3<2.5
> 
> Or whatever the versions are.
> 
> Tim
> 
> 
> On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:
>> Hi all,
>> 
>> I was getting ready to request release of congress client, but I
>> remembered that the new client causes feature regression if used with
>> older versions of congress. Specifically, new client with pre-Ocata
>> congress cannot refer to datasource by name, something that could be done
>> with pre-Ocata client.
>> 
>> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
>> 
>> 
>> A few questions:
>> 
>> Are we okay with the regression? Seems like it could cause a fair bit of
>> annoyance for users.
>>1. If we¹re okay with that, what¹s the best way to document that
>> pre-Ocata congress should be used with pre-Ocata client?
>>2. If not, how we avoid the regression? Here are some candidates I can
>> think of.
>>   a. Client detects congress version and act accordingly. I don¹t
>> think this is possible, nor desirable for client to be concerned with
>> congress version not just API version.
>>   b. Release backward compatible API version 1.1 that supports
>> getting datasource by name_or_id. Then client will take different paths
>> depending on API version.
>>   c. If datasource not found, client falls back on old method of
>> retrieving list of datasources to resolve name into UUID. This would work,
>> but causes extra API & DB call in many cases.
>>   d. Patch old versions of Congress to support getting datasource
>> by name_or_id. Essentially, it was always a bug that the API didn¹t
>> support name_or_id.
>> 
>> 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] ocata client causes feature regression with pre-ocata server

[Tim Hinrichs]

How about we go into the preocata server and change requirements.txt to
ensure it only supports the older clients. Something like...

Python-congressclient>2.3<2.5

Or whatever the versions are.

Tim


On Fri, Jan 20, 2017 at 7:07 PM Eric K  wrote:

> Hi all,
>
> I was getting ready to request release of congress client, but I
> remembered that the new client causes feature regression if used with
> older versions of congress. Specifically, new client with pre-Ocata
> congress cannot refer to datasource by name, something that could be done
> with pre-Ocata client.
>
> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> 
>
> A few questions:
>
> Are we okay with the regression? Seems like it could cause a fair bit of
> annoyance for users.
>1. If we¹re okay with that, what¹s the best way to document that
> pre-Ocata congress should be used with pre-Ocata client?
>2. If not, how we avoid the regression? Here are some candidates I can
> think of.
>   a. Client detects congress version and act accordingly. I don¹t
> think this is possible, nor desirable for client to be concerned with
> congress version not just API version.
>   b. Release backward compatible API version 1.1 that supports
> getting datasource by name_or_id. Then client will take different paths
> depending on API version.
>   c. If datasource not found, client falls back on old method of
> retrieving list of datasources to resolve name into UUID. This would work,
> but causes extra API & DB call in many cases.
>   d. Patch old versions of Congress to support getting datasource
> by name_or_id. Essentially, it was always a bug that the API didn¹t
> support name_or_id.
>
> 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

[openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

[Eric K]

Hi all,

I was getting ready to request release of congress client, but I
remembered that the new client causes feature regression if used with
older versions of congress. Specifically, new client with pre-Ocata
congress cannot refer to datasource by name, something that could be done
with pre-Ocata client.

Here¹s the patch of interest: https://review.openstack.org/#/c/407329/


A few questions:

Are we okay with the regression? Seems like it could cause a fair bit of
annoyance for users.
   1. If we¹re okay with that, what¹s the best way to document that
pre-Ocata congress should be used with pre-Ocata client?
   2. If not, how we avoid the regression? Here are some candidates I can
think of.   
  a. Client detects congress version and act accordingly. I don¹t
think this is possible, nor desirable for client to be concerned with
congress version not just API version.
  b. Release backward compatible API version 1.1 that supports
getting datasource by name_or_id. Then client will take different paths
depending on API version.
  c. If datasource not found, client falls back on old method of
retrieving list of datasources to resolve name into UUID. This would work,
but causes extra API & DB call in many cases.
  d. Patch old versions of Congress to support getting datasource
by name_or_id. Essentially, it was always a bug that the API didn¹t
support name_or_id.

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

Re: [openstack-dev] [congress][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[Brant Knudson]

On Thu, Jan 12, 2017 at 4:31 PM, Eric K  wrote:

> 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!
>
>
These options are for the auth token middleware. Services shouldn't be
using them directly.

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

[Carlos Gonçalves]

Hi Serg,

This is great news! On behalf of the OPNFV Doctor team, thank you Fuel@Opnfv
team for this effort!
We will certainly test it out as soon as possible, and we'll provide
feedback.

Cheers,
Carlos


On Mon, Jan 16, 2017 at 8:33 PM, 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][Fuel] Fuel plugin for installing Congress

[Serg Melikyan]

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

Re: [openstack-dev] [congress][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[Doug Hellmann]

Excerpts from Eric K's message of 2017-01-12 14:31:58 -0800:
> 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

Options are usually declared in the code that uses them, with a
call to register_opts() either at runtime or when a module is
imported.  You should ensure that your use of the option comes after
its declaration (having the option present in the configuration
file isn't the same as declaring it in the code).

One other important point: Options are not typically part of the
API of a library (at least not for Oslo libs, and we encourage that
same approach for other libs). If the options you need are defined
in a library, look for a public API to call to retrieve the values
or to instantiate objects using the config but without having your
application code rely on option definitions that may change as options
are moved or deprecated.

Doug

__
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][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[ChangBo Guo]

Did you search keyword in http://codesearch.openstack.org/.  Hope that will
help you.

2017-01-13 6:31 GMT+08:00 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
>
>


-- 
ChangBo Guo(gcb)
__
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

Re: [openstack-dev] [Congress] Installation/Deployment Docs

[Tim Hinrichs]

The reason we have devstack instructions under Users is because they are so
easy and make it simple to test drive Congress. To test drive you need at
least a couple of services besides Congress, which makes devstack a good
fit.

But maybe users don't care about install at all. Operators care about
install and upgrade. Users care about data sources, policies, etc.

Tim
On Tue, Jan 10, 2017 at 2:24 PM Aimee Ukasick 
wrote:

> Hi all. While looking at the installation docs in preparation for
> scripting and testing Congress installation
> (https://bugs.launchpad.net/congress/+bug/1651928), I noticed there are
> installation instructions in two places:  1) For Users: Congress
> Introduction and Installation; and 2) For Operators: Deployment. The
> "For Users" section details Devstack as well as Standalone installation.
>
> I would like to rearrange the content: 1) move README.rst/4.1
> Devstack-install and 4.3 Debugging unit tests to to the For
> Developers/Contributing section; 2) move README.rst/4.2 Standalone
> install and 4.4 Upgrade to the For Operators/Deployment section. I think
> this  would make it easier for end users to create an installation
> script or validate an existing script.
>
> Any objections or thoughts?
>
> Thanks.
>
> --
>
> Aimee Ukasick, AT&T Open Source
>
>
>
> __
> 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] Installation/Deployment Docs

[Aimee Ukasick]

Hi all. While looking at the installation docs in preparation for
scripting and testing Congress installation
(https://bugs.launchpad.net/congress/+bug/1651928), I noticed there are
installation instructions in two places:  1) For Users: Congress
Introduction and Installation; and 2) For Operators: Deployment. The
"For Users" section details Devstack as well as Standalone installation.

I would like to rearrange the content: 1) move README.rst/4.1
Devstack-install and 4.3 Debugging unit tests to to the For
Developers/Contributing section; 2) move README.rst/4.2 Standalone
install and 4.4 Upgrade to the For Operators/Deployment section. I think
this  would make it easier for end users to create an installation
script or validate an existing script.

Any objections or thoughts?

Thanks.

-- 

Aimee Ukasick, AT&T Open Source



__
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

Re: [openstack-dev] [Congress] [infra] tempest job timeout appears shorter than configured

[Jeremy Stanley]

On 2016-12-19 17:33:10 -0800 (-0800), Eric K wrote:
> 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!
[...]

Technically, yes, two different measures of time. The
devstack-vm-gate-wrap.sh script has some additional buffers built in
so that it can stop the job with enough time remaining to gather
logs and perform any necessary post-processing before the job
scheduler kills the machine it's running on. For details, see the
handling of the BUILD_TIMEOUT, DEVSTACK_GATE_TIMEOUT_BUFFER and
DEVSTACK_GATE_TIMEOUT variables starting at
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n382
 >.
-- 
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-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

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

That job is non-voting, which since you're adding a new datasource, you can
ignore.  Nothing to do now but wait for people to give you reviews.

Tim

On Mon, Dec 12, 2016 at 1:12 PM Ruben 
wrote:

> Hi Tim,
> thanks a lot for your help.
> I've seen that there is a failure for "gate-congress-pe-replicated-nv".
> It's strange because I didn't have failure before.
> So, what should I do now?
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Lunedì, 12 dicembre 2016 19:58:24
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> Looked like there were still multiple changes, so I squashed them into 1
> and fixed up the requirements.txt file.  (You should only need to add the
> python-magnumclient to the requirements.txt file.)  I also abandoned one
> that was incorporated into the one 1 fix.  Here it is.  Now the community
> should give you reviews.
>
> https://review.openstack.org/#/c/404222
>
> Tim
>
>
>
>
> On Fri, Dec 9, 2016 at 3:06 PM Ruben 
> wrote:
>
> > Hi Tim,
> > sorry for the late, but I've had a busy week.
> > Anyway, I've tried to add the magnum_driver to review into a single
> commit.
> > I don't know if I have been able..
> >
> > Ruben
> >
> > - Messaggio originale -
> > Da: "Tim Hinrichs" 
> > A: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Inviato: Mercoledì, 30 novembre 2016 22:04:32
> > Oggetto: Re: [Congress] Magnum_driver
> >
> > Hi Ruben,
> >
> > What you're doing is correct.  The downside is that it creates a new
> commit
> > for every change you make, and all of those commits show up on gerrit.
> In
> > OpenStack (and other projects I've seen that use Gerrit for code reviews)
> > you squash those commits into 1 change so that it's easier for reviewers
> to
> > see the change as a whole.  (Projects that use Github for code reviews do
> > more like what you're doing now).  To see your
> >
> > Here's a blog showing you what to do...
> > https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/
> >
> > You can probably do
> >
> > $ git rebase -i
> >
> > and then follow the instructions in the blog that say you replace the
> > 'pick' for all the commits after the first with 'squash' (or 's' for
> > short).  So something like the following.
> >
> > pick f392171 Added new feature X squash ba9dd9a Added new elements to
> page
> > design squash df71a27 Updated CSS for new elements
> >
> > After that, you should be able to do ...
> >
> > $ git review
> >
> > Tim
> >
> > On Wed, Nov 30, 2016 at 5:23 AM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > what should I do to squash all the commits into a single one?
> > >
> > > To add the code to review I made:
> > >
> > > git add 
> > > git commit
> > > git review
> > >
> > > Isn't it correct?
> > >
> > > Ruben
> > >
> > > - Messaggio originale -
> > > Da: "Tim Hinrichs" 
> > > A: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Inviato: Mercoledì, 30 novembre 2016 2:34:22
> > > Oggetto: Re: [Congress] Magnum_driver
> > >
> > > Hi Ruben,
> > >
> > > I left a comment on one of the changes; after you take care of that
> I'll
> > > take a closer look at the code.  Let me know if you have questions.
> > >
> > > Tim
> > >
> > > On Tue, Nov 29, 2016 at 4:06 AM Ruben <
> r.manganiel...@studenti.unisa.it>
> > > wrote:
> > >
> > > > Hi Tim,
> > > > I've added the code of magnum_driver and its unit test to review.
> > > > It seems everything works.
> > > >
> > > > Ruben
> > > >
> > > > - Original Message -
> > > > From: "Tim Hinrichs" 
> > > > To: "Ruben" 
> > > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > > timothy.l.hinri...@gmail.com>
> > > > Sent: Saturday, November 26, 2016 12:48:12 AM
> > > > Subject: Re: [Congress] Magnum_driver
> > > >
> > > > Definitely push that code up into Gerrit so we can all take a look.
> > Data
> > > > like pods and containers is probably the most valuable data from
> > Magnum,
> > > so
> > > > I'd definitely recommend adding that.  But push the code you have to
> > > Gerrit
> > > > first.  (As long as you leave the ChangeId the same each time you
> push
> > to
> > > > Gerrit, Gerrit will keep all of the versions you pushed organized
> > > together,
> > > > yet keep the versions separate.)
> > > >
> > > > Tim
> > > >
> > > > On Fri, Nov 25, 2016 at 3:06 PM Ruben <
> > r.manganiel...@studenti.unisa.it>
> > > > wrote:
> > > >
> > > > > Hi Tim,
> > > > > You are great. It works! Thanks a lot!
> > > > > I've also solved the problem with py27. The unit test seems to
> work.
> > > > > The only thing that seems not to work is populate the
> > 'clusters_links'
> > > > and
> > > > > 'cluster_templates_links' tables: they are empty.
> > > > > Also, the 'labels' table is empty.
> > > > > I've no errors anywa

Re: [openstack-dev] [Congress] Magnum_driver

[Ruben]

Hi Tim,
thanks a lot for your help.
I've seen that there is a failure for "gate-congress-pe-replicated-nv".
It's strange because I didn't have failure before.
So, what should I do now?

Ruben

- Messaggio originale -
Da: "Tim Hinrichs" 
A: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Inviato: Lunedì, 12 dicembre 2016 19:58:24
Oggetto: Re: [Congress] Magnum_driver

Hi Ruben,

Looked like there were still multiple changes, so I squashed them into 1
and fixed up the requirements.txt file.  (You should only need to add the
python-magnumclient to the requirements.txt file.)  I also abandoned one
that was incorporated into the one 1 fix.  Here it is.  Now the community
should give you reviews.

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

Tim




On Fri, Dec 9, 2016 at 3:06 PM Ruben 
wrote:

> Hi Tim,
> sorry for the late, but I've had a busy week.
> Anyway, I've tried to add the magnum_driver to review into a single commit.
> I don't know if I have been able..
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Mercoledì, 30 novembre 2016 22:04:32
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> What you're doing is correct.  The downside is that it creates a new commit
> for every change you make, and all of those commits show up on gerrit.  In
> OpenStack (and other projects I've seen that use Gerrit for code reviews)
> you squash those commits into 1 change so that it's easier for reviewers to
> see the change as a whole.  (Projects that use Github for code reviews do
> more like what you're doing now).  To see your
>
> Here's a blog showing you what to do...
> https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/
>
> You can probably do
>
> $ git rebase -i
>
> and then follow the instructions in the blog that say you replace the
> 'pick' for all the commits after the first with 'squash' (or 's' for
> short).  So something like the following.
>
> pick f392171 Added new feature X squash ba9dd9a Added new elements to page
> design squash df71a27 Updated CSS for new elements
>
> After that, you should be able to do ...
>
> $ git review
>
> Tim
>
> On Wed, Nov 30, 2016 at 5:23 AM Ruben 
> wrote:
>
> > Hi Tim,
> > what should I do to squash all the commits into a single one?
> >
> > To add the code to review I made:
> >
> > git add 
> > git commit
> > git review
> >
> > Isn't it correct?
> >
> > Ruben
> >
> > - Messaggio originale -
> > Da: "Tim Hinrichs" 
> > A: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Inviato: Mercoledì, 30 novembre 2016 2:34:22
> > Oggetto: Re: [Congress] Magnum_driver
> >
> > Hi Ruben,
> >
> > I left a comment on one of the changes; after you take care of that I'll
> > take a closer look at the code.  Let me know if you have questions.
> >
> > Tim
> >
> > On Tue, Nov 29, 2016 at 4:06 AM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > I've added the code of magnum_driver and its unit test to review.
> > > It seems everything works.
> > >
> > > Ruben
> > >
> > > - Original Message -
> > > From: "Tim Hinrichs" 
> > > To: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Sent: Saturday, November 26, 2016 12:48:12 AM
> > > Subject: Re: [Congress] Magnum_driver
> > >
> > > Definitely push that code up into Gerrit so we can all take a look.
> Data
> > > like pods and containers is probably the most valuable data from
> Magnum,
> > so
> > > I'd definitely recommend adding that.  But push the code you have to
> > Gerrit
> > > first.  (As long as you leave the ChangeId the same each time you push
> to
> > > Gerrit, Gerrit will keep all of the versions you pushed organized
> > together,
> > > yet keep the versions separate.)
> > >
> > > Tim
> > >
> > > On Fri, Nov 25, 2016 at 3:06 PM Ruben <
> r.manganiel...@studenti.unisa.it>
> > > wrote:
> > >
> > > > Hi Tim,
> > > > You are great. It works! Thanks a lot!
> > > > I've also solved the problem with py27. The unit test seems to work.
> > > > The only thing that seems not to work is populate the
> 'clusters_links'
> > > and
> > > > 'cluster_templates_links' tables: they are empty.
> > > > Also, the 'labels' table is empty.
> > > > I've no errors anyway.
> > > > Are these problems according to you?
> > > >
> > > > Should I to try to add the translation of pods, containers and
> > services?
> > > >
> > > > I've add the code to review.
> > > >
> > > > Ruben
> > > > - Original Message -
> > > > From: "Tim Hinrichs" 
> > > > To: "Ruben" 
> > > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > > timothy.l.hinri...@gmail.com>
> > > > Sent: Friday, November 25, 2016 10:36:29 PM
> > > > Subject: Re: [Congress] Magnum_driver
> > > >
> > > > Hi Ruben,
> > > >
> > > > Glad you got that worked out.  O

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

Hi Ruben,

Looked like there were still multiple changes, so I squashed them into 1
and fixed up the requirements.txt file.  (You should only need to add the
python-magnumclient to the requirements.txt file.)  I also abandoned one
that was incorporated into the one 1 fix.  Here it is.  Now the community
should give you reviews.

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

Tim




On Fri, Dec 9, 2016 at 3:06 PM Ruben 
wrote:

> Hi Tim,
> sorry for the late, but I've had a busy week.
> Anyway, I've tried to add the magnum_driver to review into a single commit.
> I don't know if I have been able..
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Mercoledì, 30 novembre 2016 22:04:32
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> What you're doing is correct.  The downside is that it creates a new commit
> for every change you make, and all of those commits show up on gerrit.  In
> OpenStack (and other projects I've seen that use Gerrit for code reviews)
> you squash those commits into 1 change so that it's easier for reviewers to
> see the change as a whole.  (Projects that use Github for code reviews do
> more like what you're doing now).  To see your
>
> Here's a blog showing you what to do...
> https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/
>
> You can probably do
>
> $ git rebase -i
>
> and then follow the instructions in the blog that say you replace the
> 'pick' for all the commits after the first with 'squash' (or 's' for
> short).  So something like the following.
>
> pick f392171 Added new feature X squash ba9dd9a Added new elements to page
> design squash df71a27 Updated CSS for new elements
>
> After that, you should be able to do ...
>
> $ git review
>
> Tim
>
> On Wed, Nov 30, 2016 at 5:23 AM Ruben 
> wrote:
>
> > Hi Tim,
> > what should I do to squash all the commits into a single one?
> >
> > To add the code to review I made:
> >
> > git add 
> > git commit
> > git review
> >
> > Isn't it correct?
> >
> > Ruben
> >
> > - Messaggio originale -
> > Da: "Tim Hinrichs" 
> > A: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Inviato: Mercoledì, 30 novembre 2016 2:34:22
> > Oggetto: Re: [Congress] Magnum_driver
> >
> > Hi Ruben,
> >
> > I left a comment on one of the changes; after you take care of that I'll
> > take a closer look at the code.  Let me know if you have questions.
> >
> > Tim
> >
> > On Tue, Nov 29, 2016 at 4:06 AM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > I've added the code of magnum_driver and its unit test to review.
> > > It seems everything works.
> > >
> > > Ruben
> > >
> > > - Original Message -
> > > From: "Tim Hinrichs" 
> > > To: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Sent: Saturday, November 26, 2016 12:48:12 AM
> > > Subject: Re: [Congress] Magnum_driver
> > >
> > > Definitely push that code up into Gerrit so we can all take a look.
> Data
> > > like pods and containers is probably the most valuable data from
> Magnum,
> > so
> > > I'd definitely recommend adding that.  But push the code you have to
> > Gerrit
> > > first.  (As long as you leave the ChangeId the same each time you push
> to
> > > Gerrit, Gerrit will keep all of the versions you pushed organized
> > together,
> > > yet keep the versions separate.)
> > >
> > > Tim
> > >
> > > On Fri, Nov 25, 2016 at 3:06 PM Ruben <
> r.manganiel...@studenti.unisa.it>
> > > wrote:
> > >
> > > > Hi Tim,
> > > > You are great. It works! Thanks a lot!
> > > > I've also solved the problem with py27. The unit test seems to work.
> > > > The only thing that seems not to work is populate the
> 'clusters_links'
> > > and
> > > > 'cluster_templates_links' tables: they are empty.
> > > > Also, the 'labels' table is empty.
> > > > I've no errors anyway.
> > > > Are these problems according to you?
> > > >
> > > > Should I to try to add the translation of pods, containers and
> > services?
> > > >
> > > > I've add the code to review.
> > > >
> > > > Ruben
> > > > - Original Message -
> > > > From: "Tim Hinrichs" 
> > > > To: "Ruben" 
> > > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > > timothy.l.hinri...@gmail.com>
> > > > Sent: Friday, November 25, 2016 10:36:29 PM
> > > > Subject: Re: [Congress] Magnum_driver
> > > >
> > > > Hi Ruben,
> > > >
> > > > Glad you got that worked out.  Once in a while I end up deleting my
> > .tox
> > > > dir because it gets out of date.  I guess that's what the --recreate
> > > option
> > > > to tox does.  So I learned something.  :)
> > > >
> > > > The new error message looks to be saying that an object of type
> > 'Cluster'
> > > > cannot be iterated.  Congress's _translate_clusters method assumes
> that
> > > > what you give it is basically JS

Re: [openstack-dev] [Congress] Magnum_driver

[Ruben]

Hi Tim,
sorry for the late, but I've had a busy week.
Anyway, I've tried to add the magnum_driver to review into a single commit.
I don't know if I have been able..

Ruben

- Messaggio originale -
Da: "Tim Hinrichs" 
A: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Inviato: Mercoledì, 30 novembre 2016 22:04:32
Oggetto: Re: [Congress] Magnum_driver

Hi Ruben,

What you're doing is correct.  The downside is that it creates a new commit
for every change you make, and all of those commits show up on gerrit.  In
OpenStack (and other projects I've seen that use Gerrit for code reviews)
you squash those commits into 1 change so that it's easier for reviewers to
see the change as a whole.  (Projects that use Github for code reviews do
more like what you're doing now).  To see your

Here's a blog showing you what to do...
https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

You can probably do

$ git rebase -i

and then follow the instructions in the blog that say you replace the
'pick' for all the commits after the first with 'squash' (or 's' for
short).  So something like the following.

pick f392171 Added new feature X squash ba9dd9a Added new elements to page
design squash df71a27 Updated CSS for new elements

After that, you should be able to do ...

$ git review

Tim

On Wed, Nov 30, 2016 at 5:23 AM Ruben 
wrote:

> Hi Tim,
> what should I do to squash all the commits into a single one?
>
> To add the code to review I made:
>
> git add 
> git commit
> git review
>
> Isn't it correct?
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Mercoledì, 30 novembre 2016 2:34:22
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> I left a comment on one of the changes; after you take care of that I'll
> take a closer look at the code.  Let me know if you have questions.
>
> Tim
>
> On Tue, Nov 29, 2016 at 4:06 AM Ruben 
> wrote:
>
> > Hi Tim,
> > I've added the code of magnum_driver and its unit test to review.
> > It seems everything works.
> >
> > Ruben
> >
> > - Original Message -
> > From: "Tim Hinrichs" 
> > To: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Sent: Saturday, November 26, 2016 12:48:12 AM
> > Subject: Re: [Congress] Magnum_driver
> >
> > Definitely push that code up into Gerrit so we can all take a look.  Data
> > like pods and containers is probably the most valuable data from Magnum,
> so
> > I'd definitely recommend adding that.  But push the code you have to
> Gerrit
> > first.  (As long as you leave the ChangeId the same each time you push to
> > Gerrit, Gerrit will keep all of the versions you pushed organized
> together,
> > yet keep the versions separate.)
> >
> > Tim
> >
> > On Fri, Nov 25, 2016 at 3:06 PM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > You are great. It works! Thanks a lot!
> > > I've also solved the problem with py27. The unit test seems to work.
> > > The only thing that seems not to work is populate the 'clusters_links'
> > and
> > > 'cluster_templates_links' tables: they are empty.
> > > Also, the 'labels' table is empty.
> > > I've no errors anyway.
> > > Are these problems according to you?
> > >
> > > Should I to try to add the translation of pods, containers and
> services?
> > >
> > > I've add the code to review.
> > >
> > > Ruben
> > > - Original Message -
> > > From: "Tim Hinrichs" 
> > > To: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Sent: Friday, November 25, 2016 10:36:29 PM
> > > Subject: Re: [Congress] Magnum_driver
> > >
> > > Hi Ruben,
> > >
> > > Glad you got that worked out.  Once in a while I end up deleting my
> .tox
> > > dir because it gets out of date.  I guess that's what the --recreate
> > option
> > > to tox does.  So I learned something.  :)
> > >
> > > The new error message looks to be saying that an object of type
> 'Cluster'
> > > cannot be iterated.  Congress's _translate_clusters method assumes that
> > > what you give it is basically JSON (arrays, dictionaries, numbers,
> > strings,
> > > bools).   In this case Congress is trying to iterate over the keys of a
> > > dictionary but is getting a 'Cluster' Python object instead.  What's
> > > happening is that when you do the cluster.list() (or whatever it's
> > called)
> > > on the magnum-python you're getting back a list of Cluster Python
> objects
> > > instead of a list of dictionaries.
> > >
> > > To fix the problem, you'll want to take the results of cluster.list()
> and
> > > translate it into a list of dictionaries, and then hand that off to
> > > _translate_clusters.  Probably you'll need to do the same for the
> > > cluster_template.  So instead of ...
> > >
> > > clusters_method = lambda: self._translate_clusters(
> > >   

Re: [openstack-dev] [Congress] Congress Dashboard and Containers

[Aimee Ukasick]

Thanks Anusha!

I agree that moving the congress_dashboard code to its own repo is a
good idea.

As a workaround, it was suggested to me that I could clone the congress
repo on the same server as horizon, copy the 3 files to the horizon
directory, and then delete the congress code that we don't need (ie,
everything but congress_dashboard). I don't really like that suggestion.
As many companies are moving towards containerized installations, I
think Anusha's suggestion is the best solution.

Please let me know how I can help.


Aimee Ukasick, AT&T


On 12/08/2016 10:41 PM, Anusha Ramineni wrote:
> Hi Tim, Aimee,
>
> Yes, ideally only congress_dashboard is required on the same server as
> horizon for horizon to discover the plugin, but right now
> congress_dashboard is also part of congress repo, so congress needs to
> be installed on the same server.
>
> I'm thinking for a while to move the repo to separate project, maybe
> its high time we move the congress_dashboard repo to separate project
> like other projects do? wdyt?
> http://docs.openstack.org/developer/horizon/plugin_registry.html
>
>
> Best Regards,
> Anusha
>
> On 9 December 2016 at 03:24, Tim Hinrichs  > wrote:
>
> I wouldn't expect Congress needs to be on the same server as
> Horizon.  Anusha, do you know for sure?
>
> Tim
>
>
> On Thu, Dec 8, 2016 at 1:20 PM Aimee Ukasick
> mailto:aimeeu.opensou...@gmail.com>>
> wrote:
>
> All - we are looking into deploying Congress in its own container,
> separate from the container that OpenStack is in. I know which
> Congress
> dashboard files need to be copied to Horizon, and from what I
> can tell,
> it looks like Congress and Horizon must be running on the same
> server
> for the Congress dashboard to work. Is this assumption correct?
>
>
> Thanks!
>
>
> Aimee Ukasick, AT&T
>
>
>
>
>
> 
> __
> 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 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] Congress Dashboard and Containers

[Anusha Ramineni]

Hi Tim, Aimee,

Yes, ideally only congress_dashboard is required on the same server as
horizon for horizon to discover the plugin, but right now
congress_dashboard is also part of congress repo, so congress needs to be
installed on the same server.

I'm thinking for a while to move the repo to separate project, maybe its
high time we move the congress_dashboard repo to separate project like
other projects do? wdyt?
http://docs.openstack.org/developer/horizon/plugin_registry.html


Best Regards,
Anusha

On 9 December 2016 at 03:24, Tim Hinrichs  wrote:

> I wouldn't expect Congress needs to be on the same server as Horizon.
> Anusha, do you know for sure?
>
> Tim
>
>
> On Thu, Dec 8, 2016 at 1:20 PM Aimee Ukasick 
> wrote:
>
>> All - we are looking into deploying Congress in its own container,
>> separate from the container that OpenStack is in. I know which Congress
>> dashboard files need to be copied to Horizon, and from what I can tell,
>> it looks like Congress and Horizon must be running on the same server
>> for the Congress dashboard to work. Is this assumption correct?
>>
>>
>> Thanks!
>>
>>
>> Aimee Ukasick, AT&T
>>
>>
>>
>>
>>
>> 
>> __
>> 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

Re: [openstack-dev] [Congress] Congress Dashboard and Containers

[Tim Hinrichs]

I wouldn't expect Congress needs to be on the same server as Horizon.
Anusha, do you know for sure?

Tim


On Thu, Dec 8, 2016 at 1:20 PM Aimee Ukasick 
wrote:

> All - we are looking into deploying Congress in its own container,
> separate from the container that OpenStack is in. I know which Congress
> dashboard files need to be copied to Horizon, and from what I can tell,
> it looks like Congress and Horizon must be running on the same server
> for the Congress dashboard to work. Is this assumption correct?
>
>
> Thanks!
>
>
> Aimee Ukasick, AT&T
>
>
>
>
>
> __
> 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] Congress Dashboard and Containers

[Aimee Ukasick]

All - we are looking into deploying Congress in its own container,
separate from the container that OpenStack is in. I know which Congress
dashboard files need to be copied to Horizon, and from what I can tell,
it looks like Congress and Horizon must be running on the same server
for the Congress dashboard to work. Is this assumption correct?


Thanks!


Aimee Ukasick, AT&T





__
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] Magnum_driver

[Tim Hinrichs]

Hi Ruben,

What you're doing is correct.  The downside is that it creates a new commit
for every change you make, and all of those commits show up on gerrit.  In
OpenStack (and other projects I've seen that use Gerrit for code reviews)
you squash those commits into 1 change so that it's easier for reviewers to
see the change as a whole.  (Projects that use Github for code reviews do
more like what you're doing now).  To see your

Here's a blog showing you what to do...
https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

You can probably do

$ git rebase -i

and then follow the instructions in the blog that say you replace the
'pick' for all the commits after the first with 'squash' (or 's' for
short).  So something like the following.

pick f392171 Added new feature X squash ba9dd9a Added new elements to page
design squash df71a27 Updated CSS for new elements

After that, you should be able to do ...

$ git review

Tim

On Wed, Nov 30, 2016 at 5:23 AM Ruben 
wrote:

> Hi Tim,
> what should I do to squash all the commits into a single one?
>
> To add the code to review I made:
>
> git add 
> git commit
> git review
>
> Isn't it correct?
>
> Ruben
>
> - Messaggio originale -
> Da: "Tim Hinrichs" 
> A: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Inviato: Mercoledì, 30 novembre 2016 2:34:22
> Oggetto: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> I left a comment on one of the changes; after you take care of that I'll
> take a closer look at the code.  Let me know if you have questions.
>
> Tim
>
> On Tue, Nov 29, 2016 at 4:06 AM Ruben 
> wrote:
>
> > Hi Tim,
> > I've added the code of magnum_driver and its unit test to review.
> > It seems everything works.
> >
> > Ruben
> >
> > - Original Message -
> > From: "Tim Hinrichs" 
> > To: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Sent: Saturday, November 26, 2016 12:48:12 AM
> > Subject: Re: [Congress] Magnum_driver
> >
> > Definitely push that code up into Gerrit so we can all take a look.  Data
> > like pods and containers is probably the most valuable data from Magnum,
> so
> > I'd definitely recommend adding that.  But push the code you have to
> Gerrit
> > first.  (As long as you leave the ChangeId the same each time you push to
> > Gerrit, Gerrit will keep all of the versions you pushed organized
> together,
> > yet keep the versions separate.)
> >
> > Tim
> >
> > On Fri, Nov 25, 2016 at 3:06 PM Ruben 
> > wrote:
> >
> > > Hi Tim,
> > > You are great. It works! Thanks a lot!
> > > I've also solved the problem with py27. The unit test seems to work.
> > > The only thing that seems not to work is populate the 'clusters_links'
> > and
> > > 'cluster_templates_links' tables: they are empty.
> > > Also, the 'labels' table is empty.
> > > I've no errors anyway.
> > > Are these problems according to you?
> > >
> > > Should I to try to add the translation of pods, containers and
> services?
> > >
> > > I've add the code to review.
> > >
> > > Ruben
> > > - Original Message -
> > > From: "Tim Hinrichs" 
> > > To: "Ruben" 
> > > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > > timothy.l.hinri...@gmail.com>
> > > Sent: Friday, November 25, 2016 10:36:29 PM
> > > Subject: Re: [Congress] Magnum_driver
> > >
> > > Hi Ruben,
> > >
> > > Glad you got that worked out.  Once in a while I end up deleting my
> .tox
> > > dir because it gets out of date.  I guess that's what the --recreate
> > option
> > > to tox does.  So I learned something.  :)
> > >
> > > The new error message looks to be saying that an object of type
> 'Cluster'
> > > cannot be iterated.  Congress's _translate_clusters method assumes that
> > > what you give it is basically JSON (arrays, dictionaries, numbers,
> > strings,
> > > bools).   In this case Congress is trying to iterate over the keys of a
> > > dictionary but is getting a 'Cluster' Python object instead.  What's
> > > happening is that when you do the cluster.list() (or whatever it's
> > called)
> > > on the magnum-python you're getting back a list of Cluster Python
> objects
> > > instead of a list of dictionaries.
> > >
> > > To fix the problem, you'll want to take the results of cluster.list()
> and
> > > translate it into a list of dictionaries, and then hand that off to
> > > _translate_clusters.  Probably you'll need to do the same for the
> > > cluster_template.  So instead of ...
> > >
> > > clusters_method = lambda: self._translate_clusters(
> > > {'clusters': self.magnum.clusters.list()})
> > >
> > > You'll want to do something like ...
> > >
> > > clusters_method = lambda: self._translate_clusters(
> > > {'clusters': [x.__dict__ for x in
> > self.magnum.clusters.list()]
> > >  })
> > >
> > > Or at least, that's what I'd start trying.  __dict__ grabs all the
> fields
> > > of an object and returns a di

Re: [openstack-dev] [Congress] Magnum_driver

[Ruben]

Hi Tim,
what should I do to squash all the commits into a single one?

To add the code to review I made:

git add 
git commit
git review

Isn't it correct?

Ruben

- Messaggio originale -
Da: "Tim Hinrichs" 
A: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Inviato: Mercoledì, 30 novembre 2016 2:34:22
Oggetto: Re: [Congress] Magnum_driver

Hi Ruben,

I left a comment on one of the changes; after you take care of that I'll
take a closer look at the code.  Let me know if you have questions.

Tim

On Tue, Nov 29, 2016 at 4:06 AM Ruben 
wrote:

> Hi Tim,
> I've added the code of magnum_driver and its unit test to review.
> It seems everything works.
>
> Ruben
>
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Saturday, November 26, 2016 12:48:12 AM
> Subject: Re: [Congress] Magnum_driver
>
> Definitely push that code up into Gerrit so we can all take a look.  Data
> like pods and containers is probably the most valuable data from Magnum, so
> I'd definitely recommend adding that.  But push the code you have to Gerrit
> first.  (As long as you leave the ChangeId the same each time you push to
> Gerrit, Gerrit will keep all of the versions you pushed organized together,
> yet keep the versions separate.)
>
> Tim
>
> On Fri, Nov 25, 2016 at 3:06 PM Ruben 
> wrote:
>
> > Hi Tim,
> > You are great. It works! Thanks a lot!
> > I've also solved the problem with py27. The unit test seems to work.
> > The only thing that seems not to work is populate the 'clusters_links'
> and
> > 'cluster_templates_links' tables: they are empty.
> > Also, the 'labels' table is empty.
> > I've no errors anyway.
> > Are these problems according to you?
> >
> > Should I to try to add the translation of pods, containers and services?
> >
> > I've add the code to review.
> >
> > Ruben
> > - Original Message -
> > From: "Tim Hinrichs" 
> > To: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Sent: Friday, November 25, 2016 10:36:29 PM
> > Subject: Re: [Congress] Magnum_driver
> >
> > Hi Ruben,
> >
> > Glad you got that worked out.  Once in a while I end up deleting my .tox
> > dir because it gets out of date.  I guess that's what the --recreate
> option
> > to tox does.  So I learned something.  :)
> >
> > The new error message looks to be saying that an object of type 'Cluster'
> > cannot be iterated.  Congress's _translate_clusters method assumes that
> > what you give it is basically JSON (arrays, dictionaries, numbers,
> strings,
> > bools).   In this case Congress is trying to iterate over the keys of a
> > dictionary but is getting a 'Cluster' Python object instead.  What's
> > happening is that when you do the cluster.list() (or whatever it's
> called)
> > on the magnum-python you're getting back a list of Cluster Python objects
> > instead of a list of dictionaries.
> >
> > To fix the problem, you'll want to take the results of cluster.list() and
> > translate it into a list of dictionaries, and then hand that off to
> > _translate_clusters.  Probably you'll need to do the same for the
> > cluster_template.  So instead of ...
> >
> > clusters_method = lambda: self._translate_clusters(
> > {'clusters': self.magnum.clusters.list()})
> >
> > You'll want to do something like ...
> >
> > clusters_method = lambda: self._translate_clusters(
> > {'clusters': [x.__dict__ for x in
> self.magnum.clusters.list()]
> >  })
> >
> > Or at least, that's what I'd start trying.  __dict__ grabs all the fields
> > of an object and returns a dictionary.  (If some of the values of that
> > dictionary are also Python objects, then you might need something that's
> > more complicated to recursively walk the result of clusters.list() and
> > translate everything into lists and dictionaries.  And I'm not sure that
> > __dict__ will give you exactly what you want, but it's worth a try.).
> >
> > Tim
> >
> >
> > On Thu, Nov 24, 2016 at 12:11 PM Ruben  >
> > wrote:
> >
> > > Hi Tim,
> > > I solved the problem with:
> > >
> > > tox --recreate -e py27
> > >
> > > Now I no have the error on the import. The unit test still has some
> > > errors, but I don't know why..
> > >
> > > Anyway, I've this error when I try to add the magnum_driver:
> > >
> > > 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> > > magnum:: polling
> > > 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver
> [-]
> > > update table clusters. from (pid=18720) update_from_datasource
> > > /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> > > 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> > > CLUSTERS: {'clusters': [ > > u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b',
> u'uuid':
> > > u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': 

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

Hi Ruben,

I left a comment on one of the changes; after you take care of that I'll
take a closer look at the code.  Let me know if you have questions.

Tim

On Tue, Nov 29, 2016 at 4:06 AM Ruben 
wrote:

> Hi Tim,
> I've added the code of magnum_driver and its unit test to review.
> It seems everything works.
>
> Ruben
>
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Saturday, November 26, 2016 12:48:12 AM
> Subject: Re: [Congress] Magnum_driver
>
> Definitely push that code up into Gerrit so we can all take a look.  Data
> like pods and containers is probably the most valuable data from Magnum, so
> I'd definitely recommend adding that.  But push the code you have to Gerrit
> first.  (As long as you leave the ChangeId the same each time you push to
> Gerrit, Gerrit will keep all of the versions you pushed organized together,
> yet keep the versions separate.)
>
> Tim
>
> On Fri, Nov 25, 2016 at 3:06 PM Ruben 
> wrote:
>
> > Hi Tim,
> > You are great. It works! Thanks a lot!
> > I've also solved the problem with py27. The unit test seems to work.
> > The only thing that seems not to work is populate the 'clusters_links'
> and
> > 'cluster_templates_links' tables: they are empty.
> > Also, the 'labels' table is empty.
> > I've no errors anyway.
> > Are these problems according to you?
> >
> > Should I to try to add the translation of pods, containers and services?
> >
> > I've add the code to review.
> >
> > Ruben
> > - Original Message -
> > From: "Tim Hinrichs" 
> > To: "Ruben" 
> > Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> > timothy.l.hinri...@gmail.com>
> > Sent: Friday, November 25, 2016 10:36:29 PM
> > Subject: Re: [Congress] Magnum_driver
> >
> > Hi Ruben,
> >
> > Glad you got that worked out.  Once in a while I end up deleting my .tox
> > dir because it gets out of date.  I guess that's what the --recreate
> option
> > to tox does.  So I learned something.  :)
> >
> > The new error message looks to be saying that an object of type 'Cluster'
> > cannot be iterated.  Congress's _translate_clusters method assumes that
> > what you give it is basically JSON (arrays, dictionaries, numbers,
> strings,
> > bools).   In this case Congress is trying to iterate over the keys of a
> > dictionary but is getting a 'Cluster' Python object instead.  What's
> > happening is that when you do the cluster.list() (or whatever it's
> called)
> > on the magnum-python you're getting back a list of Cluster Python objects
> > instead of a list of dictionaries.
> >
> > To fix the problem, you'll want to take the results of cluster.list() and
> > translate it into a list of dictionaries, and then hand that off to
> > _translate_clusters.  Probably you'll need to do the same for the
> > cluster_template.  So instead of ...
> >
> > clusters_method = lambda: self._translate_clusters(
> > {'clusters': self.magnum.clusters.list()})
> >
> > You'll want to do something like ...
> >
> > clusters_method = lambda: self._translate_clusters(
> > {'clusters': [x.__dict__ for x in
> self.magnum.clusters.list()]
> >  })
> >
> > Or at least, that's what I'd start trying.  __dict__ grabs all the fields
> > of an object and returns a dictionary.  (If some of the values of that
> > dictionary are also Python objects, then you might need something that's
> > more complicated to recursively walk the result of clusters.list() and
> > translate everything into lists and dictionaries.  And I'm not sure that
> > __dict__ will give you exactly what you want, but it's worth a try.).
> >
> > Tim
> >
> >
> > On Thu, Nov 24, 2016 at 12:11 PM Ruben  >
> > wrote:
> >
> > > Hi Tim,
> > > I solved the problem with:
> > >
> > > tox --recreate -e py27
> > >
> > > Now I no have the error on the import. The unit test still has some
> > > errors, but I don't know why..
> > >
> > > Anyway, I've this error when I try to add the magnum_driver:
> > >
> > > 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> > > magnum:: polling
> > > 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver
> [-]
> > > update table clusters. from (pid=18720) update_from_datasource
> > > /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> > > 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> > > CLUSTERS: {'clusters': [ > > u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b',
> u'uuid':
> > > u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> > > http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc
> ',
> > > u'rel': u'self'}, {u'href': u'
> > > http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > > u'rel': u'bookmark'}], u'stack_id':
> > > u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1,
> u'keypair':
> > > u'testkey', u'node_count': 1, u'crea

Re: [openstack-dev] [Congress] Magnum_driver

[Ruben]

Hi Tim,
I've added the code of magnum_driver and its unit test to review.
It seems everything works.

Ruben

- Original Message -
From: "Tim Hinrichs" 
To: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Sent: Saturday, November 26, 2016 12:48:12 AM
Subject: Re: [Congress] Magnum_driver

Definitely push that code up into Gerrit so we can all take a look.  Data
like pods and containers is probably the most valuable data from Magnum, so
I'd definitely recommend adding that.  But push the code you have to Gerrit
first.  (As long as you leave the ChangeId the same each time you push to
Gerrit, Gerrit will keep all of the versions you pushed organized together,
yet keep the versions separate.)

Tim

On Fri, Nov 25, 2016 at 3:06 PM Ruben 
wrote:

> Hi Tim,
> You are great. It works! Thanks a lot!
> I've also solved the problem with py27. The unit test seems to work.
> The only thing that seems not to work is populate the 'clusters_links' and
> 'cluster_templates_links' tables: they are empty.
> Also, the 'labels' table is empty.
> I've no errors anyway.
> Are these problems according to you?
>
> Should I to try to add the translation of pods, containers and services?
>
> I've add the code to review.
>
> Ruben
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Friday, November 25, 2016 10:36:29 PM
> Subject: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> Glad you got that worked out.  Once in a while I end up deleting my .tox
> dir because it gets out of date.  I guess that's what the --recreate option
> to tox does.  So I learned something.  :)
>
> The new error message looks to be saying that an object of type 'Cluster'
> cannot be iterated.  Congress's _translate_clusters method assumes that
> what you give it is basically JSON (arrays, dictionaries, numbers, strings,
> bools).   In this case Congress is trying to iterate over the keys of a
> dictionary but is getting a 'Cluster' Python object instead.  What's
> happening is that when you do the cluster.list() (or whatever it's called)
> on the magnum-python you're getting back a list of Cluster Python objects
> instead of a list of dictionaries.
>
> To fix the problem, you'll want to take the results of cluster.list() and
> translate it into a list of dictionaries, and then hand that off to
> _translate_clusters.  Probably you'll need to do the same for the
> cluster_template.  So instead of ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': self.magnum.clusters.list()})
>
> You'll want to do something like ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': [x.__dict__ for x in self.magnum.clusters.list()]
>  })
>
> Or at least, that's what I'd start trying.  __dict__ grabs all the fields
> of an object and returns a dictionary.  (If some of the values of that
> dictionary are also Python objects, then you might need something that's
> more complicated to recursively walk the result of clusters.list() and
> translate everything into lists and dictionaries.  And I'm not sure that
> __dict__ will give you exactly what you want, but it's worth a try.).
>
> Tim
>
>
> On Thu, Nov 24, 2016 at 12:11 PM Ruben 
> wrote:
>
> > Hi Tim,
> > I solved the problem with:
> >
> > tox --recreate -e py27
> >
> > Now I no have the error on the import. The unit test still has some
> > errors, but I don't know why..
> >
> > Anyway, I've this error when I try to add the magnum_driver:
> >
> > 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> > magnum:: polling
> > 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-]
> > update table clusters. from (pid=18720) update_from_datasource
> > /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> > 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> > CLUSTERS: {'clusters': [ > u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b', u'uuid':
> > u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> > http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'self'}, {u'href': u'
> > http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'bookmark'}], u'stack_id':
> > u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1, u'keypair':
> > u'testkey', u'node_count': 1, u'create_timeout': 60, u'name':
> > u'k8s-cluster'}>]} from (pid=18720) _translate_clusters
> > /opt/stack/congress/congress/datasources/magnum_driver.py:165
> > 2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-]
> > Datasource driver raised exception
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> > Traceback (most recent call last):
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  File "/opt/stack/congr

Re: [openstack-dev] [Congress] Magnum_driver

[Tim Hinrichs]

Definitely push that code up into Gerrit so we can all take a look.  Data
like pods and containers is probably the most valuable data from Magnum, so
I'd definitely recommend adding that.  But push the code you have to Gerrit
first.  (As long as you leave the ChangeId the same each time you push to
Gerrit, Gerrit will keep all of the versions you pushed organized together,
yet keep the versions separate.)

Tim

On Fri, Nov 25, 2016 at 3:06 PM Ruben 
wrote:

> Hi Tim,
> You are great. It works! Thanks a lot!
> I've also solved the problem with py27. The unit test seems to work.
> The only thing that seems not to work is populate the 'clusters_links' and
> 'cluster_templates_links' tables: they are empty.
> Also, the 'labels' table is empty.
> I've no errors anyway.
> Are these problems according to you?
>
> Should I to try to add the translation of pods, containers and services?
>
> I've add the code to review.
>
> Ruben
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Friday, November 25, 2016 10:36:29 PM
> Subject: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> Glad you got that worked out.  Once in a while I end up deleting my .tox
> dir because it gets out of date.  I guess that's what the --recreate option
> to tox does.  So I learned something.  :)
>
> The new error message looks to be saying that an object of type 'Cluster'
> cannot be iterated.  Congress's _translate_clusters method assumes that
> what you give it is basically JSON (arrays, dictionaries, numbers, strings,
> bools).   In this case Congress is trying to iterate over the keys of a
> dictionary but is getting a 'Cluster' Python object instead.  What's
> happening is that when you do the cluster.list() (or whatever it's called)
> on the magnum-python you're getting back a list of Cluster Python objects
> instead of a list of dictionaries.
>
> To fix the problem, you'll want to take the results of cluster.list() and
> translate it into a list of dictionaries, and then hand that off to
> _translate_clusters.  Probably you'll need to do the same for the
> cluster_template.  So instead of ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': self.magnum.clusters.list()})
>
> You'll want to do something like ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': [x.__dict__ for x in self.magnum.clusters.list()]
>  })
>
> Or at least, that's what I'd start trying.  __dict__ grabs all the fields
> of an object and returns a dictionary.  (If some of the values of that
> dictionary are also Python objects, then you might need something that's
> more complicated to recursively walk the result of clusters.list() and
> translate everything into lists and dictionaries.  And I'm not sure that
> __dict__ will give you exactly what you want, but it's worth a try.).
>
> Tim
>
>
> On Thu, Nov 24, 2016 at 12:11 PM Ruben 
> wrote:
>
> > Hi Tim,
> > I solved the problem with:
> >
> > tox --recreate -e py27
> >
> > Now I no have the error on the import. The unit test still has some
> > errors, but I don't know why..
> >
> > Anyway, I've this error when I try to add the magnum_driver:
> >
> > 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> > magnum:: polling
> > 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-]
> > update table clusters. from (pid=18720) update_from_datasource
> > /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> > 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> > CLUSTERS: {'clusters': [ > u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b', u'uuid':
> > u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> > http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'self'}, {u'href': u'
> > http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'bookmark'}], u'stack_id':
> > u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1, u'keypair':
> > u'testkey', u'node_count': 1, u'create_timeout': 60, u'name':
> > u'k8s-cluster'}>]} from (pid=18720) _translate_clusters
> > /opt/stack/congress/congress/datasources/magnum_driver.py:165
> > 2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-]
> > Datasource driver raised exception
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> > Traceback (most recent call last):
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  File "/opt/stack/congress/congress/datasources/datasource_driver.py",
> line
> > 1384, in poll
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  self.update_from_datasource()  # sets self.state
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  File "/opt/stack/congress/congress/datasou