[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

Re: [openstack-dev] [masakari][congress] what is a host?

[Eric K]

Got it thanks very much, Sampath!

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

Date:  Saturday, October 6, 2018 at 8:29 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [masakari][congress] what is a host?

> Hi Eric,
>  
> (1) "virtual machine" is bug. This need to be corrected as physical machine or
> hypervisor.
>   Masakari host is a physical host/hypervisor. I will correct this.
> 
> (2) Not through masakari APIs. You have to add metadata key 'HA_Enabled=True'
> to each VM by using nova API.
>  Masakeri monitors check for failures and send notification to masakari
> API if detected any failure (i.e host, VM or process failures).
>  In host failure (hypervisor down) scenario, Masakari engine get the VM
> list on that hypervisor and start evacuate VMs.
>  Operator can configure masakari to evacuate all VMs or only the VMs with
> the metadata key   'HA_Enabled=True.
>  Please see the config file [1] section [host_failure] for more details.
> 
> Let me know if you need more info on this.
> 
> [1] https://docs.openstack.org/masakari/latest/sample_config.html
> 
> --- Regards,
> Sampath
> 
> 
> 
> On Sun, Oct 7, 2018 at 8:55 AM Eric K  wrote:
>> Hi all, I'm working on a potential integration between masakari and
>> congress. But I am stuck on some basic usage questions I could not
>> answer in my search of docs and demos. Any clarification or references
>> would be much appreciated!
>> 
>> 1. What does a host refer to in masakari API? Here's the explanation in API
>> doc:
>> "Host can be any kind of virtual machine which can have compute
>> service running on it."
>> (https://developer.openstack.org/api-ref/instance-ha/#hosts-hosts)
>> 
>> So is a masakari host usually a nova instance/server instead of a
>> host/hypervisor?
>> 
>> 2. Through the masakari api, how does one go about configuring a VM to
>> be managed by masakari instance HA?
>> 
>> Thanks so much!
>> 
>> Eric Kao
>> 
>> __
>> 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

[openstack-dev] [masakari][congress] what is a host?

[Eric K]

Hi all, I'm working on a potential integration between masakari and
congress. But I am stuck on some basic usage questions I could not
answer in my search of docs and demos. Any clarification or references
would be much appreciated!

1. What does a host refer to in masakari API? Here's the explanation in API doc:
"Host can be any kind of virtual machine which can have compute
service running on it."
(https://developer.openstack.org/api-ref/instance-ha/#hosts-hosts)

So is a masakari host usually a nova instance/server instead of a
host/hypervisor?

2. Through the masakari api, how does one go about configuring a VM to
be managed by masakari instance HA?

Thanks so much!

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

Re: [openstack-dev] [tempest][qa][congress] trouble setting tempest feature flag

[Eric K]

Ha. Turned out to be a simple mistake in hyphens vs underscores.
On Tue, Aug 28, 2018 at 3:06 PM Eric K  wrote:
>
> Any thoughts on what could be going wrong that the tempest tests still
> see the default conf values rather than those set here? Thanks lots!
>
> Here is the devstack log line showing the flags being set:
> http://logs.openstack.org/64/594564/4/check/congress-devstack-api-mysql/ce34264/logs/devstacklog.txt.gz#_2018-08-28_21_23_15_934
>
> On Wed, Aug 22, 2018 at 9:12 AM Eric K  wrote:
> >
> > Hi all,
> >
> > I have added feature flags for the congress tempest plugin [1] and set
> > them in the devstack plugin [2], but the flags seem to be ignored. The
> > tests are skipped [3] according to the default False flag rather than
> > run according to the True flag set in devstack plugin. Any hints on
> > what may be wrong? Thanks so much!
> >
> > [1] https://review.openstack.org/#/c/594747/3
> > [2] https://review.openstack.org/#/c/594793/1/devstack/plugin.sh
> > [3] 
> > http://logs.openstack.org/64/594564/3/check/congress-devstack-api-mysql/b2cd46f/logs/testr_results.html.gz
> > (the bottom two skipped tests were expected to run)

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

Re: [openstack-dev] [tempest][qa][congress] trouble setting tempest feature flag

[Eric K]

Any thoughts on what could be going wrong that the tempest tests still
see the default conf values rather than those set here? Thanks lots!

Here is the devstack log line showing the flags being set:
http://logs.openstack.org/64/594564/4/check/congress-devstack-api-mysql/ce34264/logs/devstacklog.txt.gz#_2018-08-28_21_23_15_934

On Wed, Aug 22, 2018 at 9:12 AM Eric K  wrote:
>
> Hi all,
>
> I have added feature flags for the congress tempest plugin [1] and set
> them in the devstack plugin [2], but the flags seem to be ignored. The
> tests are skipped [3] according to the default False flag rather than
> run according to the True flag set in devstack plugin. Any hints on
> what may be wrong? Thanks so much!
>
> [1] https://review.openstack.org/#/c/594747/3
> [2] https://review.openstack.org/#/c/594793/1/devstack/plugin.sh
> [3] 
> http://logs.openstack.org/64/594564/3/check/congress-devstack-api-mysql/b2cd46f/logs/testr_results.html.gz
> (the bottom two skipped tests were expected to run)

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

[openstack-dev] [tempest][qa][congress] trouble setting tempest feature flag

[Eric K]

Hi all,

I have added feature flags for the congress tempest plugin [1] and set
them in the devstack plugin [2], but the flags seem to be ignored. The
tests are skipped [3] according to the default False flag rather than
run according to the True flag set in devstack plugin. Any hints on
what may be wrong? Thanks so much!

[1] https://review.openstack.org/#/c/594747/3
[2] https://review.openstack.org/#/c/594793/1/devstack/plugin.sh
[3] 
http://logs.openstack.org/64/594564/3/check/congress-devstack-api-mysql/b2cd46f/logs/testr_results.html.gz
(the bottom two skipped tests were expected to run)

__
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

Re: [Openstack] [OpenStack][Keystone][new_service]

[Eric K]

On Fri, Aug 17, 2018 at 9:34 AM, B.M.Canning  wrote:
> Hi Eric,
>
> Thanks for getting back to me.
>
> I'm not looking to develop a real, useful, new service for OpenStack but
> develop a dummy service that plugs into OpenStack's authorisation
> infrastructure in a way that it looks like an OpenStack service which
> integrates with Keystone, like, say the Swift service. See picture
> attached, where the swift object represents a resource in the dummy
> service.
>
> The dummy service itself is a web-based game of snakes and ladders
> written in JavaScript/jQuery which makes Ajax calls to its PEP, written
> in PHP. The PHP code interacts with Keystone via the PHP cURL library
> and also logs all game actions in a MariaDB database.
>
> The game has been written in a way that it can be exploited by malicious
> users who already have access to the system, e.g players can travel up
> the snakes or simply ignore the snakes. The idea is that an autonomic
> controller is recording the user's actions, analysing them, planning a
> response (if necessary) and executing a change. This change could be
> inserting a policy line into policy.json or via the congress API. It
> could also be removing a role from a user which denies them further
> access to the resource in Keystone.
>
> The aim of this research is to produce an effective and efficient means
> of mitigating against insider threats directed at computing resources
> and information systems. This idea has been previously examined with
> LDAP serving as an authentication service and PERMIS serving as an
> authorisation service [1]. What is of interest here is porting the setup
> to an authorisation infrastructure that is relevant to cloud computing.
>
> I've had a look at congress, I have it running on my game server and it
> is registered as a service in Keystone after following [2] (except I
> installed the software from CentOS 7 "cloud" repo, "openstack-queens"
> [3] but at the moment, calls to the API are returning "Service
> Unavailable (HTTP 503)". This may be because there are no datasources
> configured.
Ah I think the issue is that there is no rabbitmq server running. We
should probably make that clear in docs.
https://www.rabbitmq.com/install-rpm.html
> I started to write a driver for the dummy service [4] but as
> the game itself does not have a RESTful API, I'm not sure what approach
> to take here. I note that this distinction may favour a driver which is
> a subclass of PushedDataSourceDriver, rather than
> PollingDataSourceDriver.
I think there is no need to make a driver. Rather, your service can
simply make API calls to Congress the same way it calls Keystone.
> Failing that, I might pursue the Oslo policy
> library route, but again, I'm having difficulty in finding where to
> start. How might you suggest going about making a new, dummy service,
> such as that which I have described?
oslo policy is the stardard used by most openstack services. So if
your goal is to demonstrate doing something using the standard
framework, then that's the way to go. Though since it's a python
library you'd need some kind of bridge between your PHP web service
and oslo policy.

unfortunately it's not the most obvious how to get started. Here's a
simple example (from congress code):
step 1: define enforcement function using oslo policy library
https://github.com/openstack/congress/blob/master/congress/common/policy.py#L74
step 2: call the enforcement function to check for valid authorization
before taking action
https://github.com/openstack/congress/blob/master/congress/api/webservice.py#L417

More api reference here:
https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#oslo_policy.policy.Enforcer.enforce

On the other hand, if you don't want to involve python, you can use
directly make API calls to Congress service using PHP.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tempest][qa][congress] help with tempest plugin jobs against stable/queens

[Eric K]

On Tue, Aug 14, 2018 at 9:34 PM, Ghanshyam Mann  wrote:
>   On Wed, 15 Aug 2018 09:37:18 +0900 Eric K  
> wrote 
>  > I'm adding jobs [1] to the tempest plugin to run tests against
>  > congress stable/queens. The job output seems to show stable/queens
>  > getting checked out [2], but I know the test is *not* run against
>  > queens because it's using features not available in queens. The
>  > expected result is for several tests to fail as seen here [3]. All
>  > hints and tips much appreciated!
>
> You are doing it in right way by 'override-checkout: stable/queens'. And as 
> log also show, congress is checkout from stable/queens. I tried to check the 
> results but could not get what tests should fail and why.
>
> If you can give me more idea, i can debug that.
>
> -gmann
Thanks so much gmann!
For example, looking at
'congress_tempest_plugin.tests.scenario.congress_datasources.test_vitrage.TestVitrageDriver'
here:
http://logs.openstack.org/61/591861/1/check/congress-devstack-api-mysql/36bacbe/logs/testr_results.html.gz

It shows passing 1 of 1, but that feature is not in the queens branch
at all. The expected result can be seen here:
http://logs.openstack.org/05/591805/2/check/congress-devstack-api-mysql/7d7b28e/logs/testr_results.html.gz
>
>  >
>  > [1] https://review.openstack.org/#/c/591861/1
>  > [2] 
> http://logs.openstack.org/61/591861/1/check/congress-devstack-api-mysql-queens/f7b5752/job-output.txt.gz#_2018-08-14_22_30_36_899501
>  > [3] https://review.openstack.org/#/c/591805/ (the depends-on is
>  > irrelevant because that patch has been merged)
>  >

__
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] [OpenStack][Keystone][new_service]

[Eric K]

Hi Bruno!

What is the new service you're looking to develop?

I think the answer depends on your needs. Most openstack projects use
the oslo policy library as a PDP to protect API access [1]. On the
other hand, if you want dynamic rules and very fine-grained access
control, you may also consider Openstack Congress [2] which offers a
general and flexible rule framework.

Either way, here is how it typically works in an openstack service:
Policy rules are written and stored in the chosen policy framework.
For oslo policy, this is typically the json file containing policy
rules. In Congress, the policy store is managed by Congress service
and accessed via Congress API.
When an API is accessed, the service serving the API acts as the PEP.
It consults the PDP to see whether something is allowed, and enforces
that decision. For oslo policy, this is a library call [3]. For
Congress, this is an API call to Congress service to query the result
of rule evaluation [4][5].

For oslo policy, the main PAP is the json file containing the policy
rules. For congress, the policies and rules are managed through the
Congress API/GUI/client.

Hope that helps. Happy to talk further!

Eric
OpenStack Congress contributor

[1] 
https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#
[2] https://docs.openstack.org/congress/latest/user/policy.html#
[3] 
https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#generic-checks
[4] 
https://docs.openstack.org/congress/latest/user/api.html#policy-table-rows-v1-policies-policy-id-tables-table-id
[5] 
https://github.com/openstack/python-congressclient/blob/master/congressclient/v1/client.py#L113

On Wed, Aug 15, 2018 at 8:29 AM, B.M.Canning  wrote:
> Dear OpenStackers,
>
> Hello, I'm new to the list.
>
> I would like to know what support is available for creating a new
> OpenStack service that contains role-based access control components,
> such as a Policy Decision Point (PDP), inside the new service.
>
> I have come across oslo.policy in my research, is this what other OpenStack
> components use for their PEP, PDP, PAP and PIP? If so, what resources are
> available to help developers use this framework in their projects?
>
> Background:
> As part of my MSc degree in computer science, I am conducting a research
> project into the application of self-adaptation in authorisation
> infrastructures as a means of mitigation against insider threats towards
> cloud computing infrastructures. I'm using Keystone as a role-based
> access control system to protect access to a web-based game, and actions
> that a player can perform in the game, which represents computing
> resources, here snakes and ladders. Cheating in the game represents the
> malicious behaviour of an insider threat, to which the authorisation
> infrastructure responds by reducing/removing the user's privileges. The
> intention is to have the game represent an OpenStack service, like
> Swift. I am currently using the Queens release of Keystone and v3 of the
> API for both service-level and infrastructure-level policy decisions.
>
> Best wishes,
> Bruno Canning
>
> School of Computing, University of Kent
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tempest][qa][congress] tempest test conditioning on release version

[Eric K]

On Tue, Aug 14, 2018 at 8:59 PM, Ghanshyam Mann  wrote:
>   On Wed, 15 Aug 2018 06:40:57 +0900 Eric K  
> wrote 
>  > Anyone have an example handy of a tempest test conditioning on service
>  > release version (because new features not available in past versions)?
>  > Seems like it could get pretty messy and haphazard, so I'm curious to
>  > see best practices. Thanks lots!
>
> Thanks Eric for query. We do it in many times in Tempest and similar approach 
> can be adopt by tempest plugins. There are 2 ways we can handle  this-
>
> 1. Using feature flag. Tempest documentation is here [1].
>  Step1- This is simply adding a config options(feature flag) for new/old 
> feature.
>  Example- https://review.openstack.org/#/c/545627/   
> https://github.com/openstack/tempest/blob/6a8d495192632fd18dce4baf1a4b213f401a0167/tempest/config.py#L242
>  Step2- Based on that flag you can skip the tests where that feature is not 
> available.
>  Example-  
> https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/identity/base.py#L315
>  Step3- For gate, devstack plugin on project side (congress is your case [2]) 
> which is branch aware can set that flag to true and false based on which 
> branch that test is running. For tempest we do the same from 
> devstack/lib/tempest
>  Example - https://review.openstack.org/#/c/545680/
> https://github.com/openstack-dev/devstack/blob/8c1052001629d62f001d04c182500fa293858f47/lib/tempest#L308
>  Step4- For cloud testing(non-gate), tester can manually configure the those 
> flag based on what service version they are testing.
>
> 2. Detecting service version via version API
> - If you can get the service version info from API then you can use that 
> while skipping the tests.
> - One example if for compute where based on microversion, it can be detected 
> that test running against which release.
> - Example- 
> https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/compute/base.py#L114
>
>
> [1] 
> https://docs.openstack.org/tempest/latest/HACKING.html#branchless-tempest-considerations
> [2] 
> https://github.com/openstack/congress/blob/014361c809517661264d0364eaf1e261e449ea80/devstack/plugin.sh#L88
>
>  >
>  > Eric Kao

Thank you so much, Ghanshyam!

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

[openstack-dev] [tempest][qa][congress] help with tempest plugin jobs against stable/queens

[Eric K]

I'm adding jobs [1] to the tempest plugin to run tests against
congress stable/queens. The job output seems to show stable/queens
getting checked out [2], but I know the test is *not* run against
queens because it's using features not available in queens. The
expected result is for several tests to fail as seen here [3]. All
hints and tips much appreciated!

[1] https://review.openstack.org/#/c/591861/1
[2] 
http://logs.openstack.org/61/591861/1/check/congress-devstack-api-mysql-queens/f7b5752/job-output.txt.gz#_2018-08-14_22_30_36_899501
[3] https://review.openstack.org/#/c/591805/ (the depends-on is
irrelevant because that patch has been merged)

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

[openstack-dev] [tempest][qa][congress] tempest test conditioning on release version

[Eric K]

Anyone have an example handy of a tempest test conditioning on service
release version (because new features not available in past versions)?
Seems like it could get pretty messy and haphazard, so I'm curious to
see best practices. Thanks lots!

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] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

From:  Rabi Mishra 
Date:  Monday, August 13, 2018 at 10:10 PM
> On Tue, Aug 14, 2018 at 4:40 AM, Eric K  wrote:
>> It appears that gabbi<1.42.1 is causing on error with heat tempest
>> plugin in congress stable/queens dsvm job [1][2][3].
> I wonder why you're enabling heat-tempest-plugin in the first place? I see a
> number of tempest plugins enabled. However, you don't seem to gate on the
> tests in those plugins[1].
> 
> [1] 
> https://github.com/openstack/congress/blob/master/playbooks/legacy/congress-de
> vstack-api-base/run.yaml#L61
Hi Rabi,

When folks worked on transitioning from in-tree tempest tests to a separate
plugin, it seemed as though enabling these plugins
was necessary to get some of the skip checks like this to succeed:
https://github.com/openstack/congress-tempest-plugin/blob/master/congress_te
mpest_plugin/tests/scenario/congress_datasources/test_aodh.py#L32

But maybe that's not the case and there's a better way. Would be great to
shed these extra tempest plugins actually.
> 
>  
>> The issue was
>> addressed in heat tempest plugin [4], but the problem remains for
>> stable/queens jobs because the queens upper-constraint is still at
>> 1.40.0 [5].
>> 
> 
> Yeah, a uc bump to 1.42.1 is required if you're enabling it.
>  
>> Any suggestions on how to proceed? Thank you!
>> 
>> [1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
>> [3] 
>> http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d
>> 8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
>> [4] https://review.openstack.org/#/c/544025/
>> [5] 
>> https://github.com/openstack/requirements/blob/stable/queens/upper-constraint
>> s.txt#L245
>> 
>> __
>> 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
> 
> 
> 
> -- 
> Regards,
> Rabi Mishra
> 
> __
> 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] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

On 8/13/18, 11:03 PM, "Tony Breeds"  wrote:

>On Mon, Aug 13, 2018 at 04:10:30PM -0700, Eric K wrote:
>> It appears that gabbi<1.42.1 is causing on error with heat tempest
>> plugin in congress stable/queens dsvm job [1][2][3]. The issue was
>> addressed in heat tempest plugin [4], but the problem remains for
>> stable/queens jobs because the queens upper-constraint is still at
>> 1.40.0 [5].
>> 
>> Any suggestions on how to proceed? Thank you!
>
>https://review.openstack.org/591561 Should fix it.  You can create a
>no-op test that:
>
>Depends-On: https://review.openstack.org/591561
>
>to verify it works.  Doing so and reporting the change ID would be
>really helpful.
>
>Yours Tony.
Thank you, Tony!

Here's a no-op test:
https://review.openstack.org/#/c/591805/
>__
>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] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

It appears that gabbi<1.42.1 is causing on error with heat tempest
plugin in congress stable/queens dsvm job [1][2][3]. The issue was
addressed in heat tempest plugin [4], but the problem remains for
stable/queens jobs because the queens upper-constraint is still at
1.40.0 [5].

Any suggestions on how to proceed? Thank you!

[1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
[3] 
http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
[4] https://review.openstack.org/#/c/544025/
[5] 
https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L245

__
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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Eric K]

Requesting the raised minimun just for openstack/congress.
https://review.openstack.org/#/c/590021/

No re-release required; it'll just take effect in RC1.



On 8/8/18, 2:06 PM, "Matthew Thode"  wrote:

>On 18-08-08 13:14:08, Eric K wrote:
>> python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
>> experience a problem around Session.
>> 
>> python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
>> congress requirements to python-monascaclient>=1.12.1 if it is not
>> disruptive to packaging [2]. If it is disruptive, we can just note it
>> as a known issue.
>
>Which project(s) will need the new minimum?  Those projects would need
>re-releases.  Then my question then becomes if those projects need a
>raised minumum too, and for which project(s).  And so on.
>
>-- 
>Matthew Thode (prometheanfire)
>__
>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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Eric K]

Requesting the raised minimun just for openstack/congress.
https://review.openstack.org/#/c/589995/

No re-release required; it'll just take effect in RC1.

On 8/8/18, 2:07 PM, "Matthew Thode"  wrote:

>On 18-08-08 13:20:47, Eric K wrote:
>> Lower versions of sphinx seems to experience a problem where the
>> exclude_patterns option is not in effect. I'd like to bump the
>> docs/requirements to sphinx>=1.7.3 if it is not disruptive to
>> packaging. If it is disruptive to packaging we can leave it as is.
>> 
>> Thanks!
>> 
>> https://review.openstack.org/#/c/589995/
>> 
>
>Which project(s) will need the new minimum?  Those projects would need
>re-releases.  Then my question then becomes if those projects need a
>raised minumum too, and for which project(s).  And so on.
>
>-- 
>Matthew Thode (prometheanfire)
>__
>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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Eric K]

Lower versions of sphinx seems to experience a problem where the
exclude_patterns option is not in effect. I'd like to bump the
docs/requirements to sphinx>=1.7.3 if it is not disruptive to
packaging. If it is disruptive to packaging we can leave it as is.

Thanks!

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

__
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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Eric K]

python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
experience a problem around Session.

python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
congress requirements to python-monascaclient>=1.12.1 if it is not
disruptive to packaging [2]. If it is disruptive, we can just note it
as a known issue.

Thanks!

[1] https://review.openstack.org/#/c/579139/
[2] https://review.openstack.org/#/c/590021/

__
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

Re: [openstack-dev] [vitrage] matching webhook vs alarm list

[Eric K]

Thank you for the explanation!

Eric

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

Date:  Monday, June 11, 2018 at 1:34 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] matching webhook vs alarm list

> Hi Eric,
>  
> The format of the vitrage_id was changed to UUID in Pike release. It appears
> that the API documentation [1] is outdated. I¹ll fix it.
> The vitrage_id that you get in the webhook notification should match the one
> coming from Œvitrage alarm list¹. The Œid¹ field is determined by the external
> monitor, so it might be different.
>  
> Best Regards,
> Ifat
>  
> 
> -- Forwarded message -
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 01:40
> Subject: [openstack-dev] [vitrage] matching webhook vs alarm list
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on what ID to use for matching a webhook notification to
> the specific alarm from the alarm list. In the sample alarm list
> response, there is an 'id' field and a 'vitrage_id' field [1], where
> as in the sample webhook notification payload, there is a 'vitrage_id'
> field [2]. I'd assume we can match by the 'vitrage_id', but the
> samples have very different formats for 'vitrage_id', so I just want
> to confirm. Thank you!
> 
> [1] 
> https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
> [2]
> {
>   "notification": "vitrage.alarm.activate",
>   "payload": {
> "vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
> "resource": {
>   "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
>   "name": "app-1-server-1-jz6qvznkmnif",
>   "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
>   "vitrage_category": "RESOURCE",
>   "vitrage_operational_state": "OK",
>   "vitrage_type": "nova.instance",
>   "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
>   "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
> },
> "update_timestamp": "2018-01-22T10:00:34Z",
> "vitrage_category": "ALARM",
> "state": "Active",
> "vitrage_type": "vitrage",
> "vitrage_operational_severity": "WARNING",
> "name": "Instance memory performance degraded"
>   }
> }
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.
> html
> 
> __
> 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] [vitrage] update_timestamp precision

[Eric K]

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

Date:  Monday, June 11, 2018 at 2:12 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [vitrage] update_timestamp precision

> Hi Eric,
>  
> Apparently we have inconsistent behavior between the different datasources.
> The format of the timestamp should be '%Y-%m-%dT%H:%M:%SZ' as defined in [1].
> We need to go over the code and make sure all datasources are aligned. I
> created a bug for it [2].
>  
> [1] 
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/transform
> er_base.py
> 
> [2] https://bugs.launchpad.net/vitrage/+bug/1776181
> Best regards,
> Ifat
>  
> 
> -- Forwarded message -
> From: Eric K 
> Date: Sat, 9 Jun 2018 at 00:20
> Subject: [openstack-dev] [vitrage] update_timestamp precision
> To: OpenStack Development Mailing List (not for usage questions)
> 
> 
> 
> Hi I'm building integration with Vitrage webhook and looking for some
> clarification on the timestamp precision to expect.
> 
> In the sample webhook payload found in doc the resource and the alarm
> shows different time stamp precisions:
> https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
> in.html 
> <https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin
> .html> 
> 
> 
> Thank you!
> 
> 
> 
> __
> 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

[openstack-dev] [vitrage] matching webhook vs alarm list

[Eric K]

Hi I'm building integration with Vitrage webhook and looking for some
clarification on what ID to use for matching a webhook notification to
the specific alarm from the alarm list. In the sample alarm list
response, there is an 'id' field and a 'vitrage_id' field [1], where
as in the sample webhook notification payload, there is a 'vitrage_id'
field [2]. I'd assume we can match by the 'vitrage_id', but the
samples have very different formats for 'vitrage_id', so I just want
to confirm. Thank you!

[1] https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html#id22
[2]
{
  "notification": "vitrage.alarm.activate",
  "payload": {
"vitrage_id": "2def31e9-6d9f-4c16-b007-893caa806cd4",
"resource": {
  "vitrage_id": "437f1f4c-ccce-40a4-ac62-1c2f1fd9f6ac",
  "name": "app-1-server-1-jz6qvznkmnif",
  "update_timestamp": "2018-01-22 10:00:34.327142+00:00",
  "vitrage_category": "RESOURCE",
  "vitrage_operational_state": "OK",
  "vitrage_type": "nova.instance",
  "project_id": "8f007e5ba0944e84baa6f2a4f2b5d03a",
  "id": "9b7d93b9-94ec-41e1-9cec-f28d4f8d702c"
},
"update_timestamp": "2018-01-22T10:00:34Z",
"vitrage_category": "ALARM",
"state": "Active",
"vitrage_type": "vitrage",
"vitrage_operational_severity": "WARNING",
"name": "Instance memory performance degraded"
  }
}
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plugin.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] [vitrage] update_timestamp precision

[Eric K]

Hi I'm building integration with Vitrage webhook and looking for some
clarification on the timestamp precision to expect.

In the sample webhook payload found in doc the resource and the alarm
shows different time stamp precisions:
https://docs.openstack.org/vitrage/latest/contributor/notifier-webhook-plug
in.html


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-operators] [self-healing] BoF in Vancouver tomorrow

[Eric K]

For everyone interested in self-healing infra, come share your
experience and your ideas with like-minded stackers, including folks
from 10+ projects working together to make OpenStack self-healing a
reality!

Thursday, May 24, 1:50pm-2:30pm
Vancouver Convention Centre West - Level Two - Room 217

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21830/self-healing-sig-bof

Brainstorming etherpad:
https://etherpad.openstack.org/p/YVR-self-healing-brainstorming

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

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

Thank you, Zane for the discussion.

Point taken about sending webhook notifications.

Primarily I want Congress to consume webhook notifications from the
openstack services which already send them (monasca, vitrage, etc.). Most
of them do not currently support sending appropriate keystone tokens with
the notifications, but some are open to doing it.

The aodh and zaqar references are exactly what I was hoping to find. I
couldn't find a reference to it in aodh docs or much on google, so many
thanks for the pointer!

Eric



On 5/8/18, 1:20 PM, "Zane Bitter"  wrote:
>If the caller is something that is basically trusted, then you should
>prefer regular keystone auth. If you need to make sure that the caller
>can only use that one API, signed URLs are still the only game in town
>for now (but we hope this is very temporary).
>
>> I know some people are working on adding the keystone auth option to
>> Monasca's webhook framework. If there is a project that already does it,
>> it could be a very helpful reference.
>
>There's a sort of convention that where you supply a webhook URL with a
>scheme trust+https:// then the service creates a keystone trust and uses
>that to get keystone tokens which are then used to authenticate the
>webhook request. Aodh and Zaqar at least follow this convention. The
>trust part is an important point that you're overlooking: (from your
>other message)



__
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] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

To clarify, one of the reasons I'd like to accept webhook notifications
authenticated with keystone tokens is that I don't want the access to
expire, but of course it's poor practice to use a signed URL that never
expires.

Eric

On 5/8/18, 12:29 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:

>Thanks, Thomas!
>
>I see the point that it is impractical to configure a service with a fixed
>keystone token to use in webhook notifications because they expire fairly
>quickly.
>
>I'm thinking about the situation where the sending service can obtain
>tokens directly from keystone. In that case I'm guessing the main reason
>it hasn't been done that way is because it does not generalize to most
>other services that don't connect to keystone?
>
>On 5/6/18, 9:30 AM, "Thomas Herve" <the...@redhat.com> wrote:
>
>>On Sat, May 5, 2018 at 1:53 AM, Eric K <ekcs.openst...@gmail.com> wrote:
>>> Thanks a lot Witold and Thomas!
>>>
>>> So it doesn't seem that someone is currently using a keystone token to
>>> authenticate web hook? Is is simply because most of the use cases had
>>> involved services which do not use keystone?
>>>
>>> Or is it unsuitable for another reason?
>>
>>It's fairly impractical for webhooks because
>>
>>1) Tokens expire fairly quickly.
>>2) You can't store all the data in the URL, so you need to store the
>>token and the URL separately.
>>
>>-- 
>>Thomas
>>
>>_
>>_
>>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] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

Thanks, Thomas!

I see the point that it is impractical to configure a service with a fixed
keystone token to use in webhook notifications because they expire fairly
quickly.

I'm thinking about the situation where the sending service can obtain
tokens directly from keystone. In that case I'm guessing the main reason
it hasn't been done that way is because it does not generalize to most
other services that don't connect to keystone?

On 5/6/18, 9:30 AM, "Thomas Herve" <the...@redhat.com> wrote:

>On Sat, May 5, 2018 at 1:53 AM, Eric K <ekcs.openst...@gmail.com> wrote:
>> Thanks a lot Witold and Thomas!
>>
>> So it doesn't seem that someone is currently using a keystone token to
>> authenticate web hook? Is is simply because most of the use cases had
>> involved services which do not use keystone?
>>
>> Or is it unsuitable for another reason?
>
>It's fairly impractical for webhooks because
>
>1) Tokens expire fairly quickly.
>2) You can't store all the data in the URL, so you need to store the
>token and the URL separately.
>
>-- 
>Thomas
>
>__
>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] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

Thanks a lot Witold and Thomas!

So it doesn't seem that someone is currently using a keystone token to
authenticate web hook? Is is simply because most of the use cases had
involved services which do not use keystone?

Or is it unsuitable for another reason?

On 5/4/18, 2:36 AM, "Thomas Herve" <the...@redhat.com> wrote:

>On Thu, May 3, 2018 at 9:49 PM, Eric K <ekcs.openst...@gmail.com> wrote:
>> Question to the projects which send or consume webhook notifications
>> (telemetry, monasca, senlin, vitrage, etc.), what are your
>> supported/preferred authentication mechanisms? Bearer token (e.g.
>> Keystone)? Signing?
>>
>> Any pointers to past discussions on the topic? My interest here is
>>having
>> Congress consume and send webhook notifications.
>>
>> I know some people are working on adding the keystone auth option to
>> Monasca's webhook framework. If there is a project that already does it,
>> it could be a very helpful reference.
>
>Hi,
>
>I'll add a few that you didn't mention which consume such webhooks.
>
> * Heat has been using EC2 signatures basically since forever. It
>creates EC2 credentials for a Keystone user, and signs URL that way.
> * Zaqar has signed URLs
>(https://developer.openstack.org/api-ref/message/#pre-signed-queue)
>which allows sharing queues without authentication.
> * Swift temp URLs
>(https://docs.openstack.org/swift/latest/middleware.html#tempurl) is a
>good mechanism to share information as well.
>
>I'd say application credentials would make those operations a bit
>nicer, but they are not completely there yet. Everybody not
>reinventing its own wheel would be nice too :).
>
>-- 
>Thomas
>
>__
>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] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

Question to the projects which send or consume webhook notifications
(telemetry, monasca, senlin, vitrage, etc.), what are your
supported/preferred authentication mechanisms? Bearer token (e.g.
Keystone)? Signing?

Any pointers to past discussions on the topic? My interest here is having
Congress consume and send webhook notifications.

I know some people are working on adding the keystone auth option to
Monasca's webhook framework. If there is a project that already does it,
it could be a very helpful reference.


Thanks very much!



__
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] [all][ptl][release] reminder for rocky-1 milestone deadline

[Eric K]

Got it thanks a lot, Doug and Matt!

On 4/19/18, 11:34 AM, "Matt Riedemann"  wrote:

>On 4/19/2018 1:15 PM, Doug Hellmann wrote:
>> Second, releasing early and often gives us more time to fix issues,
>> so we aren't rushing around at deadline trying to solve a problem
>> while the gate is full of other last minute patches for other
>> projects.
>
>Yup, case in point: I waited too long to release python-novaclient 10.x
>in Queens and it prevented us from being able to include it in
>upper-constraints for Queens because it negatively impacted some other
>projects due to backward incompatible changes in the 10.x series of
>novaclient. So learn from my mistakes.
>
>-- 
>
>Thanks,
>
>Matt
>
>__
>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] [all][ptl][release] reminder for rocky-1 milestone deadline

[Eric K]

Specifically, for client library using the cycle-with-intermediary release
model.

On 4/19/18, 10:52 AM, "Eric K" <ekcs.openst...@gmail.com> wrote:

>Thank you, Doug. Question: do we need to do a client library release prior
>to R-3? The practice seems to change from cycle to cycle.
>
>On 4/19/18, 6:15 AM, "Doug Hellmann" <d...@doughellmann.com> wrote:
>
>>Today is the deadline for proposing a release for the Rocky-1 milestone.
>>Please don't forget to include your libraries (client or otherwise) as
>>well.
>>
>>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
>
>



__
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] [all][ptl][release] reminder for rocky-1 milestone deadline

[Eric K]

Thank you, Doug. Question: do we need to do a client library release prior
to R-3? The practice seems to change from cycle to cycle.

On 4/19/18, 6:15 AM, "Doug Hellmann"  wrote:

>Today is the deadline for proposing a release for the Rocky-1 milestone.
>Please don't forget to include your libraries (client or otherwise) as
>well.
>
>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



__
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] [mistral][tempest][congress] import or retain mistral tempest service client

[Eric K]

Thank you, Dougal and Ghanshyam for the responses!

What I can gather is: service client registration > import service client
> retaining copy.
So the best thing for Congress to do now is to import the service client.

On 3/17/18, 9:00 PM, "Ghanshyam Mann" <gm...@ghanshyammann.com> wrote:

>Hi All,
>
>Sorry for late response, i kept this mail unread but forgot to
>respond. reply inline.
>
>On Fri, Mar 16, 2018 at 8:08 PM, Dougal Matthews <dou...@redhat.com>
>wrote:
>>
>>
>> On 13 March 2018 at 18:51, Eric K <ekcs.openst...@gmail.com> wrote:
>>>
>>> Hi Mistral folks and others,
>>>
>>> I'm working on Congress tempest tests [1] for integration with
>>>Mistral. In
>>> the tests, we use a Mistral service client to call Mistral APIs and
>>> compare results against those obtained by Mistral driver for Congress.
>>>
>>> Regarding the service client, Congress can either import directly from
>>> Mistral tempest plugin [2] or maintain its own copy within Congress
>>> tempest plugin.
>
>Maintaining own copy will leads to lot of issues and lot of duplicate
>code among many plugins.
>
>>I'm not sure whether Mistral team expects the service
>>> client to be internal use only, so I hope to hear folks' thoughts on
>>>which
>>> approach is preferred. Thanks very much!
>>
>>
>> I don't have a strong opinion here. I am happy for you to use the
>>Mistral
>> service client, but it will be hard to guarantee stability. It has been
>> stable (since it hasn't changed), but we have a temptest refactor
>>planned
>> (once we move the final tempest tests from mistraclient to
>> mistral-tempest-plugin). So there is a fair chance we will break the
>>API at
>> that point, however, I don't know when it will happen, as nobody is
>> currently working on it.
>
>From QA team, service clients are the main interface which can be used
>across tempest plugins. For example, congress need many other service
>clients from other Tempest Plugins liek Mistral. Tempest also declare
>all their in-tree service clients as library interface and we maintain
>them as per backward compatibility [3]. This way we make these service
>clients usable outside of Tempest also to avoid duplicate
>code/interface.
>
>For Service Clients defined in Tempest plugins (like Mistral service
>clients),  we suggest (strongly) the same process which is to declare
>plugins's service clients as stable interface which gives 2 advantage:
>1. By this you make sure that you are not allowing to change the API
>calling interface(service clietns) which indirectly means you are not
>allowing to change the APIs. Makes your tempest plugin testing more
>reliable.
>
>2. Your service clients can be used in other Tempest plugins to avoid
>duplicate code/interface. If any other plugins use you service clients
>means, they also test your project so it is good to help them by
>providing the required interface as stable.
>
>Initial idea of owning the service clients in their respective plugins
>was to share them among plugins for integrated testing of more then
>one openstack service.
>
>Now on usage of service clients, Tempest provide a better way to do so
>than importing them directly [4]. You can see the example for Manila's
>tempest plugin [5]. This gives an advantage of discovering your
>registered service clients in other Tempest plugins automatically.
>They do not need to import other plugins service clients. QA is hoping
>that each tempest plugins will move to new service client registration
>process.
>
>Overall, we recommend to have service clients as stable interface so
>that other plugins can use them and test your projects in more
>integrated way.
>
>>
>> I have cc'ed Chandan - hopefully he can provide some input. He has
>>advised
>> me and the Mistral team regarding tempest before.
>>
>>>
>>>
>>> Eric
>>>
>>> [1] https://review.openstack.org/#/c/538336/
>>> [2]
>>>
>>> 
>>>https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_
>>>tem
>>> pest_tests/services/v2/mistral_client.py
>>>
>>>
>
>..3 
>http://git.openstack.org/cgit/openstack/tempest/tree/tempest/lib/services
>..4 
>https://docs.openstack.org/tempest/latest/plugin.html#get_service_clients(
>)
>..5 https://review.openstack.org/#/c/334596/34
>
>-gmann
>
>>>
>>> 
>>>
>>>__
>>> OpenStack Development Mailing List (not for usage q

[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] [mistral][tempest][congress] import or retain mistral tempest service client

[Eric K]

Hi Mistral folks and others,

I'm working on Congress tempest tests [1] for integration with Mistral. In
the tests, we use a Mistral service client to call Mistral APIs and
compare results against those obtained by Mistral driver for Congress.

Regarding the service client, Congress can either import directly from
Mistral tempest plugin [2] or maintain its own copy within Congress
tempest plugin. I'm not sure whether Mistral team expects the service
client to be internal use only, so I hope to hear folks' thoughts on which
approach is preferred. Thanks very much!

Eric

[1] https://review.openstack.org/#/c/538336/
[2] 
https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_tem
pest_tests/services/v2/mistral_client.py



__
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

Re: [openstack-dev] [monasca][congress] help configuring monasca for gate

[Eric K]

Thank Witek =)

We're looking at getting pushed alarm data from Monasca via webhook.
Fabiog started that quite a while back and we're hoping to revive it. Not
sure there is any feature requests. But I do want to understand the
authentication situation in Monasca webhook. Wondering whether Congress
should require keystone auth in the webhook request or expect
unauthenticated requests.

On a much more ambitious and speculative front, we're also thinking about
how Congress may be able to leverage Monasca to evaluate certain policies.
It's also something we explored with fabiog before. For example, if there
is a rule that identifies low usage servers:
  underutilized_servers(server_id) :-
  ceilometer:statistics(meter_name='cpu_util',resource_id=server_id,
avg=avg),builtin:lt(avg, 10)
There may be a way for Congress to (semi) automatically create a
corresponding Monasca alarm and rewrite the rule to depend on the alarm.

I'd also love to hear if there are any other thoughts for how one project
may benefit from the other.

Eric Kao (ekcs)

On 2/13/18, 6:45 AM, "Bedyk, Witold" <witold.be...@est.fujitsu.com> wrote:

>Hi Eric,
>
>glad to hear the problems are solved :)
>
>What are your plans around integration with Monasca? Please let us know
>if you have related feature requests.
>
>Cheers
>Witek
>
>
>> -Original Message-
>> From: Eric K [mailto:ekcs.openst...@gmail.com]
>> Sent: Dienstag, 13. Februar 2018 03:59
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [monasca][congress] help configuring
>>monasca
>> for gate
>> 
>> Oops. Nevermind. Looks like it's working now.
>> 
>> On 2/12/18, 5:00 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:
>> 
>> >Hi Monasca folks,
>> >I'm trying to configure monasca in congress gate [1] and modeled it
>> >after this monasca playbook [2]. But I get:
>> >rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed:
>> >No such file or directory (2)
>> >
>> >http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql
>> >/16
>> >6
>> >d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-
>> 30_01_53_41
>> >_60
>> >7
>> >
>> >
>> >Any hints on what I need to do differently? Thanks!
>> >
>> >[1] https://review.openstack.org/#/c/530522/
>> >[2]
>> >https://github.com/openstack/monasca-
>> api/blob/master/playbooks/legacy/m
>> >ona
>> >s
>> >ca-tempest-base/run.yaml
>> >
>> >
>> 
>> 
>> 
>> __
>> 
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [ptg][congress] Congress Rocky brainstorming & planning

[Eric K]

Hi all,

In lieu of planning sessions at the PTG, let's have asynchronous
brainstorming and a sync-up telecon.
(I will still be available at the PTG for discussions).

If you're interested, please:
1. Jot down your thoughts and ideas (problems, features, use cases, etc.)
in this planning/brainstorming etherpad:
https://etherpad.openstack.org/p/congress-rocky-brainstorm

2. Indicate your likely availability in this calendar (targeting the week
after PTG):
http://whenisgood.net/2yxtikn

Thanks so much!

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] [monasca][congress] help configuring monasca for gate

[Eric K]

Oops. Nevermind. Looks like it's working now.

On 2/12/18, 5:00 PM, "Eric K" <ekcs.openst...@gmail.com> wrote:

>Hi Monasca folks,
>I'm trying to configure monasca in congress gate [1] and modeled it after
>this monasca playbook [2]. But I get:
>rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
>such file or directory (2)
>
>http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/16
>6
>d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_60
>7
>
>
>Any hints on what I need to do differently? Thanks!
>
>[1] https://review.openstack.org/#/c/530522/
>[2] 
>https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/mona
>s
>ca-tempest-base/run.yaml
>
>



__
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] [monasca][congress] help configuring monasca for gate

[Eric K]

Hi Monasca folks,
I'm trying to configure monasca in congress gate [1] and modeled it after
this monasca playbook [2]. But I get:
rsync: change_dir "/home/zuul/src/*/openstack/monasca-common" failed: No
such file or directory (2)

http://logs.openstack.org/22/530522/1/check/congress-devstack-api-mysql/166
d935/logs/devstack-gate-setup-workspace-new.txt.gz#_2017-12-30_01_53_41_607


Any hints on what I need to do differently? Thanks!

[1] https://review.openstack.org/#/c/530522/
[2] 
https://github.com/openstack/monasca-api/blob/master/playbooks/legacy/monas
ca-tempest-base/run.yaml



__
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

[openstack-dev] [requirements][congress] getting requirements updates for congress-dashboard

[Eric K]

Hi all,

I'm having some trouble getting congress-dashboard to receive requirements
updates from global-requirements.

The check-requirements job seems to be configured, but does NOT seem to be
running:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr
ojects.yaml#n4246

The project is also listed in the requirements repo:
http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt#n24

Any hints on what may be wrong? Thanks very much!

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] [infra][tempest][devstack][congress] tempest.config.CONF.service_available changed on Jan 2/3?

[Eric K]

On 1/7/18, 9:27 PM, "Ghanshyam Mann" <ghanshyamm...@gmail.com> wrote:

>On Sat, Jan 6, 2018 at 3:41 PM, Chandan kumar <chkumar...@gmail.com>
>wrote:
>> Hello Eric,
>>
>> On Sat, Jan 6, 2018 at 4:46 AM, Eric K <ekcs.openst...@gmail.com> wrote:
>>> Seems that sometime between 1/2 and 1/3 this year,
>>> tempest.config.CONF.service_available.aodh_plugin as well as
>>> ..service_available.mistral became unavailable in congress dsvm
>>>check/gate
>>> job. [1][2]
>>>
>>> I've checked the changes that went in to congress, tempest, devstack,
>>> devstack-gate, aodh, and mistral during that period but don't see
>>>obvious
>>> causes. Any suggestions on where to look next to fix the issue? Thanks
>>> very much!
>
>These config options should stay there even separating the tempest
>plugin.  I have checked aodh and mistral config options and there are
>present as tempest config.
>
>- 
>https://github.com/openstack/telemetry-tempest-plugin/blob/b30a19214d00361
>41de75047b444d48ae0d0b656/telemetry_tempest_plugin/config.py#L27
>- 
>https://github.com/openstack/mistral-tempest-plugin/blob/63a0fe20f98e0cb83
>16beb81ca77249ffdda29c5/mistral_tempest_tests/config.py#L18
>
>
>Issue occurred because of removing the in-tree plugins before congress
>was setup to use new repo. We should not remove the in-tree plugin
>before gate setup of consuming the new plugin is complete for each
>consumer of plugings.
>
>>>
>>
>> The aodh tempest plugin [https://review.openstack.org/#/c/526299/] is
>> moved to telemetry-tempest-plugin
>> [https://github.com/openstack/telemetry-tempest-plugin].
>> I have sent a patch to Congress project to fix the issue:
>> https://review.openstack.org/#/c/531534/
>
>Thanks Chandan, this will fix congress issue for Aodh, we need same
>fix for mistral case too.
Thank you Chandan Kumar and Ghanshyam Mann!
It seems that the adding of telemetry-tempest-plugin does not solve the
issue though.
I did a testing patch based-off of Chandan's, and the aodh test was still
skipped. Any ideas what more needs to be done? Thanks so much!
https://review.openstack.org/#/c/531922/
http://logs.openstack.org/22/531922/1/check/congress-devstack-api-mysql/381
2b5d/logs/testr_results.html.gz
>
>>
>> The mistral bundled intree tempest plugin
>> [https://review.openstack.org/#/c/526918/] is also moved to
>> mistral-tempest-plugin repo
>> [https://github.com/openstack/mistral-tempest-plugin]
>>
>> Tests are moved to a new repo as a part of Tempest Plugin Split goal
>> 
>>[https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.h
>>tml].
>> Feel free to consume the new tempest plugin and let me know if you
>> need any more help.
>>
>> Thanks,
>>
>> Chandan Kumar
>>
>> 
>>_
>>_
>> 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] generic push driver

[Eric K]

From:  Tim Hinrichs <t...@styra.com>
Date:  Monday, January 8, 2018 at 7:31 AM
To:  Eric Kao <ekcs.openst...@gmail.com>
Cc:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
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 <ekcs.openst...@gmail.com> 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)" <ifat.a...@nokia.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:  Sunday, January 7, 2018 at 4:00 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
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 <ekcs.openst...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Saturday, 6 January 2018 at 3:50
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> 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",
> 
>   "

[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] [infra][tempest][devstack][congress] tempest.config.CONF.service_available changed on Jan 2/3?

[Eric K]

Seems that sometime between 1/2 and 1/3 this year,
tempest.config.CONF.service_available.aodh_plugin as well as
..service_available.mistral became unavailable in congress dsvm check/gate
job. [1][2]

I've checked the changes that went in to congress, tempest, devstack,
devstack-gate, aodh, and mistral during that period but don't see obvious
causes. Any suggestions on where to look next to fix the issue? Thanks
very much!

Eric Kao

[1] test results from Jan 2; note that aodh is available:
http://logs.openstack.org/54/530154/5/check/congress-devstack-api-mysql/6f8
2f93/logs/testr_results.html.gz
[2] test results from Jan 3; note that aodh is skipped by this line [3],
but aodh is in fact available as seen from the aodh logs [4]:
http://logs.openstack.org/13/526813/11/gate/congress-devstack-api-mysql/7bf
b025/logs/testr_results.html.gz
[3] 
http://git.openstack.org/cgit/openstack/congress/tree/congress_tempest_test
s/tests/scenario/congress_datasources/test_aodh.py#n32
[4] 
http://logs.openstack.org/13/526813/11/gate/congress-devstack-api-mysql/7bf
b025/logs/



__
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

Re: [openstack-dev] [keystone] keystone client service_catalog is None

[Eric K]

Thank you Boris for the pointers!

On 12/9/17, 7:07 AM, "Boris Bobrov" <bre...@cynicmansion.ru> wrote:

>Hi,
>
>Have a look at how openstackclient does this. Read this code:
>https://github.com/openstack/python-openstackclient/blob/master/openstackc
>lient/identity/v3/catalog.py#L43
>and then this code:
>https://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#
>L239
>
>
>On 09.12.2017 04:15, Eric K wrote:
>> Hi all,
>> 
>> I'm working on some code [1] that attempts to retrieve a endpoint from
>>the
>> service_catalog, but the service_catalog comes up None. Any suggestions
>>on
>> what I need to do differently to get a working service_catalog? Thanks
>> very much!
>> 
>> Python 2.7.12 (default, Nov 20 2017, 18:23:56)
>> [GCC 5.4.0 20160609] on linux2
>>>>> from keystoneauth1 import session # Version 2.12.1
>>>>> from keystoneauth1.identity import v2
>>>>> import keystoneclient.v3.client as ksclient
>>>>> auth = v2.Password(auth_url='http://127.0.0.1/identity',
>>>>> username='admin', password='password', tenant_name='admin')
>>>>> sess = session.Session(auth=auth)
>>>>> keystone = ksclient.Client(session=sess)
>>>>> print(keystone.service_catalog)
>> None
>> 
>> 
>> 
>> [1] 
>> 
>>https://review.openstack.org/#/c/526813/1/congress/datasources/monasca_dr
>>iv
>> er.py@94
>> 
>> 
>> 
>> 
>>_
>>_
>> 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] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Eric K]

Submitted this after merging the fix:
https://review.openstack.org/#/c/526834/

Is that the correct step? Thanks again!

On 12/8/17, 2:10 PM, "Sean McGinnis"  wrote:

>On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
>> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
>> > Build failed.
>> > 
>> > - release-openstack-python-without-pypi
>>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre
>>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m
>>53s
>> > - announce-release announce-release : SKIPPED
>> > 
>> 
>> This error looks like there is a bad file reference in the MANIFEST.in:
>> 
>> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
>> ERROR: InvocationError:
>> 
>>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
>> setup.py bdist_wheel'
>> venv finish: runtests after 2.76 seconds
>
>I think this is needed to fix it. Some missing cleanup work from the
>policy-in-code activity.
>
>https://review.openstack.org/#/c/526274/
>
>
>__
>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] [keystone] keystone client service_catalog is None

[Eric K]

Hi all,

I'm working on some code [1] that attempts to retrieve a endpoint from the
service_catalog, but the service_catalog comes up None. Any suggestions on
what I need to do differently to get a working service_catalog? Thanks
very much!

Python 2.7.12 (default, Nov 20 2017, 18:23:56)
[GCC 5.4.0 20160609] on linux2
>>> from keystoneauth1 import session # Version 2.12.1
>>> from keystoneauth1.identity import v2
>>> import keystoneclient.v3.client as ksclient
>>> auth = v2.Password(auth_url='http://127.0.0.1/identity',
>>>username='admin', password='password', tenant_name='admin')
>>> sess = session.Session(auth=auth)
>>> keystone = ksclient.Client(session=sess)
>>> print(keystone.service_catalog)
None



[1] 
https://review.openstack.org/#/c/526813/1/congress/datasources/monasca_driv
er.py@94



__
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] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Eric K]

Ah sorry about that, Doug. And thank you for the pointer, Sean. I'm on it.

On 12/8/17, 2:10 PM, "Sean McGinnis"  wrote:

>On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
>> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
>> > Build failed.
>> > 
>> > - release-openstack-python-without-pypi
>>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre
>>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m
>>53s
>> > - announce-release announce-release : SKIPPED
>> > 
>> 
>> This error looks like there is a bad file reference in the MANIFEST.in:
>> 
>> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
>> ERROR: InvocationError:
>> 
>>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
>> setup.py bdist_wheel'
>> venv finish: runtests after 2.76 seconds
>
>I think this is needed to fix it. Some missing cleanup work from the
>policy-in-code activity.
>
>https://review.openstack.org/#/c/526274/
>
>
>__
>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][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" <ekcs.openst...@gmail.com> 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] 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

Re: [openstack-dev] [infra][devstack][congress] zuul3 transition surfaced error: The following LIBS_FROM_GIT were not installed correct: python-congressclient

[Eric K]

Ah got it thanks a lot Sam!

On 10/2/17, 12:39 PM, "Sam Matzek" <matzek...@gmail.com> wrote:

>This is also one of several errors hitting the Trove gate.  This
>review should workaround the issue for now.
>
>https://review.openstack.org/#/c/508344/3
>
>On Mon, Oct 2, 2017 at 1:44 PM, Eric K <ekcs.openst...@gmail.com> wrote:
>> Since the transition to zuul3, this error began and prevents the
>>devstack
>> setup from finishing on Congress gate jobs. I've been working to
>>diagnose
>> it but so far without success.
>>
>> Any suggestions and tips much appreciated!
>>
>> 
>>http://logs.openstack.org/58/493258/5/check/legacy-congress-dsvm-api-mysq
>>l/
>> cfb57ff/logs/devstacklog.txt.gz#_2017-10-01_23_46_16_449
>>
>> ./stack.sh:1392:check_libs_from_git
>> /opt/stack/new/devstack/inc/python:404:die
>> [ERROR] /opt/stack/new/devstack/inc/python:404 The following
>>LIBS_FROM_GIT
>> were not installed correct: python-congressclient
>> Error on exit
>>
>>
>> Note: previous to the transition to zuul3, it was already a problem on
>> python3 devstack setup at gate but never on python2. For example, see
>> these results run pre-zuul3: https://review.openstack.org/#/c/498996/
>>
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [infra][devstack][congress] zuul3 transition surfaced error: The following LIBS_FROM_GIT were not installed correct: python-congressclient

[Eric K]

Since the transition to zuul3, this error began and prevents the devstack
setup from finishing on Congress gate jobs. I've been working to diagnose
it but so far without success.

Any suggestions and tips much appreciated!

http://logs.openstack.org/58/493258/5/check/legacy-congress-dsvm-api-mysql/
cfb57ff/logs/devstacklog.txt.gz#_2017-10-01_23_46_16_449

./stack.sh:1392:check_libs_from_git
/opt/stack/new/devstack/inc/python:404:die
[ERROR] /opt/stack/new/devstack/inc/python:404 The following LIBS_FROM_GIT
were not installed correct: python-congressclient
Error on exit


Note: previous to the transition to zuul3, it was already a problem on
python3 devstack setup at gate but never on python2. For example, see
these results run pre-zuul3: https://review.openstack.org/#/c/498996/



__
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

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

[Eric K]

As far as I can tell, bumping min version to 1.7.0 would not be a problem
for Congress.

Eric Kao

On 8/3/17, 4:39 AM, "witold.be...@est.fujitsu.com"
 wrote:

>Hello everyone,
>
>I would like to ask for the FFE for python-monascaclient version in
>global requirements.
>
>The current version in Pike (1.7.0) is not fully backward compatible. The
>monasca exception classes were replaced with keystoneauth exceptions,
>which affects heat and watcher projects if they use current upper
>constraints. The fixes for these projects have been submitted [1, 2].
>
>Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
>python-monascaclient 1.7.0 and don't work with older versions.
>
>The change for bumping the minimum version of python-monascaclient is
>here:
>
>https://review.openstack.org/489173
>
>
>Best greetings
>Witek Bedyk
>
>
>[1] https://review.openstack.org/490016
>[2] https://review.openstack.org/490018
>
>__
>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] [infra] redo gate jobs only

[Eric K]

Thanks a lot Jeremy and Andreas for the reference and the added context!

On 8/3/17, 10:49 AM, "Jeremy Stanley"  wrote:

>On 2017-08-03 08:15:36 +0200 (+0200), Andreas Jaeger wrote:
>[...]
>> "A patchset has to be approved to run tests in the gate pipeline. If the
>> patchset has failed in the gate pipeline (it will have been approved to
>> get into the gate pipeline) a recheck will first run the check jobs and
>> if those pass, it will again run the gate jobs. There is no way to only
>> run the gate jobs, the check jobs will first be run again."
>
>The reasons being:
>
>1. There's no good way to decide how long is too long to wait
>between passing jobs in check and running jobs in the gate. We used
>to not enforce this "clean check" policy and developers would
>repeatedly reverify broken changes back into the gate pipeline over
>and over creating a significant amount of additional disruption
>because their change had passed check jobs once (perhaps many months
>earlier). Now they at least only get to disrupt the gate once when
>that change gets approved, but after that it won't be able to make
>it back into the gate until a fixed revision is uploaded and so
>doesn't further slow down the merging of unrelated changes.
>
>2. If a change passes jobs once (in check) and then fails later (in
>the gate) then there's a fair chance it's introducing a
>nondeterministic bug (one which only manifests sometimes but not on
>every run). Back when we used to allow reverification directly in
>the gate pipeline for changes which passed check, we had people
>rechecking flaky changes until they passed and then reverifying them
>over and over after approval until they made them through the gate.
>Under these conditions a recheck followed by a reverify could merge
>changes which failed jobs 50% of the time; 9 rechecks and 9
>reverifies could merge a change which failed jobs 90% of the time on
>average. With the current requirements to pass both check and gate
>in series, it takes on average 3 rechecks to merge a 50% failing
>change and 99 rechecks to merge a 90% failing change.
>
>So basically if a change fails in the gate pipeline, there's good
>reason for it to get increased scrutiny at least in the form of
>trying the jobs again in the check pipeline before going back to the
>gate once more.
>-- 
>Jeremy Stanley
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [infra] redo gate jobs only

[Eric K]

Hi all is there a command on review.openstack.org that triggers a redo of
gate jobs but not check jobs (already passed)?
`remerge` doesn¹t seem to do anything. 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] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Eric K]

Thanks for the suggestion, Jeremy.

I¹ll look into that. Two key pieces will be needed:
1. Know ahead of time what user tempest tests would be run from (should be
determined by job setup?)
2. Have a way to specify in job/devstack to start congress using that user.

On 7/28/17, 6:30 AM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

>On 2017-07-27 20:37:49 -0700 (-0700), Eric K wrote:
>> A tempest test [1] launches additional instances of Congress using
>> subprocess.popen and tests the coordination between them and the
>>original
>> instance launched by devstack. The problem is, the new instances are
>> launched from the tempest test user rather than the user of the original
>> congress instance devstack created. As a result, the new instances fail
>> for being unable to access the encryption keys created by the original
>> congress instance (600 permission).[2]
>> 
>> Any suggestions for how to workaround this problem? Is it possible to
>> somehow configure the gate job to run tempest tests as SU or as the
>> stackuser that launches the original congress instance?
>[...]
>
>Could you flip this around and create the original instances with
>the tempest user? That seems less likely to violate base assumptions
>about the test environment.
>-- 
>Jeremy Stanley
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Eric K]

Thanks for your help and sketch of solution, Andrea!  -Eric

From:  Andrea Frittoli <andrea.fritt...@gmail.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:  Friday, July 28, 2017 at 9:03 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [tempest][infra][congress] subprocess launched
in tempest test lacks file permission

> 
> 
> On Fri, Jul 28, 2017 at 4:38 AM Eric K <ekcs.openst...@gmail.com> wrote:
>> A tempest test [1] launches additional instances of Congress using
>> subprocess.popen and tests the coordination between them and the original
>> instance launched by devstack. The problem is, the new instances are
>> launched from the tempest test user rather than the user of the original
>> congress instance devstack created. As a result, the new instances fail
>> for being unable to access the encryption keys created by the original
>> congress instance (600 permission).[2]
>> 
>> Any suggestions for how to workaround this problem? Is it possible to
>> somehow configure the gate job to run tempest tests as SU or as the
>> stackuser that launches the original congress instance? Thanks so much!
> 
> Unfortunately we don't have any facility in Tempest to control the user for
> subprocesses since Tempest is meant for API testing only. Starting a
> subprocess within the test sounds a bit outside of the scope of what you
> may want to do in a Tempest test.
>  
> If you want to use Tempest to verify HA type of scenarios you may want
> to move the orchestration bit outside of Tempest - you could have an ansible
> script that manages your services and run Tempest before and after certain
> actions to verify that things are still working.
> 
> If you want tests to run in parallel to things happening to your system you
> can do that but again you will need an external component to orchestrate
> this, and you don't know what kind of tempest test will be running unless
> you use a single long running scenario test designed for this purpose.
> 
> Andrea Frittoli (andreaf)
> 
>> 
>> [1]
>> https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
>> sts/scenario/congress_ha/test_ha.py.disabled#L117
>> <https://github.com/openstack/congress/blob/master/congress_tempest_tests/tes
>> ts/scenario/congress_ha/test_ha.py.disabled#L117>  (currently disabled,
>> trying to re-enable)
>> 
>> [2]
>> http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
>> untu-xenial/607623d/logs/testr_results.html.gz
>> <http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ubu
>> ntu-xenial/607623d/logs/testr_results.html.gz>  (find: OSError: [Errno 13]
>> Permission denied: '/etc/congress/keys/aes_key¹)
>> 
>> 
>> 
>> __
>> 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

[openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Eric K]

A tempest test [1] launches additional instances of Congress using
subprocess.popen and tests the coordination between them and the original
instance launched by devstack. The problem is, the new instances are
launched from the tempest test user rather than the user of the original
congress instance devstack created. As a result, the new instances fail
for being unable to access the encryption keys created by the original
congress instance (600 permission).[2]

Any suggestions for how to workaround this problem? Is it possible to
somehow configure the gate job to run tempest tests as SU or as the
stackuser that launches the original congress instance? Thanks so much!

[1] 
https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
sts/scenario/congress_ha/test_ha.py.disabled#L117 (currently disabled,
trying to re-enable)

[2] 
http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
untu-xenial/607623d/logs/testr_results.html.gz (find: OSError: [Errno 13]
Permission denied: '/etc/congress/keys/aes_key¹)



__
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] [infra][python3][congress] locally successful devstack setup fails in check-job

[Eric K]

On 7/19/17, 1:11 PM, "Clark Boylan" <cboy...@sapwetik.org> wrote:

>On Tue, Jul 18, 2017, at 12:47 PM, Eric K wrote:
>> Hi all, looking for some hints/tips. Thanks so much in advance.
>> 
>> My local python3 devstack setup [2] succeeds, but in check-job a
>> similarly
>> configured devstack setup [1] fails for not installing congress client.
>> 
>> ./stack.sh:1439:check_libs_from_git
>> /opt/stack/new/devstack/inc/python:401:die
>> [ERROR] /opt/stack/new/devstack/inc/python:401 The following
>> LIBS_FROM_GIT
>> were not installed correct: python-congressclient
>> 
>> 
>> It seems that the devstack setup in check-job never attempted to install
>> congress client. Comparing the log [4] in my local run to the log in
>> check-job [3], all these steps in my local log are absent from the
>> check-job log:
>> ++/opt/stack/congress/devstack/settings:source:9
>> CONGRESSCLIENT_DIR=/opt/stack/python-congressclient
>> 
>> ++/opt/stack/congress/devstack/settings:source:52
>> 
>>CONGRESSCLIENT_REPO=git://git.openstack.org/openstack/python-congressclie
>>nt
>> .git
>> 
>> Cloning into '/opt/stack/python-congressclient'?
>
>You won't see this logged by devstack because devstack-gate does all of
>the git repo setup beforehand to ensure that the correct git refs are
>checked out.
>
>> 
>> Check python version for : /opt/stack/python-congressclient
>> Automatically using 3.5 version to install
>> /opt/stack/python-congressclient based on classifiers
>> 
>> 
>> Installing collected packages: python-congressclient
>>   Running setup.py develop for python-congressclient
>> Successfully installed python-congressclient
>> 
>> 
>> [1] Check-job config:
>> 
>>https://github.com/openstack-infra/project-config/blob/master/jenkins/job
>>s/
>> congress.yaml#L65
>> 
>>https://github.com/openstack-infra/project-config/blob/master/jenkins/job
>>s/
>> congress.yaml#L111
>> 
>> [2] Local devstack local.conf:
>> https://pastebin.com/qzuYTyAE
>> 
>> [3] Check-job devstack log:
>> 
>>http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-m
>>ys
>> ql-ubuntu-xenial-nv/7ae2814/logs/devstacklog.txt.gz
>> 
>> [4] Local devstack log:
>> https://ufile.io/c9jhm
>
>My best guess of what is happening here is that python-congressclient is
>being installed to python2 from source so then when devstack checks if
>python-congressclient is installed properly against python3 it fails.
>You'll want to make sure that whatever is installing
>python-congressclient is doing so against the appropriate python.

Thanks a lot Clark!

Now pursuing the guess that install was done in wrong python version.

I was actually looking at the wrong log. Here is the correct one.
http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-mys
ql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz

In this log, I see it successfully installing congress client here:
| Installing collected packages: python-congressclient

| Running setup.py develop for python-congressclient

| Successfully installed python-congressclient

| + ./stack.sh:main:941 : use_library_from_git python-openstackclient

| + inc/python:use_library_from_git:378 : local enabled=1
| + inc/python:use_library_from_git:379 : [[ python-congressclient =
\A\L\L ]]
| + inc/python:use_library_from_git:379 : [[ ,python-congressclient, =~
,python-openstackclient, ]]
| + inc/python:use_library_from_git:380 : return 1

(http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-my
sql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz#_2017-07-19_06_26_31_5
46)

From then on there is nothing noteworthy re: congress client until it says
the client is not installed correctly:
| + inc/python:check_libs_from_git:395 : lib_installed_from_git
python-congressclient

...
| + inc/python:check_libs_from_git:401 : die 401 'The following
LIBS_FROM_GIT were not installed correct: python-congressclient’

(http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-my
sql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz#_2017-07-19_06_36_41_2
01)

Is there a way to tell from these logs whether the install is being done
in python2 or python3? From this line in the log it seems to be doing the
right thing:
| Automatically using 3.5 version to install
/opt/stack/new/python-congressclient based on classifiers

(http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-my
sql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz#_2017-07-19_06_26_24_8
86)

Thanks again!



>
>Clark
>
>__
>O

Re: [openstack-dev] [infra][python3][congress] locally successful devstack setup fails in check-job

[Eric K]

Thanks a lot Jeremy. I'm now running the reproduce.sh to see what happens.

> [3] Check-job devstack log:
> 
>http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-my
>sql-ubuntu-xenial-nv/7ae2814/logs/devstacklog.txt.gz

And oops, I linked to and older run of the check-job devstack log. Here¹s
a more appropriate version:
http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-mys
ql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz

In this log, I see it successfully installing congress client here:
| Installing collected packages: python-congressclient

|   Running setup.py develop for python-congressclient

| Successfully installed python-congressclient

| + ./stack.sh:main:941  :   use_library_from_git
python-openstackclient

| + inc/python:use_library_from_git:378  :   local enabled=1
| + inc/python:use_library_from_git:379  :   [[ python-congressclient
= \A\L\L ]]
| + inc/python:use_library_from_git:379  :   [[
,python-congressclient, =~ ,python-openstackclient, ]]
| + inc/python:use_library_from_git:380  :   return 1

(http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-my
sql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz#_2017-07-19_06_26_31_5
46)

From then on there is nothing noteworthy re: congress client until it says
the client is not installed correctly:
| + inc/python:check_libs_from_git:395   :   lib_installed_from_git
python-congressclient

...
| + inc/python:check_libs_from_git:401   :   die 401 'The following
LIBS_FROM_GIT were not installed correct:  python-congressclient¹

(http://logs.openstack.org/53/485053/1/check/gate-congress-dsvm-py35-api-my
sql-ubuntu-xenial-nv/7f07b73/logs/devstacklog.txt.gz#_2017-07-19_06_36_41_2
01)

Clark suggested that perhaps in install for python-congressclient was
going to python2 instead of python3. So I¹m investigating that.

Thanks again!

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

>On 2017-07-18 12:47:07 -0700 (-0700), Eric K wrote:
>> Hi all, looking for some hints/tips. Thanks so much in advance.
>> 
>> My local python3 devstack setup [2] succeeds, but in check-job a
>>similarly
>> configured devstack setup [1] fails for not installing congress client.
>> 
>> ./stack.sh:1439:check_libs_from_git
>> /opt/stack/new/devstack/inc/python:401:die
>> [ERROR] /opt/stack/new/devstack/inc/python:401 The following
>>LIBS_FROM_GIT
>> were not installed correct: python-congressclient
>> 
>> 
>> It seems that the devstack setup in check-job never attempted to install
>> congress client. Comparing the log [4] in my local run to the log in
>> check-job [3], all these steps in my local log are absent from the
>> check-job log:
>> ++/opt/stack/congress/devstack/settings:source:9
>> CONGRESSCLIENT_DIR=/opt/stack/python-congressclient
>> 
>> ++/opt/stack/congress/devstack/settings:source:52
>> 
>>CONGRESSCLIENT_REPO=git://git.openstack.org/openstack/python-congressclie
>>nt.git
>> 
>> Cloning into '/opt/stack/python-congressclient'
>> 
>> Check python version for : /opt/stack/python-congressclient
>> Automatically using 3.5 version to install
>> /opt/stack/python-congressclient based on classifiers
>> 
>> 
>> Installing collected packages: python-congressclient
>>   Running setup.py develop for python-congressclient
>> Successfully installed python-congressclient
>> 
>> 
>> [1] Check-job config:
>> 
>>https://github.com/openstack-infra/project-config/blob/master/jenkins/job
>>s/congress.yaml#L65
>> 
>>https://github.com/openstack-infra/project-config/blob/master/jenkins/job
>>s/congress.yaml#L111
>> 
>> [2] Local devstack local.conf:
>> https://pastebin.com/qzuYTyAE
>> 
>> [3] Check-job devstack log:
>> 
>>http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-m
>>ysql-ubuntu-xenial-nv/7ae2814/logs/devstacklog.txt.gz
>> 
>> [4] Local devstack log:
>> https://ufile.io/c9jhm
>
>Did you attempt comparison to the local.conf the job used?
>
>http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-my
>sql-ubuntu-xenial-nv/7ae2814/logs/local.conf.txt.gz
>
>Also, if you haven't seen it, every devstack-gate run includes a
>convenience script you should be able to use to reproduce locally
>with the same settings:
>
>http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-my
>sql-ubuntu-xenial-nv/7ae2814/logs/reproduce.sh
>
>Further, https://review.openstack.org/484158 seems to have changed
>the behavior of the job since the log you posted from the 14th. Is
>the result still the same in this case?
>-

[openstack-dev] [infra][python3][congress] locally successful devstack setup fails in check-job

[Eric K]

Hi all, looking for some hints/tips. Thanks so much in advance.

My local python3 devstack setup [2] succeeds, but in check-job a similarly
configured devstack setup [1] fails for not installing congress client.

./stack.sh:1439:check_libs_from_git
/opt/stack/new/devstack/inc/python:401:die
[ERROR] /opt/stack/new/devstack/inc/python:401 The following LIBS_FROM_GIT
were not installed correct: python-congressclient


It seems that the devstack setup in check-job never attempted to install
congress client. Comparing the log [4] in my local run to the log in
check-job [3], all these steps in my local log are absent from the
check-job log:
++/opt/stack/congress/devstack/settings:source:9
CONGRESSCLIENT_DIR=/opt/stack/python-congressclient

++/opt/stack/congress/devstack/settings:source:52
CONGRESSCLIENT_REPO=git://git.openstack.org/openstack/python-congressclient
.git

Cloning into '/opt/stack/python-congressclient'Š

Check python version for : /opt/stack/python-congressclient
Automatically using 3.5 version to install
/opt/stack/python-congressclient based on classifiers


Installing collected packages: python-congressclient
  Running setup.py develop for python-congressclient
Successfully installed python-congressclient


[1] Check-job config:
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/
congress.yaml#L65
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/
congress.yaml#L111

[2] Local devstack local.conf:
https://pastebin.com/qzuYTyAE   

[3] Check-job devstack log:
http://logs.openstack.org/49/484049/1/check/gate-congress-dsvm-py35-api-mys
ql-ubuntu-xenial-nv/7ae2814/logs/devstacklog.txt.gz

[4] Local devstack log:
https://ufile.io/c9jhm



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

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

Re: [openstack-dev] uWSGI help for Congress

[Eric K]

On 5/22/17, 8:54 PM, "gordon chung" <g...@live.ca> wrote:

>
>
>On 22/05/17 05:48 PM, Eric K wrote:
>> If someone out there knows uWSGI and has a couple spare cycles to help
>> Congress project, we'd super appreciate it.
>>
>> The regular contributors to Congress don't have experience with uWSGI
>> and could definitely use some help getting started with this goal.
>> Thanks a ton!
>>
>
>it shouldn't be much different from mod_wsgi. you just need to create a
>uwsgi.ini file which points to the appropriate .wsgi file. here's
>sileht's patch in gnocchi from a while back:
>https://review.openstack.org/#/c/292077. apparently pbr provides wsgi
>file now (not sure what version though):
>https://github.com/gnocchixyz/gnocchi/commit/6377e25bdcca68be66fadf65aa16a
>6f174cfaa99

Thank you Gordon for the references. We have a wsgi app but have not made
it work with mod_wsgi or uwsgi yet.
So I think we still have some steps to go before we¹re at this step. Glad
to have a good reference for when we get there. 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

Re: [openstack-dev] uWSGI help for Congress

[Eric K]

On 5/23/17, 5:37 AM, "Chris Dent" <cdent...@anticdent.org> wrote:

>On Mon, 22 May 2017, Eric K wrote:
>
>> If someone out there knows uWSGI and has a couple spare cycles to help
>> Congress project, we'd super appreciate it.
>>
>> The regular contributors to Congress don't have experience with uWSGI
>>and
>> could definitely use some help getting started with this goal. Thanks a
>>ton!
>
>Is the issue that you need get WSGI working at all (that is, need to
>create a WSGI app for running the api service), or existing WSGI
>tooling, made to work with mod_wsgi, needs to be adapted to work
>with uwsgi?
>In either case, if you're able to point me at existing
>api service code I might be able to provide some pointers.
>
>In the meantime some potentially useful links:
>
>* some notes I took on switching nova and devstack over to uwsg:
>
> https://etherpad.openstack.org/p/devstack-uwsgi
>
>* devstack code for nova+uwsgi
>
> https://review.openstack.org/#/c/457715/
>
>* rewrite of nova's wsgi application to start up properly
>
> https://review.openstack.org/#/c/457283/
>
>This last one might be most useful as it looks like congress is
>using an api startup model (for the non-WSGI case) similar to
>nova's.

Thanks a lot for the references Chris! I¹m very new to this matter so
please excuse my ignorance.
We have a WSGI app but have not made it deployable with either mod_wsgi or
uwsgi, only directly running with paste http server.

Here is the app (wrapper):
https://github.com/openstack/congress/blob/master/congress/api/application.
py#L34

Here¹s the app factory that makes it work with paste:
https://github.com/openstack/congress/blob/master/congress/service.py#L43

Here¹s the routing logic (not relevant I think):
https://github.com/openstack/congress/blob/master/congress/api/webservice.p
y

There is also a wsgi.py file but it appears to be used only for Keystone
context:
https://github.com/openstack/congress/blob/master/congress/common/wsgi.py

As far as I can figure out, the first step is to adapt the existing wsgi
app so it works right with uwsgi. It looks like what we are missing is the
equivalent of this file:
https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi_app.p
y (basically your third link)

Is that right?

I¹ve read the following as well as several wsgi related patches but still
feel quite ungrounded. Any other suggested reading?

http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html
http://docs.webob.org/en/stable/do-it-yourself.html
http://docs.webob.org/en/stable/api/dec.html

Thanks a ton!

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] 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] uWSGI help for Congress

[Eric K]

If someone out there knows uWSGI and has a couple spare cycles to help
Congress project, we'd super appreciate it.

The regular contributors to Congress don't have experience with uWSGI and
could definitely use some help getting started with this goal. Thanks a ton!

https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html

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] 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=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] [all] parsing libraries

[Eric K]

Hi all,

In the congress project, we¹re looking to replace the antlr3-based parser
with a better maintained alternative. I see that pyparsing and Parsley are
used in some projects, could anyone share their experience with them and
potentially other parsing libraries?

The intended use is to parse input into abstract syntax trees according to
a grammar like this:
https://github.com/openstack/congress/blob/master/congress/datalog/Congress
.g

More specific questions:
- how would they do on a grammar that¹s slightly more complex than the
typical usage? e.g.,
https://github.com/openstack/congress/blob/master/congress/datalog/Congress
.g

- does anyone know if Parsley is well-maintained? Their repo seems to be
very quiet over the past 2 yrs
https://github.com/python-parsley/parsley/graphs/contributors?from=2015-02-
01=2017-02-20=c

- Any thoughts or comments on the other Other libraries I¹m considering?
(these are more geared toward larger grammars)
-- Grako https://pypi.python.org/pypi/grako/3.19.1

-- PLY https://pypi.python.org/pypi/ply/3.10
-- I have ³soft-rejected² Antlr4 because the AST feature has been removed.
If I have to put in non-trivial work anyway (to create the AST), I figure
I might as well invest the work into moving to a pure Python framework.
But would love to hear more if someone thinks it¹s the way to go!

Thanks so much!

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

Re: [openstack-dev] [release][all] Ocata release candidates frozen

[Eric K]

Hi all,

I¹d like to request an exception to release Congress RC2. I¹m really sorry
that we got bogged down by a tricky, critical bug that we didn¹t manage to
root cause and patch until the very last minute. I replied to Doug earlier
about it, but neglected to reply to the list.

Here¹s the release request in question:
https://review.openstack.org/#/c/435551/

Thanks so much for considering the request.

Eric

On 2/17/17, 8:08 AM, "Doug Hellmann"  wrote:

>Later today we will be entering the freeze period between the release
>candidates and the final release next Wednesday. We have a couple
>of releases in progress now for senlin and python-magnumclient, but
>after those are completed we will not be releasing anything until
>after the PTG.
>
>I hope to see you in Atlanta!
>
>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



__
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

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