[openstack-dev] [congress] temporary change of meeting time
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?
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?
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
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
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
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
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
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
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
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]
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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: houzhianReply-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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]
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 AnnunziataReply-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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