Open Stack

Try this:

openstack congress policy row list classification error?



________________________________
From: Shiv Haris <sharis at Brocade.com>
Sent: Wednesday, September 16, 2015 12:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] CLI equivalent

Do we have a CLI way for  doing the equivalent of:

$ curl -X GET localhost:1789/v1/policies/classification/tables/error/rows
As described in the tutorial:

https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_congress_blob_master_doc_source_tutorial-2Dtenant-2Dsharing.rst-23listing-2Dpolicy-2Dviolations&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=djA1lFdIf0--GIJ_8gr44Q&m=m3vnP788yf3Iil8q67Kfx9ViGERr356Hb7b2KBSss9M&s=PUH7xM0t0Uy3ovTTmks2NWmKbdfY_90-EJsXIoNvSEQ&e=>

-Shiv

From: Tim Hinrichs [mailto:tim at styra.com]
Sent: Thursday, September 10, 2015 8:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] Ending feature freeze

Hi all,

We're now finished with feature freeze.  We have our first release candidate and the stable/liberty branch.  So master is once again open for new features.  Couple of things to note:

1. Documentation.  We should also look through the docs and update them.  Documentation is really important.  There's one doc patch not yet merged, so be sure to pull that down before editing.  That patch officially deprecates a number of API calls that don't make sense for the new distributed architecture.  If you find places where we don't mention the deprecation, please fix that.

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

2. Bugs.  We should still all be manually testing, looking for bugs, and fixing them.  This will be true especially as other projects change their clients, which as we've seen can break our datasource drivers.

All bug fixes first go into master, and then we cherry-pick to stable/liberty.  Once you've patched a bug on master and it's been merged, you'll create another change for your bug-fix and push it to review.  Then one of the cores will +2/+1 it (usually without needing another formal round of reviews).  Here's the procedure.

// pull down the latest changes for master
$ git checkout master
$ git pull

// create a local branch for stable/liberty and switch to it
$ git checkout origin/stable/liberty -b stable/liberty

// cherry-pick your change from master onto the local stable/liberty
// The -x records the original <sha1 from master> in the commit msg
$ git cherry-pick -x <sha1 from master>

// Push to review and specify the stable/liberty branch.
// Notice in gerrit that the branch is stable/liberty, not master
$ git review stable/liberty

// Once your change to stable/liberty gets merged, fetch all the new
// changes.

// switch to local version of stable/liberty
$ git checkout stable/liberty

// fetch all the new changes to all the branches
$ git fetch origin

// update your local branch
$ git rebase origin/stable/liberty

Tim





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/52432cf9/attachment.html>