Re: [openstack-dev] [Congress] Nominating Masahito for core

[Peter Balland]

+1

From: Tim Hinrichs mailto:t...@styra.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 16, 2016 at 11:15 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress] Nominating Masahito for core

Hi all,

I'm writing to nominate Masahito Muroi for the Congress core team.  He's been a 
consistent contributor for the entirety of Liberty and Mitaka, both in terms of 
code contributions and reviews.  In addition to volunteering for bug fixes and 
blueprints, he initiated and carried out the design and implementation of a new 
class of datasource driver that allows external datasources to push data into 
Congress.  He has also been instrumental in migrating Congress to its new 
distributed architecture.

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

Re: [openstack-dev] [Congress] Congress social night

[Peter Balland]

Hi,

I tried to register, but the link said the event was sold out.  I am
planning on attending.

Thanks,

- Peter

On 10/21/15, 7:21 PM, "Masahito MUROI" 
wrote:

>Hi Congress folks,
>
>Congress team plans to get-together on Wednesday night to be acquainted.
>
>If you are interested, please fill out quick RSVP [1] by the end of the
>week since I want to know a roughly estimated head count. If the number
>is big, I'll book sports bar, Japanese style bar called "Izakaya" or
>somewhere. The place and the time will depend on how many people want to
>go since there is official events on Wednesday night.
>
>1.
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.eventbrite.com_e_c
>ongress-2Dteam-2Ddinner-2Din-2Dtokyo-2Dsuumit-2Dtickets-2D19199371838&d=BQ
>ICJg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zlP7bph5MvLMIU5tJQ_-2
>AcEk-35kD-YRDosa2Aww1E&m=8xdrau-62ty8A5qoxqDMw2a0ZHAItjr-ya3vD8o03sQ&s=W96
>JYhfc5cZcRv6DiBGgYVU3CNEMJAgikLNzzhw05fg&e=
>
>best regard,
>masahito
>
>-- 
>室井 雅仁(Masahito MUROI)
>Software Innovation Center, NTT
>Tel: +81-422-59-4539，FAX: +81-422-59-2699
>
>
>__
>OpenStack Development Mailing List (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] [api] API recommendation

[Peter Balland]

On Oct 16, 2014 8:24 AM, "Dean Troyer"  wrote:
>
>
>
> On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando 
wrote:
>>
>> From an API guideline viewpoint, I understand that
https://review.openstack.org/#/c/86938/ proposes the introduction of a
rather simple endpoint to query active tasks and filter them by resource
uuid or state, for example.
>
>
> That review/blueprint contains one thing that I want to address in more
detail below along with Sal's comment on persistence...
>
>>
>> While this is hardly questionable, I wonder if it might be worth
"typifying" the task, ie: adding a resource_type attribute, and/or allowing
to retrieve active tasks as a chile resource of an object, eg.: GET
/servers//tasks?state=running or if just for running tasks GET
/servers//active_tasks
>
>
> I'd prefer the filter approach, but more importantly, it should be the
_same_ structure as listing resources themselves.
>
> To note: here is another API design detail, specifying resource types in
the URL path:
>
> /server//foo
>
> vs
>
> //foo
>
> or what we have today, for example, in compute:
>
> //foo
>
>> The proposed approach for the multiple server create case also makes
sense to me. Other than "bulk" operations there are indeed cases where a
single API operation needs to perform multiple tasks. For instance, in
Neutron, creating a port implies L2 wiring, setting up DHCP info, and
securing it on the compute node by enforcing anti-spoof rules and security
groups. This means there will be 3/4 active tasks. For this reason I wonder
if it might be the case of differentiating between the concept of
"operation" and "tasks" where the former is the activity explicitly
initiated by the API consumer, and the latter are the activities which need
to complete to fulfil it. This is where we might leverage the already
proposed request_id attribute of the task data structure.
>
>
> I like the ability to track the fan-out, especially if I can get the
state of the entire set of tasks in a single round-trip.  This also makes
it easier to handle backout of failed requests without having to maintain a
lot of client-side state, or make a lot of round-trips.
>

Based on previous experience, I highly recommend maintaining separation
between tracking work at an API call level aggregate and other "subtasks."
In non-provisioning scenarios, tasks may fire independent of API
operations, so there wouldn't be an API handle to query on. It is great to
manage per-API call level tasks in the framework. The "other work" type
tasks are *much* more complicated beasts, deserving of their own design.

>> Finally, a note on persistency. How long a completed task, successfully
or not should be stored for? Do we want to store them until the resource
they operated on is deleted?
>> I don't think it's a great idea to store them indefinitely in the DB.
Tying their lifespan to resources is probably a decent idea, but time-based
cleanup policies might also be considered (e.g.: destroy a task record 24
hours after its completion)
>
>
> I can envision an operator/user wanting to be able to pull a log of an
operation/task for not only cloud debugging (x failed to build, when/why?)
but also app-level debugging (concrete use case not ready at deadline).
This would require a minimum of life-of-resource + some-amount-of-time.
The time might also be variable, failed operations might actually need to
stick around longer.
>
> Even as an operator with access to backend logging, pulling these state
transitions out should not be hard, and should be available to the resource
owner (project).
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] PTL Non-Candidacy + Nomination

[Peter Balland]

Yes, I should have mentioned, Congress is currently a StackForge project,
but we follow many of the standard timelines and processes.  Sorry if I
caused any confusion.

- Peter

On 9/29/14, 2:28 PM, "Anita Kuno"  wrote:

>On 09/29/2014 05:20 PM, Peter Balland wrote:
>> It has been an honor to serve as the interim PTL for the Congress
>>project during Juno.  Due to other commitments I have during the Kilo
>>timeframe, I feel I would not be able to commit the time needed by the
>>growing project.  In my place, I would like to nominate Tim Hinrichs for
>>PTL of Congress.
>> 
>> Tim has been involved in the Congress project since its inception, and
>>has been serving as its chief architect.  He is very active in policy
>>research, code, and community, and has a great strategic vision for the
>>project.
>> 
>> - Peter
>> 
>> 
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>Note:
>
>Congress is not one of the programs or projects that is currently having
>elections administered by the election process governed by the tc
>charter, just to ensure readers are not confused. They can choose a
>leader as suits the members involved in Congress.
>
>Thanks,
>Anita.
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Congress] PTL Non-Candidacy + Nomination

[Peter Balland]

It has been an honor to serve as the interim PTL for the Congress project 
during Juno.  Due to other commitments I have during the Kilo timeframe, I feel 
I would not be able to commit the time needed by the growing project.  In my 
place, I would like to nominate Tim Hinrichs for PTL of Congress.

Tim has been involved in the Congress project since its inception, and has been 
serving as its chief architect.  He is very active in policy research, code, 
and community, and has a great strategic vision for the project.

- Peter

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

Re: [openstack-dev] [Congress] Nominating Aaron Rosen for congress-core

[Peter Balland]

Aaron has now been added to the congress-core group in gerrit.

Cheers,

Peter

From: Rajdeep Dua mailto:rajdeep@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, September 18, 2014 at 1:26 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: Aaron Rosen mailto:aro...@vmware.com>>
Subject: Re: [openstack-dev] [Congress] Nominating Aaron Rosen for congress-core

+1

On Fri, Sep 12, 2014 at 12:14 PM, Tim Hinrichs 
mailto:thinri...@vmware.com>> wrote:
+1

Tim

On Sep 12, 2014, at 11:47 AM, Sean Roberts 
mailto:seanrobert...@gmail.com>> wrote:

> +1
>
> ~sean
>
>> On Sep 12, 2014, at 11:28 AM, Peter Balland 
>> mailto:pball...@vmware.com>> wrote:
>>
>> Hello,
>>
>> I would like to nominate Aaron Rosen for the congress-core team.
>>
>> Aaron has been involved in congress for the last few months providing
>> valuable reviews as well as leading the keystone integration and
>> congressclient work.
>>
>> References:
>>
>> https://review.openstack.org/#/q/owner:arosen+project:+stackforge/congress,
>> n,z
>>
>> https://review.openstack.org/#/q/owner:arosen+project:+stackforge/python-co
>> ngressclient,n,z
>>
>> https://review.openstack.org/#/q/reviewer:arosen+project:+stackforge/congre
>> ss,n,z
>>
>> Please respond with +1's or any concerns.
>>
>> Thanks,
>>
>> Peter
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Congress] Nominating Aaron Rosen for congress-core

[Peter Balland]

Hello,

I would like to nominate Aaron Rosen for the congress-core team.

Aaron has been involved in congress for the last few months providing
valuable reviews as well as leading the keystone integration and
congressclient work.

References:

https://review.openstack.org/#/q/owner:arosen+project:+stackforge/congress,
n,z

https://review.openstack.org/#/q/owner:arosen+project:+stackforge/python-co
ngressclient,n,z

https://review.openstack.org/#/q/reviewer:arosen+project:+stackforge/congre
ss,n,z

Please respond with +1's or any concerns.

Thanks,

Peter


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

Re: [openstack-dev] [Congress] Help in understanding API Flow

[Peter Balland]

Hi Madhu,

If you are trying to expose data from a new service, you need to add a new 
data-source driver (examples from nova and neutron are in the tree.)  Once a 
data-source driver is registered, data from the data source will be exposed 
through the API automatically, and you will also be able to write policy based 
on the data.  (Note that using the current code in master your data source will 
not be activated until it is referenced by a policy - a commit is in flight to 
change that, however.)

If, instead, you are trying to expose non datasource data in the API, it would 
involve implementing the DataModel interface (see api/webservice.py) and 
binding it to a URI and handler in congress_server.py.  If this is what you 
want to do, please provide more details on what you are exposing and I can walk 
you through it.

- Peter

From: Madhu Mohan mailto:mmo...@mvista.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 14, 2014 at 2:54 AM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress] Help in understanding API Flow

Hi,

Can some one help me understand how an API is exposed to the clients from 
Congress server ?

I see that a cage service ('api-policy') is created in congress_server.py.
I believe this is implemented in policy_model. I tried to send a json_request 
from my client on the server.

I tried sending "list_members", "get_items", "PUT" and  "POST" as methods and 
all these give me "NotImplemented" error response.

Any help in this direction ?

I also want to add new APIs and hence understanding the API flow is crucial.

Thanks,
Madhu Mohan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] congress-server fails to start

[Peter Balland]

Hi Rajdeep,

What version of pip are you running?  Please try installing the latest version 
(https://pip.pypa.io/en/latest/installing.html) and run 'sudo pip install -r 
requirements.txt'.

- Peter

From: Rajdeep Dua mailto:rajdeep@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 11, 2014 at 11:27 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress] congress-server fails to start

Hi All,
command to start the congress-server fails

$ ./bin/congress-server --config-file etc/congress.conf.sample

Error :
ImportError: No module named keystonemiddleware.auth_token

Installing keystonemiddleware manually also fails

$ sudo pip install keystonemiddleware

Could not find a version that satisfies the requirement oslo.config>=1.4.0.0a3 
(from keystonemiddleware) (from versions: )
No distributions matching the version for oslo.config>=1.4.0.0a3 (from 
keystonemiddleware)

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

Re: [openstack-dev] [Congress]Congress API model

[Peter Balland]

Hi Madhu,

We have not yet concluded on an API port, the code currently defaults to 8080, 
but we are considering 1789.

The Congress API is built on a custom framework that encourages data models 
that follow REST conventions.  Are you interested in adding additional API 
calls?

- Peter

From: Madhu Mohan mailto:mmo...@mvista.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 31, 2014 at 7:29 AM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress]Congress API model

Hi,

I am building a congress-based demo and setting up server exposed as API. Can 
somebody clarify a couple of my questions:

1. What is the port that is planned to be used for Congress to listen to API 
calls ?
2. What is the Web Framework model that is planned to be adapted (Pecan/WSME) 
does it follow the OSAPI model from Nova ?

Thanks,
Madhu Mohan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Error running scripts/run_api_server

[Peter Balland]

Hi Madhu,

That script is a legacy holdover from a proof-of-concept done some time back.  
Since that time, we have refined the policy and API designs, and should have 
the new code ready for testing in the next couple of days.

- Peter

From: Madhu Mohan Nelemane mailto:snmoha...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, June 19, 2014 at 11:03 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress] Error running scripts/run_api_server

Hi,

I recently cloned the latest Congress source code and tried to run unit-tests 
on my Ubuntu PC. Using "scripts/run_api_server", I found this following error:


Jun 20 11:28:11|0|__main__|INFO|Starting congress server
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/eventlet/greenpool.py", line 80, in 
_spawn_n_impl
func(*args, **kwargs)
  File "server.py", line 82, in ad_update_thread
ad_model.update_from_ad()  # XXX: blocks eventlet
  File "/home/madhu/Project/policyFW/congress/congress/server/ad_sync.py", line 
72, in update_from_ad
l.simple_bind_s(BIND_USER, BIND_PW)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 206, in 
simple_bind_s
msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 200, in 
simple_bind
return 
self._ldap_call(self._l.simple_bind,who,cred,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls))
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 96, in 
_ldap_call
result = func(*args,**kwargs)
SERVER_DOWN: {'desc': "Can't contact LDAP server"}
(5065) wsgi starting up on 
http://0.0.0.0:8080/

Does other guys face this error too ?
Am i missing any prerequisite to run the congress unit-test ?

"make" was successful and had no issues.

Please suggest a way to proceed further.

Thanks and Regards,
Madhu Mohan




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

Re: [openstack-dev] [Neutron] Partially Shared Networks

[Peter Balland]

- Original Message -
> From: "PAUL CARVER" 
> To: OpenStack-dev@lists.openstack.org
> Sent: Wednesday, January 15, 2014 6:52:32 AM
> Subject: [openstack-dev] [Neutron] Partially Shared Networks
> 
> 
>
> The particular use case I have in mind concerns networks that could
> technically be created as admin and marked as shared and thus have only
> whatever network namespace considerations that apply to shared networks. The
> desire to make them "partially shared" has more to do with the UI (either
> Horizon or API access) not showing them to tenants who are not on the
> approved list and not permitting tenants who are not on the list to attach
> instances to them.
> 
> This is basically like the door list at a club. If you're not on the list you
> can't get into the club. But if you're on the list, once you're inside the
> club it's not really any different from a less exclusive club other than the
> fact that everybody inside was "on the list".
> 
> 
> --
> Paul Carver

This is one of the use cases we are considering for the "Congress" project 
(https://wiki.openstack.org/wiki/Congress).

Policy is well-suited for modeling this sort of scenario where the user wants 
to express intended behavior as a subset of the system's capabilities.  
Decoupling policy from networking facilitates expressing this intent using 
inputs across multiple systems (e.g. Neutron, Nova, Active Directory, etc).

As an example, we have a demo modeling the following use case: "Every network 
connected to a VM must be either public or private and owned by someone in the 
same group as the VM's owner."  Congress is still in the early stages, however, 
and integration with Neutron is still TBD.  If this sounds interesting, please 
send me a note.

- Peter

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

Re: [openstack-dev] Congress: an open policy framework

[Peter Balland]

I hope that you guys made it safely to Hong Kong.
We have secured an unconference session on Wednesday at 4:40 - 5:20
(SkyCity Meeting Room 2).  There will be a panel of customers and vendors,
and we are already gathering some really good feedback.
We will also be able to run a demo of what we have running.
Looking forward to the discussion.

- Peter


On Sat, Nov 2, 2013 at 9:31 PM, Tim Hinrichs  wrote:

> Hi OpenStackers,
>
> We've been working on an open policy framework for OpenStack that we're
> calling Congress.  We've been talking with OpenStack users and several of
> our partners to understand the kinds of rules and regulations they envision
> enforcing with a policy-based management framework.  Across the board they
> are interested in policies that span networking, compute, storage, etc.
>
> The idea behind Congress is to have a single policy engine that integrates
> any collection of external authentication and data stores and allows cloud
> administrators to write policies over those data stores in a rich,
> declarative language.  The policy engine can either enforce the policy
> proactively (i.e. preventing policy violations before they occur) or
> reactively (identifying violations after they occur and taking corrective
> action) or a combination (proactively when possible and reactively when
> not).  The policy engine can also interact with the administrator,
> explaining the causes of violations, computing potential remediation plans,
> and simulating action executions to understand what violations those
> actions might cause.
>
> While the project is still in the early stages, we have identified a
> grammar for the policy language, implemented a policy engine, and written a
> proof of concept integration for ActiveDirectory.  We would love to get
> participation and feedback.
>
> Code (in the midst of moving to stackforge):
> https://github.com/pballand/congress
>
> Wiki:
> https://wiki.openstack.org/wiki/Congress
>
> We'll be in Hong Kong, so if you would like to meet up to discuss please
> e-mail Peter  and Pierre .
>
> -- The Congress Team
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev