from:"Tim Hinrichs"

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

2018-01-08 Thread Tim Hinrichs

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

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

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

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

Tim

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

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

[openstack-dev] [Congress] Is it possible that congress policy do live-migration

2017-10-18 Thread Tim Hinrichs

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

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

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

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

Tim

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

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

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

2017-07-10 Thread Tim Hinrichs

Hi Valentin,

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

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

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

Tim



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

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

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

2017-06-15 Thread Tim Hinrichs

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

Tim

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

> Hi everyone,
> I wrote a congress datasource driver and its unit test for designate, but
> i got the following errors in the method test_update_from_datasource. It's
> something wrong in the translation.
> Here is the traceback:
>
>  File "congress/tests/datasources/test_designate_driver.py", line 34, in
> setUp
> self.driver = designate_driver.DesignateDriver(args=args)
>   File "congress/datasources/designate_driver.py", line 150, in __init__
> super(DesignateDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 1282, in __init__
> super(PollingDataSourceDriver, self).__init__(name, args=args)
>   File "congress/datasources/datasource_driver.py", line 324, in __init__
> self.initialize_translators()
>   File "congress/datasources/datasource_driver.py", line 1324, in
> initialize_translators
> self.register_translator(translator)
>   File "congress/datasources/datasource_driver.py", line 457, in
> register_translator
> self._validate_translator(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 389, in
> _validate_hdict_type
> self._validate_translator(subtranslator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 446, in
> _validate_translator
> self._validate_by_translation_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 428, in
> _validate_by_translation_type
> self._validate_hdict_type(translator, related_tables)
>   File "congress/datasources/datasource_driver.py", line 386, in
> _validate_hdict_type
> self.check_params(field_translator.keys(),
> AttributeError: 'str' object has no attribute 'keys'
>
> Thank you,
> Carmine
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] PTG Activities options

2017-02-07 Thread Tim Hinrichs

Hi all,

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

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

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

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

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

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

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

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

2017-01-23 Thread Tim Hinrichs

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

Tim

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

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

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

2017-01-21 Thread Tim Hinrichs

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

Python-congressclient>2.3<2.5

Or whatever the versions are.

Tim


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

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

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

2017-01-11 Thread Tim Hinrichs

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

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

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

> Hi all. While looking at the installation docs in preparation for
> scripting and testing Congress installation
> (https://bugs.launchpad.net/congress/+bug/1651928), I noticed there are
> installation instructions in two places:  1) For Users: Congress
> Introduction and Installation; and 2) For Operators: Deployment. The
> "For Users" section details Devstack as well as Standalone installation.
>
> I would like to rearrange the content: 1) move README.rst/4.1
> Devstack-install and 4.3 Debugging unit tests to to the For
> Developers/Contributing section; 2) move README.rst/4.2 Standalone
> install and 4.4 Upgrade to the For Operators/Deployment section. I think
> this  would make it easier for end users to create an installation
> script or validate an existing script.
>
> Any objections or thoughts?
>
> Thanks.
>
> --
>
> Aimee Ukasick, AT Open Source
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Magnum_driver

2016-12-12 Thread Tim Hinrichs

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

Tim

On Mon, Dec 12, 2016 at 1:12 PM Ruben <r.manganiel...@studenti.unisa.it>
wrote:

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

Re: [openstack-dev] [Congress] Magnum_driver

2016-12-12 Thread Tim Hinrichs

Hi Ruben,

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

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

Tim




On Fri, Dec 9, 2016 at 3:06 PM Ruben <r.manganiel...@studenti.unisa.it>
wrote:

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

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

2016-12-08 Thread Tim Hinrichs

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

Tim


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

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

2016-11-30 Thread Tim Hinrichs

Hi Ruben,

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

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

You can probably do

$ git rebase -i

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

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

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

$ git review

Tim

On Wed, Nov 30, 2016 at 5:23 AM Ruben <r.manganiel...@studenti.unisa.it>
wrote:

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

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-29 Thread Tim Hinrichs

Hi Ruben,

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

Tim

On Tue, Nov 29, 2016 at 4:06 AM Ruben <r.manganiel...@studenti.unisa.it>
wrote:

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

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-25 Thread Tim Hinrichs

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

Tim

On Fri, Nov 25, 2016 at 3:06 PM Ruben <r.manganiel...@studenti.unisa.it>
wrote:

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

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-25 Thread Tim Hinrichs

5 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1048, in convert_objs
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  rows, _ = DataSourceDriver.convert_obj(o, translator)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1021, in convert_obj
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  parent_row_dict)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 994, in _populate_translator_data_hdict
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  return cls._populate_hdict(translator, obj, parent_row_dict)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 924, in _populate_hdict
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  cls._get_value(obj, field, selector), extract_fn)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 693, in _get_value
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  if field in o:
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> TypeError: argument of type 'Cluster' is not iterable
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> 2016-11-24 20:56:27.435 INFO congress.datasources.datasource_driver [-]
> magnum:: finished polling
>
>
> Any suggestions to solve it?
> I've add the code to review.
>
> Ruben
>
> - Original Message -
> From: "Ruben" <r.manganiel...@studenti.unisa.it>
> To: "Tim Hinrichs" <t...@styra.com>
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Thursday, November 24, 2016 12:44:38 AM
> Subject: Re: [Congress] Magnum_driver
>
> Hi Tim,
> I already have 'pyhton-magnumclient' in the requirements.txt file, but I
> still have the error.
>
> This is the /opt/stack/congress/requirements.txt file:
>
> "# The order of packages is significant, because pip processes them in the
> order
> # of appearance. Changing the order has an impact on the overall
> integration
> # process, which may cause wedges in the gate later.
>
> Babel>=2.3.4 # BSD
> eventlet!=0.18.3,>=0.18.2 # MIT
> PuLP>=1.4.1 # MIT
> keystoneauth1>=2.14.0 # Apache-2.0
> keystonemiddleware!=4.5.0,>=4.2.0 # Apache-2.0
> Paste # MIT
> PasteDeploy>=1.5.0 # MIT
> pbr>=1.6 # Apache-2.0
> python-keystoneclient>=3.6.0 # Apache-2.0
> python-heatclient>=1.5.0 # Apache-2.0
> python-magnumclient
> python-muranoclient>=0.8.2 # Apache-2.0
> python-novaclient!=2.33.0,>=2.29.0 # Apache-2.0
> python-neutronclient>=5.1.0 # Apache-2.0
> python-ceilometerclient>=2.5.0 # Apache-2.0
> python-cinderclient!=1.7.0,!=1.7.1,>=1.6.0 # Apache-2.0
> python-swiftclient>=2.2.0 # Apache-2.0
> python-ironicclient>=1.6.0 # Apache-2.0
> alembic>=0.8.4 # MIT
> python-dateutil>=2.4.2 # BSD
> python-glanceclient>=2.5.0 # Apache-2.0
> Routes!=2.0,!=2.1,!=2.3.0,>=1.12.3;python_version=='2.7' # MIT
> Routes!=2.0,!=2.3.0,>=1.12.3;python_version!='2.7' # MIT
> six>=1.9.0 # MIT
> oslo.concurrency>=3.8.0 # Apache-2.0
> oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
> oslo.context>=2.9.0 # Apache-2.0
> oslo.db!=4.13.1,!=4.13.2,>=4.11.0 # Apache-2.0
> oslo.messaging>=5.2.0 # Apache-2.0
> oslo.policy>=1.15.0 # Apache-2.0
> oslo.serialization>=1.10.0 # Apache-2.0
> oslo.service>=1.10.0 # Apache-2.0
> oslo.utils>=3.18.0 # Apache-2.0
> oslo.middleware>=3.0.0 # Apache-2.0
> oslo.vmware>=2.11.0 # Apache-2.0
> oslo.log>=3.11.0 # Apache-2.0
> WebOb>=1.6.0 # MIT"
>
> - Original Message -
> From: "Tim Hinrichs" <t...@styra.com>
> To: "Ruben" <r.manganiel...@studenti.unisa.it>,
> openstack-dev@lists.openstack.org
> Cc: "timothy l hinrichs" <timothy.l.hinri...@gmail.com>
> Sent: Wednesday, November 23, 2016 11:44:40 PM
> Subject: Re: [Congress] Magnum_driver
>
> Ruben,
>
> All the software that gets imported by your code needs to be listed in
> requirements.txt so that when tox runs, it installs that software.  When I
> did some debugging for you I made the necessary change, so if you add that
> back into your c

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-23 Thread Tim Hinrichs

It's hard to debug that remotely.  If you add the requirements.txt file
with the magnum-client to the code you submitted to gerrit, the tests will
run on gerrit, and I can see the errors for myself.  The error message is
pretty clearly saying that the module can't be found.  Not sure what to
recommend here--maybe diff your changes with the one I pushed to gerrit for
you to see what's different?

I think that putting the python-magnumclient into the
/opt/stack/congress/requirements.tx file should work.  Then again, I don't
see python-magnumclient in that long list of installed packages.

Tim


On Wed, Nov 23, 2016 at 12:29 PM Ruben 
wrote:

> Hi everybody,
> I've trying to run the unit test of the magnum_driver.
>
> I make:
> -cd /opt/stack/congress/
> -tox -epy27
>
> but I have error with the import.
> This is the output:
>
> "py27 develop-inst-noop: /opt/stack/congress
> py27 installed:
> alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
> git+
> http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.concurrency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.policy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.6,sphinx-rtd-theme==0.1.9,SQLAlchemy==1.1.3,sqlalchemy-migrate==0.10.0,sqlparse==0.2.2,stevedore==1.18.0,suds-jurko==0.6,Tempita==0.5.2,tenacity==3.3.0,testrepository==0.0.20,testscenarios==0.5.0,testtools==2.2.0,traceback2==1.4.0,unicodecsv==0.14.1,unittest2==1.1.0,urllib3==1.19,warlock==1.2.0,WebOb==1.6.2,wrapt==1.10.8,yaql==1.1.1
> py27
>

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-23 Thread Tim Hinrichs

Ruben,

All the software that gets imported by your code needs to be listed in
requirements.txt so that when tox runs, it installs that software.  When I
did some debugging for you I made the necessary change, so if you add that
back into your change, that error should disappear.

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

Tim


On Wed, Nov 23, 2016 at 12:29 PM Ruben 
wrote:

> Hi everybody,
> I've trying to run the unit test of the magnum_driver.
>
> I make:
> -cd /opt/stack/congress/
> -tox -epy27
>
> but I have error with the import.
> This is the output:
>
> "py27 develop-inst-noop: /opt/stack/congress
> py27 installed:
> alabaster==0.7.9,alembic==0.8.8,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.0,Babel==2.3.4,cachetools==2.0.0,cffi==1.9.1,cliff==2.2.0,cmd2==0.6.9,-e
> git+
> http://git.openstack.org/openstack/congress@b2d96b56f721c941e85db565d203df008c455b19#egg=congress,contextlib2==0.5.4,coverage==4.2,cryptography==1.5.3,debtcollector==1.9.0,decorator==4.0.10,docutils==0.12,dogpile.cache==0.6.2,enum34==1.1.6,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.2.4,funcsigs==1.0.2,functools32==3.2.3.post2,futures==3.0.5,futurist==0.19.0,greenlet==0.4.10,hacking==0.10.2,idna==2.1,ipaddress==1.0.17,iso8601==0.1.11,Jinja2==2.8,jsonpatch==1.14,jsonpointer==1.10,jsonschema==2.5.1,keystoneauth1==2.15.0,keystonemiddleware==4.10.0,kombu==3.0.37,linecache2==1.0.0,lxml==3.6.4,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.18.0,msgpack-python==0.4.8,netaddr==0.7.18,netifaces==0.10.5,openstacksdk==0.9.9,os-client-config==1.22.0,osc-lib==1.2.0,oslo.concurrency==3.15.0,oslo.config==3.19.0,oslo.context==2.10.0,oslo.db==4.14.0,oslo.i18n==3.10.0,oslo.log==3.17.0,oslo.messaging==5.12.0,oslo.middleware==3.20.0,oslo.policy==1.16.0,oslo.serialization==2.14.0,oslo.service==1.17.0,oslo.utils==3.18.0,oslo.vmware==2.15.0,oslosphinx==4.8.0,oslotest==2.11.0,Paste==2.0.3,PasteDeploy==1.5.2,pbr==1.10.0,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,ply==3.9,positional==1.1.1,prettytable==0.7.2,PuLP==1.6.1,pyasn1==0.1.9,pycadf==2.4.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.1.3,pyinotify==0.9.6,pyOpenSSL==16.2.0,pyparsing==1.5.7,python-ceilometerclient==2.7.0,python-cinderclient==1.9.0,python-dateutil==2.6.0,python-editor==1.0.1,python-glanceclient==2.5.0,python-heatclient==1.5.0,python-ironicclient==1.8.0,python-keystoneclient==3.6.0,python-mimeparse==1.6.0,python-muranoclient==0.11.1,python-neutronclient==6.0.0,python-novaclient==6.0.0,python-openstackclient==3.3.0,python-subunit==1.2.0,python-swiftclient==3.1.0,pytz==2016.7,PyYAML==3.12,reno==1.8.0,repoze.lru==0.6,requests==2.11.1,requests-mock==1.1.0,requestsexceptions==1.1.3,retrying==1.3.3,rfc3986==0.4.1,Routes==2.3.1,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.6,sphinx-rtd-theme==0.1.9,SQLAlchemy==1.1.3,sqlalchemy-migrate==0.10.0,sqlparse==0.2.2,stevedore==1.18.0,suds-jurko==0.6,Tempita==0.5.2,tenacity==3.3.0,testrepository==0.0.20,testscenarios==0.5.0,testtools==2.2.0,traceback2==1.4.0,unicodecsv==0.14.1,unittest2==1.1.0,urllib3==1.19,warlock==1.2.0,WebOb==1.6.2,wrapt==1.10.8,yaql==1.1.1
> py27
>

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-16 Thread Tim Hinrichs

Hi Ruben,

The fieldnames you care about are the fields as they show up in the JSON
that gets returned from the magnum-client methods inside the datasource
driver, e.g. from these methods...

self.magnum.cluster_template.list()
self.magnum.cluster.list()

Several ways to check that you have the right fields..
1) Suppose your Murano driver is running inside of Congress, and you've
created an instance of it.
$ openstack congress datasource create magnum magnum ...
$ openstack congress datasource list

You know you have the right fields in the driver if you're getting data in
the Murano datasource instance.
$ openstack congress datasource row list magnum cluster
$ openstack congress datasource row list magnum cluster_template

2) If that doesn't work, check what JSON data magnum is returning on the
CLI by adding the --debug parameter to the magnum CLI commands.
[I haven't used magnum's client, but it looks to be using the standard
openstack client, so should support --debug.]

$ magnum cluster-template-list --debug

You'll need to wade through the output to find the JSON that gets returned
from the server.

3) If you think you have the right field names in the congress translators,
but you're still not seeing data in the Murano datasource instance, you'll
probably want to look at the congress logs. It looks like you have the
right log.DEBUG statements in there.  One trick is to disable all the
datasources in congress other than your own to minimize the logs you need
to look through.  Another is to change your log.DEBUG to log.WARNING
temporarily so your messages show up more clearly in the log.

You can look at logs from the command line with:
$ less -R /opt/stack/logs/congress.log

Or go into 'screen -x', go to the Congress window, and look at the output
in real time.  You'll want a tutorial on screen if you haven't used it.

Tim

On Wed, Nov 16, 2016 at 9:37 AM Ruben 
wrote:

> Hi everybody,
> first of all: Tim thanks for your help.
>
> I've read the code in
> python-magnumclient/magnumclient/v1/cluster_templates_shell.py and in
> python-magnumclient/magnumclient/v1/clusters_shell.py, so I've modify the
> translators in the magnum_driver according to
> _show_cluster_template(cluster_template) and _show_cluster(cluster) methods
> shown in these files.
> Are these the methods to be taken into account for the translation?
> Anyway I don't know if I made mistakes in the translation..
>
> I've some doubts because if I made the CLI command 'magnum
> cluster-template-list' I have:
>
> +--+--+
> | uuid | name |
> +--+--+
> | 8d25a1ed-faa6-4305-a6a1-6559708c805b | k8s-cluster-template |
> +--+--+
>
> and if I made the CLI command 'magnum cluster-template-show
> k8s-cluster-template' I have:
>
> +---+--+
> | Property  | Value|
> +---+--+
> | insecure_registry | -|
> | labels| {}   |
> | updated_at| -|
> | floating_ip_enabled   | True |
> | fixed_subnet  | -|
> | master_flavor_id  | my   |
> | uuid  | 8d25a1ed-faa6-4305-a6a1-6559708c805b |
> | no_proxy  | -|
> | https_proxy   | -|
> | tls_disabled  | False|
> | keypair_id| testkey  |
> | public| False|
> | http_proxy| -|
> | docker_volume_size| 7|
> | server_type   | vm   |
> | external_network_id   | public   |
> | cluster_distro| fedora-atomic|
> | image_id  | fedora-atomic-latest |
> | volume_driver | -|
> | registry_enabled  | False|
> | docker_storage_driver | devicemapper |
> | apiserver_port| -|
> | name  | k8s-cluster-template |
> | created_at| 2016-11-11T11:38:25+00:00|
> | network_driver| flannel  |
> | fixed_network | -|
> | coe   | kubernetes   |
> |

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-15 Thread Tim Hinrichs

Hi Ruben,

Did a little debugging for you...

1) Run your unit tests
$ tox -epy34 congress.tests.datasources.test_magnum
...
  File
"/Users/tim/opencode/congress/congress/tests/datasources/test_magnum_driver.py",
line 3, in 
from congress.datasources import magnum_driver
  File
"/Users/tim/opencode/congress/congress/datasources/magnum_driver.py", line
51
self.magnum = magnum_client.Client(session=session)
^
IndentationError: unexpected indent

The IndenetationError says you haven't lined up the code correctly.  Python
is sensitive to whitespace.  I fixed this.

2) Run unit tests again.
$ tox -epy34 congress.tests.datasources.test_magnum
..
  File
"/Users/tim/opencode/congress/congress/datasources/magnum_driver.py", line
1, in 
from magnumclient import client as magnum_client

Here the problem is that the package magnumclient doesn't exist.  You need
to add the python-magnumclient to the file requirements.txt.
I fixed this for you as well.

3) Run unit tests again
$ tox -epy34 congress.tests.datasources.test_magnum

Forgot to capture the output this time, but there was a test failure.  I
went ahead and uncommented the two translators that you wrote
because they seemed to be doing the right thing; that required combining
your two unit tests into 1.

4) Run unit tests again
$ tox -epy34 congress.tests.datasources.test_magnum

Traceback (most recent call last):
  File
"/Users/tim/opencode/congress/congress/tests/datasources/test_magnum_driver.py",
line 97, in test_cluster_template_update_from_datasource
self.assertEqual(self.driver.state, expected)
  File
"/Users/tim/opencode/congress/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
  File
"/Users/tim/opencode/congress/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'cluster': {('None', 'k8s-cluster', 'None', 1, 1,
'CREATE_FAILED')},
 'cluster_template': {('None', 'k8s-cluster-template', 'None', 'None')}}
reference = {'cluster': {('f88cb9c7-1e5d-42cb-b0dc-d9c3d0872ddf',
  'k8s-cluster',
  'testkey',
  1,
  1,
  'CREATE_FAILED')},
 'cluster_template': {('3ddeaf4f-af3d-4534-9558-59bf28b1578b',
   'k8s-cluster-template',
   'kubernetes',
   'flannel')}}
actual= {'cluster': {('None', 'k8s-cluster', 'None', 1, 1,
'CREATE_FAILED')},
 'cluster_template': {('None', 'k8s-cluster-template', 'None', 'None')}}

What's happening here is that the output of the translator does not match
what the test says the output should be.  The problem is that there's a
mismatch between the keys in the data that you've mocked out (e.g.
mock_cluster_template) and the fieldnames in the translator (e.g.
cluster_template_translator).

In the translator below you say the field names are 'id', 'name', 'COE',
and 'Network_driver'.  In the data you mocked out, the closest field names
I can see are 'uuid', 'name', 'coe', and 'network_driver'.  So fieldname
'name' matches the mocked out data, but the other field names do not.
 (Field names are case sensitive.)  So if you change it so the fieldnames
and the mock-data match, your unit test should pass.

cluster_template_translator = {
'translation-type': 'HDICT',
'table-name': CLUSTER_TEMPLATE,
'selector-type': 'DICT_SELECTOR',
'field-translators':
  ({'fieldname': 'id', 'translator': value_trans},
   {'fieldname': 'name', 'translator': value_trans},
   {'fieldname': 'COE', 'translator': value_trans},
   {'fieldname': 'Network_driver', 'translator': value_trans})}

5) Of course, just because the unit tests pass doesn't mean the driver is
correct.  The translator fieldnames need to match the actual data that
magnum returns when you ask for the clusters and cluster_templates.  One
option is to read through the python-magnumclient code to see what fields
it returns; the other is to run the commands yourself from the commandline
to see what they return; another is to look at the Congress logs when the
magnum driver is running (with debug=True in /etc/congress/congress.conf).

6) I pushed all my changes as a revision on top of one of your commits.  We
always include the code and the unit tests as one commit.  So now there's 1
commit that you can download to your local machine and continue editing.
Or you can just look at the code in gerrit and make changes to your code
manually.

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

To download, the safest thing is to create a new branch and apply the
changes on top of that branch.You can also skip the 'git checkout' step
if you want to apply the changes on top of the ones you already have,
resolve conflicts, and then squash all the commits together.
$ cd /path/to/congress
$ git checkout origin/master

Re: [openstack-dev] [Congress] Error datasource create

2016-11-08 Thread Tim Hinrichs

Here's the pertinent error.  It looks like you have a typo in one of your
translators.

2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node InvalidParamException:
Params (field_translators, selector_type) are invalid.  Valid params:
('translation-type', 'table-name', 'parent-key', 'id-col', 'selector-type',
'field-translators', 'in-list', 'parent-col-name', 'objects-extract-fn',
'parent-key-desc')


If you push your Magnum datasource code to review, we can help you more
easily.  Let us know if you need help doing that.  Here's the quickstart
guide.
http://docs.openstack.org/contributor-guide/quickstart/first-timers.html

There are 2 kinds of testing you can do.

1. Run congress and magnum using Devstack (as it seems you're doing).
Manually add a couple of objects to Magnum and manually check that those
objects are showing up in Congress.

2. You can run unit tests on a Linux box with the following commands.
$ cd /path/to/congress
$ tox

You can run specific tests with ...
$ tox -epy34  // just run the Python34 tests
$ tox -epy34 congress.tests.datasources // just run the tests in the
congress/tests/datasources directory
$ tox -epy34 congress.tests.datasources.glancev2_driver  // just run the
tests in the file test_glancev2_driver.py
$ tox -epy34
congress.tests.datasources.glancev2_driver.test_update_from_datasource   //
just run the test_update_from_datasource test

Tim


On Tue, Nov 8, 2016 at 3:26 AM Ruben 
wrote:

> Hi everybody,
> really, I've not been able to create the datasource for magnum.
> Now, I've seen that I've these errors when I restart the congress server..
>
> "ERROR congress.dse2.dse_node [-] Error loading instance of module
> 'congress.datasources.magnum_driver.MagnumDriver'
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node Traceback (most
> recent call last):
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/dse2/dse_node.py", line 841, in
> create_datasource_service
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node service =
> getattr(module, class_name)(**kwargs)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/magnum_driver.py", line 49, in
> __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  super(MagnumDriver, self).__init__(name, args=args)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1282,
> in __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  super(PollingDataSourceDriver, self).__init__(name, args=args)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 324,
> in __init__
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self.initialize_translators()
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1324,
> in initialize_translators
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self.register_translator(translator)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 457,
> in register_translator
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._validate_translator(translator, related_tables)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 446,
> in _validate_translator
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._validate_by_translation_type(translator, related_tables)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 415,
> in _validate_by_translation_type
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
>  self._get_translator_params(translation_type))
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node   File
> "/opt/stack/congress/congress/datasources/datasource_driver.py", line 1066,
> in check_params
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node raise
> exception.InvalidParamException(err)
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
> InvalidParamException: Params (field_translators, selector_type) are
> invalid.  Valid params: ('translation-type', 'table-name', 'parent-key',
> 'id-col', 'selector-type', 'field-translators', 'in-list',
> 'parent-col-name', 'objects-extract-fn', 'parent-key-desc')
> 2016-11-08 12:15:29.906 TRACE congress.dse2.dse_node
> 2016-11-08 12:15:29.911 ERROR congress.harness [-] datasource magnum
> creation failed.
> 2016-11-08 12:15:29.911 TRACE congress.harness Traceback (most recent call
> last):
> 2016-11-08 12:15:29.911 TRACE congress.harness   File
> "/opt/stack/congress/congress/harness.py", line 167, in create_datasources
> 2016-11-08 12:15:29.911 TRACE congress.harness

[openstack-dev] [Congress] Fwd: Your draft logo & sneak peek

2016-10-21 Thread Tim Hinrichs

Hi team,
I just received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready for
us before the Project Team Gathering in February. Before they make our logo
final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is
due Friday, Nov. 11. To get a sense of how ours stacks up to others, check
out this sneak preview of several dozen draft logos from our community:
https://youtu.be/JmMTCWyY8Y4

[image: Congress.png]
__
OpenStack Development Mailing 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] Project for Ruben

2016-10-10 Thread Tim Hinrichs

Hi Ruben,

It's great that you've decided to add a datasource driver for Magnum.  A
datasource driver is a good place to start.

In terms of getting started, if you haven't read thru the docs, start
there.  The Cloud Services section will give you info on datasources; at
the end there is a section on Writing a Datasource driver.  The Policy
section will explain the policy language.
http://docs.openstack.org/developer/congress/

As mentioned below, Eric suggests the Monasca datasource to be a recent one
to use as an example.  The docs use Glance.

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] [release][congress][searchlight] projects in danger of being left out of newton

2016-09-19 Thread Tim Hinrichs

Congress tagged RC1 on Friday.

Tim

On Mon, Sep 19, 2016 at 7:52 AM Nikhil Komawar 
wrote:

> I think searchlight went right ahead into 1.0.0 so, I doubt if we will
> have rc1. (this is just initial info, I will defer the details to the
> project lead).
>
>
>
> On 9/19/16 9:55 AM, Doug Hellmann wrote:
> > We have not had RC1 tags for congress or searchlight, and the project
> > leads aren't responding on IRC. These projects are at risk of being
> > left out of the newton release. Someone from the core teams for
> > these projects should get in touch with the release team as soon
> > as possible to let us know your plans.
> >
> > 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
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> OpenStack Development Mailing 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] Default devstack deployment config

2016-09-12 Thread Tim Hinrichs

I'd agree with a single process version of Congress for devstack.  I'd say
we should even do that for Newton.

Tim

On Mon, Sep 12, 2016 at 6:34 PM Eric K  wrote:

> Hi all,
>
> I want to get people’s thoughts regarding what we should set as default
> devstack deployment config for Ocata.
> At the moment, it is set to deploy three processes: API, policy, and
> datasource-drivers.
>
> I see some potential arguments against that:
>
>1. For most users installing via devstack, running Congress in three
>processes bring little benefit, but rather a more complex and less stable
>user experience. (Even if our code is perfect, rabbitMQ will timeout every
>now and then)
>2. It’s not clear that we want to officially support separating the
>API from the policy engine at this point. The supported deployment options
>for HAHT do not need it.
>
> The main argument I see for deploying three processes by default is that
> we may get more bug reports regarding the multi-process deployment that way.
>
> Our main options for devstack default are:
> 1. Single-process Congress (with in-mem transport).
> 2. Two-process Congress API+Policy, datasource-drivers. (other breakdowns
> between two processes are also possible)
> 3. Three-process Congress.
>
> In the end, I think it’s a trade-off: potentially getting more bug reports
> from users, at the expense of a more complex and less polished user
> experience that could make a poor first impression. What does everyone
> think?
>
> Personally, I slightly favor defaulting to single process Congress because
> from a typical devstack user’s perspective, there is little reason to run
> separate processes. In addition, because it is the first time we’re
> releasing our complete architecture overhaul to the wild, and it may be a
> good to default to the least complex deployment for the first cycle of the
> new architecture.
> __
> OpenStack Development Mailing 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] PTL non-candidacy

2016-09-12 Thread Tim Hinrichs

Hi all,

I've decided it's time to step down as PTL of Congress.  Partly because I
have so many outside responsibilities, and partly because we have such a
strong team, the time is right for someone else to lead the project.  We've
made so much progress over the past couple of years, and there's so much
left to do.  I'm truly excited to see someone's ideas for setting direction
and interacting with the community.  Should be a ton of fun!

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] Stack trace returned to end user bug

2016-09-11 Thread Tim Hinrichs

The Api node on Oslo-messaging sends a request to the policy node asking
for say policy alpha. The policy node raises an exception, which Oslo
returns to the API node. I'd imagine there is some way to have the Ali node
extract the original exception or tell Oslo to return the only the original
exception.

Tim
On Thu, Sep 8, 2016 at 2:04 PM Aimee Ukasick 
wrote:

> All --
>
> https://bugs.launchpad.net/congress/+bug/1620868
>
> I stepped through the code with the pdb. I can't find anything wrong
> in the CongressException
> code.
>
> The traceback is being added by oslo_messaging/rpc/server.py  in
> _process_incoming
> This call that is throwing an exception: res =
> self.dispatcher.dispatch(message) but I haven't
> determined why.
>
> https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/server.py#L134
>
> https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/server.py#L142
>
> console output here:  http://paste.openstack.org/show/569334/
>
>
> I can't figure out why oslo.messaging is throwing an exception, I
> assume I should go into the API and CLI cod and prevent the traceback
> from being displayed.
>
> Thoughts? Suggestions? Epiphanies?
>
> aimee
>
> __
> OpenStack Development Mailing 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] Enabling Remote Debugging

2016-09-02 Thread Tim Hinrichs

I'd be concerned about merging a change to eventlet this late in the
cycle.  Threading problems are notoriously difficult to find during
testing.  I'd recommend pushing the patch to Gerrit, so that we can all try
it out when debugging, and we check it in after the Newton release.

Eric, +1 to your general advice.

I wouldn't expect a blueprint or even a bug for a code-change that only
impacts developers, unless you want to socialize the idea before writing
the code or the code is substantial.  If writing the code is small and
easy, and no one will have much to say before seeing that code, I'd just
push a patch to gerrit and see what people think.

Tim


On Fri, Sep 2, 2016 at 2:31 AM Masahito MUROI 
wrote:

> Hi Aimee,
>
> Thanks let us know.
>
> I don't think it has a big impact to the current architecture and
> user/dev. So it seems to be good to report it as a bug and target the
> fix to N-release.
>
> best regards,
> Masahito
>
> On 2016/09/02 10:10, Eric K wrote:
> > Hi Aimee,
> >
> > Thanks for digging into it!
> >
> > Here¹s my understanding of our conventions (and I¹m happy to hear from
> > others).
> >
> > a. If you think it¹s just a straightforward change with zero to minimal
> > impact on architecture, users, and devs, then it makes sense to file a
> bug
> > or just submit a patch.
> > b. If you think it warrants deeper discussion in terms of design, impact,
> > etc., then the process is to create a spec and associated blueprint. See
> > this wiki for more details:
> > https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
> >
> > In case (b), the change should target the O-cycle because we¹re past
> > feature-freeze in N.
> > In case (a), it may make sense to get it in during the N-cycle if it has
> > minimal impact and will help us in the N-cycle QA process.
> >
> > My guess is we¹re in case (a) because we can make sure changes have no
> > impact without a special flag. But I¹d also like to understand a little
> > better the impact of eventlet.monkey_patch(thread=False) as done in the
> > Keystone patch (
> https://review.openstack.org/#/c/18404/3/bin/keystone-all).
> >
> > Enjoy the time holidays!
> >
> > On 9/1/16, 11:45 AM, "Aimee Ukasick" 
> wrote:
> >
> >> HI all - I've been trying to configure remote debugging with PyCharm
> >> and DevStack. It looks like some tiny modifications need to be made to
> >> the Congress code (3-4 files) to support remote debugging via pydevd.
> >>
> >> As far as I can tell, support has been added to Keystone, Glance,
> >> Nova, and Manilla (and I'm sure others).
> >>
> >> Keystone patch: https://review.openstack.org/#/c/18404/3
> >> Glance patch: https://review.openstack.org/#/c/18748/5
> >>
> >> I think it would be very beneficial to support remote debugging, and
> >> I'm willing to implement the changes needed. Should I create a bug for
> >> this or draft a blueprint?
> >>
> >> I'm out of office 2-5 Sept for the US Labor Day holiday, so I could
> >> start on this on 6 Sept.
> >>
> >> As always, I appreciate all your comments.
> >>
> >> Thanks.
> >>
> >> aimee
> >>
> >> irc:aimeeu
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> >
> >
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] python-client push bug?

2016-08-31 Thread Tim Hinrichs

Hi all,

As I was sanity checking the latest python-client, which we need to release
by tomorrow, I may have found a bug that we should fix before releasing.
If it's a bug in the server, that can be fixed later, but if it's a bug in
the client, we should get that fixed now.

https://bugs.launchpad.net/congress/+bug/1619065

Masahito: could you double-check that I'm running the right commands in the
client?

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 horizon plugin - congressclient/congress API auth issue - help

2016-07-28 Thread Tim Hinrichs

gt; doesn't support identity v3.
> >> I thought it did, but then I came across this:
> >> "support keystone v3 api and session based authentication "
> >> https://bugs.launchpad.net/python-congressclient/+bug/1564361
> >> This is currently assigned to Anusha.
> >> I'd like to start work on it since I am becoming familiar with keystone
> >> v3.
> >>
> >> Thoughts?
> >>
> >> aimee
> >>
> >>
> >>
> >>
> >> On Fri, Jul 22, 2016 at 8:07 AM, Aimee Ukasick
> >> <aimeeu.opensou...@gmail.com> wrote:
> >> > Thanks Anusha! I will retest this today. I guess I need to learn more
> >> > about Horizon as well - thanks for pointing me in the right direction.
> >> >
> >> > aimee
> >> >
> >> >
> >> >
> >> > On Fri, Jul 22, 2016 at 6:30 AM, Anusha Ramineni
> >> > <anusha.ii...@gmail.com> wrote:
> >> >> Hi Aimee,
> >> >>
> >> >> I think devstack by default configured horizon to use v3 .
> >> >> For V2 authentication, from the logs , auth_url doesn't seem to be
> set
> >> >> explicitly to v2 auth_url .
> >> >>
> >> >> I have always set explicit v2 auth which worked fine.
> >> >> For eg:- auth_url = 'http://:5000/v2.0' , for V2
> >> >> authentication
> >> >>
> >> >> I have raised a patch, to take the auth_url from horizon settings
> >> >> instead of
> >> >> from request.
> >> >> https://review.openstack.org/#/c/345828/1
> >> >>
> >> >> Please set explict v2 auth_url as mentioned above in
> >> >> OPENSTACK_KESYTONE_URL
> >> >> in /openstack_dashboard/local/local_settings.py and restart
> >> >> apache2
> >> >> server . Then v2 authentication should go through fine.
> >> >>
> >> >> For v3 , need to add relevant code for v3 authentication in
> >> >> contrib/horizon
> >> >> as presently it is hardcoded to use only v2. but yes, the code from
> >> >> plugin
> >> >> model patch is still a WIP , so doesn't work for v3 authentication I
> >> >> guess
> >> >> I'll have a look at it and let you know .
> >> >>
> >> >>
> >> >> Best Regards,
> >> >> Anusha
> >> >>
> >> >> On 21 July 2016 at 21:56, Tim Hinrichs <t...@styra.com> wrote:
> >> >>>
> >> >>> So clearly an authentication problem then.
> >> >>>
> >> >>> Anusha, do you have any ideas?  (Aimee, I think Anusha has worked
> with
> >> >>> Keystone authentication most recently, so she's your best bet.)
> >> >>>
> >> >>> Tim
> >> >>>
> >> >>> On Thu, Jul 21, 2016 at 8:59 AM Aimee Ukasick
> >> >>> <aimeeu.opensou...@gmail.com> wrote:
> >> >>>>
> >> >>>> The  Policy/Data Sources web page throws the same errors. I am
> >> >>>> planning to recheck direct API calls using v3 auth today or
> tomorrow.
> >> >>>>
> >> >>>> aimee
> >> >>>>
> >> >>>> On Thu, Jul 21, 2016 at 10:49 AM, Tim Hinrichs <t...@styra.com>
> wrote:
> >> >>>> > Hi Aimee,
> >> >>>> >
> >> >>>> > Do the other APIs work?  That is, is it a general problem
> >> >>>> > authenticating, or
> >> >>>> > is the problem limited to list_policies?
> >> >>>> >
> >> >>>> > Tim
> >> >>>> >
> >> >>>> > On Wed, Jul 20, 2016 at 3:54 PM Aimee Ukasick
> >> >>>> > <aimeeu.opensou...@gmail.com>
> >> >>>> > wrote:
> >> >>>> >>
> >> >>>> >> Hi all,
> >> >>>> >>
> >> >>>> >> I've been working on Policy UI (Horizon): Unable to get policies
> >> >>>> >> list (devstack) (
> https://bugs.launchpad.net/congress/+bug/1602837)
> >> >>>> >> for the past 3 days. Anusha is correct - it's an authentication
> >> >>>> >> problem, but I have not been able to fix it.
> >> >>

Re: [openstack-dev] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

2016-07-21 Thread Tim Hinrichs

So clearly an authentication problem then.

Anusha, do you have any ideas?  (Aimee, I think Anusha has worked with
Keystone authentication most recently, so she's your best bet.)

Tim

On Thu, Jul 21, 2016 at 8:59 AM Aimee Ukasick <aimeeu.opensou...@gmail.com>
wrote:

> The  Policy/Data Sources web page throws the same errors. I am
> planning to recheck direct API calls using v3 auth today or tomorrow.
>
> aimee
>
> On Thu, Jul 21, 2016 at 10:49 AM, Tim Hinrichs <t...@styra.com> wrote:
> > Hi Aimee,
> >
> > Do the other APIs work?  That is, is it a general problem
> authenticating, or
> > is the problem limited to list_policies?
> >
> > Tim
> >
> > On Wed, Jul 20, 2016 at 3:54 PM Aimee Ukasick <
> aimeeu.opensou...@gmail.com>
> > wrote:
> >>
> >> Hi all,
> >>
> >> I've been working on Policy UI (Horizon): Unable to get policies
> >> list (devstack) (https://bugs.launchpad.net/congress/+bug/1602837)
> >> for the past 3 days. Anusha is correct - it's an authentication
> >> problem, but I have not been able to fix it.
> >>
> >> I grabbed the relevant code in congress.py from Anusha's horizon
> >> plugin model patchset (https://review.openstack.org/#/c/305063/3) and
> >> added try/catch blocks, logging statements (with error because I
> >> haven't figured out how to set the horizon log level).
> >>
> >>
> >> I am testing the code on devstack, which I cloned on 19 July 2016.
> >>
> >> With both v2 and v3 auth, congressclient.v1.client is created.
> >> The failure happens trying to call
> >> congressclient.v1.client.Client.list_policies().
> >> When using v2 auth, the error message is "Unable to get policies list:
> >> The resource could not be found"
> >> When using v3 auth, the error message is "Cannot authorize API client"
> >>
> >> I am assuming that congressclient.v1.client.Client is
> >>
> >>
> https://github.com/openstack/python-congressclient/blob/master/congressclient/v1/client.py
> >> and that client.list_policy() calls list_policy()in the
> >> python-congressclient
> >> which in turn calls the Congress API. Is this correct?
> >>
> >> Any ideas why with v3 auth, the python-congressclient cannot authorize
> the
> >> call to the API?
> >>
> >> I looked at other horizon plugin models (ceilometer, neutron, nova,
> >> cerberus, cloudkitty, trove, designate, manila) to see how they created
> >> the client. While the code to create a client is not identical,
> >> it is vastly different from the code to create a client
> >> in contrib/horizon/congress.py.
> >>
> >> Thanks in advance for any pointers.
> >>
> >> aimee
> >>
> >> Aimee Ukasick (aimeeu)
> >>
> >> v2 log:
> >> 2016-07-20 22:13:56.501455
> >> 2016-07-20 22:14:30.238233 * view.get_data calling policies =
> >> congress.policies_list(self.request) *
> >> 2016-07-20 22:14:30.238318 * self.request.path=
> >> /dashboard/admin/policies/
> >> 2016-07-20 22:14:30.238352 * congress.policies_list(request)
> >> BEGIN*
> >> 2016-07-20 22:14:30.238376 * calling client =
> >> congressclient(request)*
> >> 2016-07-20 22:14:30.238399 * congress.congressclient BEGIN*
> >> 2016-07-20 22:14:30.238454 * auth_url=
> http://192.168.56.103/identity
> >> 2016-07-20 22:14:30.238479 * calling get_keystone_session *
> >> 2016-07-20 22:14:30.238505 * congress.get_keystone_session BEGIN
> >> auth_url *http://192.168.56.103/identity
> >> 2016-07-20 22:14:30.238554 * path= /identity
> >> 2016-07-20 22:14:30.238578 * using V2 plugin to authenticate*
> >> 2016-07-20 22:14:30.238630 * v2 auth.get_auth_state=
> >> 2016-07-20 22:14:30.238656 None
> >> 2016-07-20 22:14:30.238677 * finished using V2 plugin to
> >> authenticate*
> >> 2016-07-20 22:14:30.238698 * creating session with auth *
> >> 2016-07-20 22:14:30.244407 * congress.get_keystone_session END*
> >> 2016-07-20 22:14:30.244462 * regtion_name= RegionOne
> >> 2016-07-20 22:14:30.244491 * calling
> congress_client.Client(**kwargs)
> >> 2016-07-20 22:14:30.247830 * congress.congressclient END*
> >> 2016-07-20 22:14:30.247902 * calling policies_list =
> >> client.list_policy()*
> >> 2016-07-20 22:14:30.248012 DEBUG:keystoneauth

Re: [openstack-dev] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

2016-07-21 Thread Tim Hinrichs

Hi Aimee,

Do the other APIs work?  That is, is it a general problem authenticating,
or is the problem limited to list_policies?

Tim

On Wed, Jul 20, 2016 at 3:54 PM Aimee Ukasick 
wrote:

> Hi all,
>
> I've been working on Policy UI (Horizon): Unable to get policies
> list (devstack) (https://bugs.launchpad.net/congress/+bug/1602837)
> for the past 3 days. Anusha is correct - it's an authentication
> problem, but I have not been able to fix it.
>
> I grabbed the relevant code in congress.py from Anusha's horizon
> plugin model patchset (https://review.openstack.org/#/c/305063/3) and
> added try/catch blocks, logging statements (with error because I
> haven't figured out how to set the horizon log level).
>
>
> I am testing the code on devstack, which I cloned on 19 July 2016.
>
> With both v2 and v3 auth, congressclient.v1.client is created.
> The failure happens trying to call
> congressclient.v1.client.Client.list_policies().
> When using v2 auth, the error message is "Unable to get policies list:
> The resource could not be found"
> When using v3 auth, the error message is "Cannot authorize API client"
>
> I am assuming that congressclient.v1.client.Client is
>
> https://github.com/openstack/python-congressclient/blob/master/congressclient/v1/client.py
> and that client.list_policy() calls list_policy()in the
> python-congressclient
> which in turn calls the Congress API. Is this correct?
>
> Any ideas why with v3 auth, the python-congressclient cannot authorize the
> call to the API?
>
> I looked at other horizon plugin models (ceilometer, neutron, nova,
> cerberus, cloudkitty, trove, designate, manila) to see how they created
> the client. While the code to create a client is not identical,
> it is vastly different from the code to create a client
> in contrib/horizon/congress.py.
>
> Thanks in advance for any pointers.
>
> aimee
>
> Aimee Ukasick (aimeeu)
>
> v2 log:
> 2016-07-20 22:13:56.501455
> 2016-07-20 22:14:30.238233 * view.get_data calling policies =
> congress.policies_list(self.request) *
> 2016-07-20 22:14:30.238318 * self.request.path=
> /dashboard/admin/policies/
> 2016-07-20 22:14:30.238352 * congress.policies_list(request) BEGIN*
> 2016-07-20 22:14:30.238376 * calling client =
> congressclient(request)*
> 2016-07-20 22:14:30.238399 * congress.congressclient BEGIN*
> 2016-07-20 22:14:30.238454 * auth_url= http://192.168.56.103/identity
> 2016-07-20  22:14:30.238479
> * calling get_keystone_session *
> 2016-07-20 22:14:30.238505 * congress.get_keystone_session BEGIN
> auth_url *http://192.168.56.103/identity
> 2016-07-20 22:14:30.238554 * path= /identity
> 2016-07-20 22:14:30.238578 * using V2 plugin to authenticate*
> 2016-07-20 22:14:30.238630 * v2 auth.get_auth_state=
> 2016-07-20 22:14:30.238656 None
> 2016-07-20 22:14:30.238677 * finished using V2 plugin to
> authenticate*
> 2016-07-20 22:14:30.238698 * creating session with auth *
> 2016-07-20 22:14:30.244407 * congress.get_keystone_session END*
> 2016-07-20 22:14:30.244462 * regtion_name= RegionOne
> 2016-07-20 22:14:30.244491 * calling congress_client.Client(**kwargs)
> 2016-07-20 22:14:30.247830 * congress.congressclient END*
> 2016-07-20 22:14:30.247902 * calling policies_list =
> client.list_policy()*
> 2016-07-20 22:14:30.248012 DEBUG:keystoneauth.identity.v2:Making
> authentication request to http://192.168.56.103/identity/tokens
> 2016-07-20 22:14:30.255023 DEBUG:keystoneauth.session:Request returned
> failure status: 404
> 2016-07-20 22:14:30.257546 Unable to get policies list: The resource
> could not be found.
>
>
> v3 log:
> 2016-07-20 22:09:22.912969
> 2016-07-20 22:09:31.907119 * view.get_data calling policies =
> congress.policies_list(self.request) *
> 2016-07-20 22:09:31.907973 * self.request.path=
> /dashboard/admin/policies/
> 2016-07-20 22:09:31.908122 * congress.policies_list(request) BEGIN*
> 2016-07-20 22:09:31.908250 * calling client =
> congressclient(request)*
> 2016-07-20 22:09:31.908386 * congress.congressclient BEGIN*
> 2016-07-20 22:09:31.909034 * auth_url= http://192.168.56.103/identity
> 2016-07-20  22:09:31.909217
> * calling get_keystone_session *
> 2016-07-20 22:09:31.909356 * congress.get_keystone_session BEGIN
> auth_url *http://192.168.56.103/identity
> 2016-07-20 22:09:31.909527 * path= /identity
> 2016-07-20 22:09:31.909795 * using V3 plugin to authenticate*
> 2016-07-20 22:09:31.910042 auth_url=http://192.168.56.103/identity
> 2016-07-20  22:09:31.910175
> token=d46339f2d0b5455db54909d6ed95a9cc
> 2016-07-20 22:09:31.910301 project_name=alt_demo
> 2016-07-20 22:09:31.910426 domain_name=Default
> 2016-07-20 22:09:31.910676 project_domain_name=default
>

[openstack-dev] [Congress] Mascot

2016-07-15 Thread Tim Hinrichs

Hi all,

As a reminder, we need to come up with a list of 2-3 mascots so the
OpenStack Foundation can choose 1 and turn it into a logo for Congress.
The mascots must come from the natural world (animals, plants, mountains,
waterfalls, etc.).  Deadline is July 27.

I'll get the thread started with the following animal suggestions, all of
which are called a 'congress' when there is a group of them.

salamander
raven
baboon

Any other suggestions?  Any preferences among those 3?  I'm not a fan of
baboon.

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] [puppet] [Congress] Request to create puppet-congress

2016-06-07 Thread Tim Hinrichs

Hi Dan,

As far as the Congress team is concerned, that'd be great!  Let us know how
we can help.

Tim

On Tue, Jun 7, 2016 at 12:54 PM Dan Radez  wrote:

> I'd like to get puppet-congress started.
>
> I've written some code based on the cookie cutter structure but I've not
> gone through proper channels yet to get it into openstack-puppet.
>
> I'd like to get the project establish so that the code can be run
> through the review process.
>
> Dan Radez
> freenode: radez
>
> __
> OpenStack Development Mailing 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] Spec for congress.conf

2016-06-02 Thread Tim Hinrichs

Bryan,

I spent some time looking into the proper way to document configuration
options in OpenStack.  There's a configuration reference that's part of the
openstack-manuals project.  It'll take some time to figure out the best way
of contributing to that.

But for now I added a section to our docs detailing the most important
options for Congress.  All the rest of the config options are common to
most OpenStack projects.  We should document those too, but for the time
being I think we've got the most important part in place.

Here's the change in review, if you want to comment.
https://review.openstack.org/#/c/324732/

If you'd rather just have the Congress-specific config options, here's the
text from that change.
As Masahito said, everything has a default value, so all of these are
optional for you to include in the configuration file.  In practice,
though, you should always provide the ``drivers`` option, since otherwise
you won't be able to create any datasources.

Quick request: Could you give us feedback around whether an empty default
value for ``drivers`` makes sense, or whether it would be (much) better for
the default to be all of the drivers that exist in Congress?

The options most important to Congress are described below, all of which
appear under the [DEFAULT] section of the configuration file.

``drivers``
The list of permitted datasource drivers.  Default is the empty list.
The list is a comma separated list of Python class paths. For example:
drivers =
congress.datasources.neutronv2_driver.NeutronV2Driver,congress.datasources.glancev2_driver.GlanceV2Driver

``datasource_sync_period``
The number of seconds to wait between synchronizing datasource config
from the database.  Default is 0.

``enable_execute_action``
Whether or not congress will execute actions.  If false, Congress will
never execute any actions to do manual reactive enforcement, even if
there
are policy statements that say actions should be executed and the
conditions of those actions become true.  Default is True.

One of Congress's new experimental features is distributing its services
across multiple services and even hosts.  Here are the options for using
that feature.

``distributed_architecture``
Whether to enable the distributed architecture.  Don't set it to true in
before Newton release since the new architecture is still under
development as of Newton.  Default is false.

``node_id``
Unique ID of this Congress instance.  Can be any string.  Useful if
you want to create multiple, distributed instances of Congress.

Here are the most often-used, but standard OpenStack options.  These
are specified in the [DEFAULT] section of the configuration file.

``auth_strategy``
Method for authenticating Congress users.
Can be assigned to either 'keystone' meaning that the user must provide
Keystone credentials or to 'noauth' meaning that no authentication is
required.  Default is 'keystone'.

``verbose``
Controls whether the INFO-level of logging is enabled.  If false,
logging
level will be set to WARNING.  Default is false.  Deprecated.

``debug``
Whether or not the DEBUG-level of logging is enabled. Default is false.

Tim

On Tue, May 31, 2016 at 10:18 AM Tim Hinrichs <t...@styra.com> wrote:

> We should add a section to our docs that details the config option names,
> their descriptions, and which ones are required.  We should backport that
> to mitaka and maybe liberty.
>
> Tim
>
> On Mon, May 30, 2016 at 12:49 AM Masahito MUROI <
> muroi.masah...@lab.ntt.co.jp> wrote:
>
>> Hi Bryan,
>>
>>
>> On 2016/05/28 2:52, Bryan Sullivan wrote:
>> > Masahito,
>> >
>> > Sorry, I'm not quite clear on the guidance. Sounds like you're saying
>> > all options will be defaulted by Oslo.config if not set in the
>> > congress.conf file. That's OK, if I understood.
>> you're right.
>>
>> >
>> > It's clear to me that some will be deployment-specific.
>> >
>> > But what I am asking is where is the spec for:
>> > - what congress.conf fields are supported i.e. defined for possible
>> > setting in a release
>> Your generated congress.conf has a list of all supported config fields.
>>
>> > - which fields are mandatory to be set (or Congress will simply not
>> work)
>> > - which fields are not mandatory, but must be set for some specific
>> > purpose, which right now is unclear
>> Without deployment-specific configs, IIRC what you need to change from
>> default only is "drivers" fields to run Congress with default setting.
>>
>> >
>> > I'm hoping the answer isn't "go look at the code"! That won't work for
>> > end-users, who are looking to use Congress but not decipher the
>> &

Re: [openstack-dev] [congress] Spec for congress.conf

2016-05-31 Thread Tim Hinrichs

We should add a section to our docs that details the config option names,
their descriptions, and which ones are required.  We should backport that
to mitaka and maybe liberty.

Tim

On Mon, May 30, 2016 at 12:49 AM Masahito MUROI <
muroi.masah...@lab.ntt.co.jp> wrote:

> Hi Bryan,
>
>
> On 2016/05/28 2:52, Bryan Sullivan wrote:
> > Masahito,
> >
> > Sorry, I'm not quite clear on the guidance. Sounds like you're saying
> > all options will be defaulted by Oslo.config if not set in the
> > congress.conf file. That's OK, if I understood.
> you're right.
>
> >
> > It's clear to me that some will be deployment-specific.
> >
> > But what I am asking is where is the spec for:
> > - what congress.conf fields are supported i.e. defined for possible
> > setting in a release
> Your generated congress.conf has a list of all supported config fields.
>
> > - which fields are mandatory to be set (or Congress will simply not work)
> > - which fields are not mandatory, but must be set for some specific
> > purpose, which right now is unclear
> Without deployment-specific configs, IIRC what you need to change from
> default only is "drivers" fields to run Congress with default setting.
>
> >
> > I'm hoping the answer isn't "go look at the code"! That won't work for
> > end-users, who are looking to use Congress but not decipher the
> > meaning/importance of specific fields from the code.
> I guess your generated config has the purpose of each config fields.
>
> If you expect the spec means documents like [1], unfortunately Congress
> doesn't have these kind of document now.
>
> [1] http://docs.openstack.org/mitaka/config-reference/
>
> best regards,
> Masahito
>
> >
> > Thanks,
> > Bryan Sullivan
> >
> >> From: muroi.masah...@lab.ntt.co.jp
> >> Date: Fri, 27 May 2016 15:40:31 +0900
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [congress] Spec for congress.conf
> >>
> >> Hi Bryan,
> >>
> >> Oslo.config that Congress uses to manage config sets each fields to
> >> default value if you don't specify your configured values in
> >> congress.conf. In that meaning, all config is option/required.
> >>
> >> In my experience, config values differing from each deployment, like ip
> >> address and so on, have to be configured, but others might be configured
> >> when you want Congress to run with different behaviors.
> >>
> >> best regard,
> >> Masahito
> >>
> >> On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:
> >> > Hi Congress team,
> >> >
> >> >
> >> >
> >> > Quick question for anyone. Is there a spec for fields in congress.conf
> >> > file? As of Liberty this has to be tox-generated but I need to know
> >> > which conf values are required vs optional. The generated sample
> output
> >> > doesn't clarify that. This is for the Puppet Module and JuJu Charm I
> am
> >> > developing with the help of RedHat and Canonical in OPNFV. I should
> have
> >> > Congress installed by default (for the RDO and JuJu installers) in the
> >> > OPNFV Colorado release in the next couple of weeks, and the
> >> > congress.conf file settings are an open question. The Puppet module
> will
> >> > also be used to create a Fuel plugin for installation.
> >> >
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Bryan Sullivan | AT
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> >> --
> >> 室井 雅仁(Masahito MUROI)
> >> Software Innovation Center, NTT
> >> Tel: +81-422-59-4539
> >>
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] update congress

2016-05-24 Thread Tim Hinrichs

Hi Yue,

That version of Congress definitely doesn't have the Push driver.  The Push
driver code was implemented only in the latest release (Mitaka).

Here are the upgrade instructions.  They SHOULD work, but let us know if
you run into problems, both so we can help you and so we can correct the
instructions.

https://review.openstack.org/#/c/320652/2/README.rst

Tim

On Tue, May 24, 2016 at 3:40 AM Yue Xin  wrote:

> Hi Tim and all,
>
> May I ask how to update the congress version with the Tokyo Hands on Lab
> environment? cause I use the command ＂openstack congress list version＂ it
> show the congress is 2013's version.
>
> The reason why I want to update it is that I write a demo driver, which I
> want to push data into the datasource table, but when I use 'curl -i -g -X
> PUT ' command , the error is "501 not implemented" , same error comes with
> 'curl -X PUSH', I am not sure whether it comes from the version of congress
> or not(I thought maybe congress is too old so it doesn't support push data).
>
> Thank you very much for your response.
>
> *Regards,*
> *Yue*
>
__
OpenStack Development Mailing 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] driver (authentication issue)

2016-05-18 Thread Tim Hinrichs

When you're doing testing like this, the easiest solution is to disable
authentication.  Here are the instructions from the previous email:

To use curl, the easiest thing to do is go into /etc/congress/congress.conf
and change the auth_strategy from keystone to noauth, and restart the
congress server.  Then Congress won't ask for authentication credentials.

auth_strategy = noauth

Tim

On Tue, May 17, 2016 at 8:36 PM Yue Xin  wrote:

> Hi Tim and all,
>
> Thank you very much. I put congress in a tag so I missed your email and
> relay late. Sorry about that.
>
> My problem here is that i want to use the command line to put the data
> into the congress datasource.
> I use the command openstack congress datasource create test test(i have a
> test_driver), and successed in creating a table.
> Then I want to check the table use the command(openstack congress
> datasource list table test) the errer is (internal server error 501).
> Then I try to push the data to the test table, use
>
> curl -g -i -X PUThttp://localhost:1789/v1/data-sources/id/tables/ 
> 
>
> the response is "authentication required" which means I can't push data into 
> congress datasource. I have no idea how to fix it. Can you give me some hints?
>
> Thank you 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

[openstack-dev] [Congress] Nominating Anusha Ramineni and Eric Kao for core reviewer

2016-05-13 Thread Tim Hinrichs

Hi all,

I'm writing to nominate Anusha Ramineni and Eric Kao as Congress core
reviewers.  Both Anusha and Eric have been active and consistent
contributors in terms of code, reviewing, and interacting with the
community since September--for all of Mitaka and a few months before that.

Anusha was so active in Mitaka that she committed more code than the other
core reviewers, and wrote the 2nd most reviews over all.  She took on
stable-maintenance, is the first person to fix gate breakages, and manages
to keep Congress synchronized with the rest of the OpenStack projects we
depend on.  She's taken on numerous tasks in migrating to our new
distributed architecture, especially around the API.  She manages to write
honest yet kind reviews, and has discussions at the same level as the rest
of the cores.

Eric also committed more code in Mitaka than the other core reviewers.  He
has demonstrated his ability to design and implement solutions and work
well with the community through the review process.  In particular, he
completed the Congress migration to Python3 (including dealing with the
antlr grammar), worked through difficult problems with the new distributed
architecture (e.g. message sequencing, test-nondeterminism), and is now
designing an HA deployment architecture.  His reviews and responses are
both thoughtful and thorough and engages in discussions at the same level
as the rest of the core team.

Anusha and Eric: it's great working with you both!

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] driver (authentication issue)

2016-05-13 Thread Tim Hinrichs

Hi Yue,

Added the mailing list to this one too.  Responses inline.

If you're comfortable with IRC, you can go to the #congress channel on
chat.freenode.net to ask question in real time.  Would likely be quicker
than debugging over email.

On Fri, May 13, 2016 at 2:03 PM Yue Xin  wrote:

>  Hi Tim,
>
> Thank you so much for your warm help previously.
> I have written a driver as a demo to create a table on congress. it
> succeed. But when I use the command to list the table, the error is:
> [image: image.png]
> "internal server error (http 500)"
>

That looks like a bug--you shouldn't see 500 errors.  We'd need more info
to help you avoid the problem: (i) the command you used to create the
'test' datasource and (ii) the datasource driver code that you created.

> [image: image.png]
>
> when I want to use curl to access localhost:1789 the error is
> authentication required. I tried to add -u congress:password, still get
> this error.
>
>
To use curl, the easiest thing to do is go into /etc/congress/congress.conf
and change the auth_strategy from keystone to noauth, and restart the
congress server.  Then Congress won't ask for authentication credentials.

auth_strategy = noauth

Tim

> My working environment is "Tokyo hands on lab virtual machine"
>
> Thank you so much for your help.
>
> *Regards,*
> *Yue*
>
__
OpenStack Development Mailing 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] with vm-placement and the third party module

2016-05-13 Thread Tim Hinrichs

Hi Yue,

Not sure I understood your question exactly.  You can definitely build your
own datasource and have it do whatever you want.  The one I created had all
the vm-placement logic that was contained in
policy_engines/vmplacement.py.  And in the commit it shows how to invoke
the different functions on that datasource from the command line using curl.

BTW I added the openstack-dev mailing list to this thread.  It's good to
send this kind of note to openstack-dev and start the subject line with
[Congress] so the Congress team sees it.

Tim



On Thu, May 12, 2016 at 7:47 PM Yue Xin <xinyuefeiy...@gmail.com> wrote:

> Hi Tim and all,
>
> Thank you so much. It helps a lot.
> But I still have some confusion here. The vmplace driver trigger the vm
> placement by combine the driver and vm together。is there any way to have
> congress communicate with a separate one?(seperate driver and module)
>
> Thank you very much
>
> *Regards,*
> *Yue*
>
> On 11 May 2016 at 21:22, Tim Hinrichs <t...@styra.com> wrote:
>
>> Hi Yue,
>>
>> I got the vm-placement code added to a datasource that seems to spin up
>> and is working.  You can get the vm-placement datasource driver from here:
>>
>> https://review.openstack.org/#/c/315303/
>>
>> The commit message explains how to use it.  (You already know how to
>> configure Congress to use a new datasource driver.  So you do the same
>> thing with this new file.)
>>
>> Tim
>>
>> On Tue, May 10, 2016 at 6:50 AM Yue Xin <xinyuefeiy...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Thank you so much for your kindness feedback.
>>>
>>> I will try to put vm_placement.py in the same directory with
>>> others.(pervious I didn't find the location of other drivers, now I figured
>>> out they are in /opt/stack/congress/congress/datasources/).
>>>
>>> I am not quite sure about the congress version, I download the "Tokyo
>>> Hands On Lab virtual machine <https://goo.gl/o062Kc>" directly to work
>>> on virtualbox.
>>>
>>> My vm_placement_driver.py is quite simple right now(not sure about how
>>> it works). I have attached it below. I will work on it this week, if any
>>> progress, I will let you know.
>>>
>>> Thanks
>>>
>>>
>>> *Regards,*
>>> *Yue*
>>>
>>> On 9 May 2016 at 18:27, Tim Hinrichs <t...@styra.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Yue wants to use the vm-placement module.  It's intended to be an
>>>> additional policy-engine, but maybe we can load it as if it were a new
>>>> datasource.  Anyone know if that would work?
>>>>
>>>> Yue: I CCed the rest of the team.  When you configure Congress, you are
>>>> giving it the path to the datasource:
>>>> congress.datasources.vm_placement_driver says to grab
>>>> congress/datasources/vm_placement_driver.py.  So put your file at that
>>>> location within the Congress repo.  (Make sure it's in the same directory
>>>> as all the other drivers.)  If that doesn't work, could you tell us which
>>>> version of Congress you are using (the Hands-on-lab from Vancouver?)?
>>>> Could you attach the vm_placement_driver.py file you are using?
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>> On Mon, May 9, 2016 at 3:13 PM Yue Xin <xinyuefeiy...@gmail.com> wrote:
>>>>
>>>>> Hi Tim,
>>>>>
>>>>> Thank you very much for your reply.
>>>>>
>>>>>  I have written an demo vm-placement driver, and tried to put it into
>>>>> the demo. But I have no clue where to put it.
>>>>>
>>>>> I added an line in "devstack/lib/congress" to tell congress there is a
>>>>> new driver added
>>>>> [image: image.png]
>>>>>
>>>>> but when I use the command "opeopenstack congress datasource create
>>>>> --config username=admin --config tenant_name=admin  --config auth_url=
>>>>> http://127.0.0.1:5000/v2.0 --config password=password -ope-config
>>>>> poll_time=5 vm_placement vm_placement"
>>>>>
>>>>> the response is"*driver not found(Http 404)"*
>>>>>
>>>>> I guess it is because I didn't put the vm_placement_driver.py in the
>>>>> right place.
>>>>>
>>>>> Can you give me some suggestion where to put the added driver

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

2016-05-12 Thread Tim Hinrichs

t; >>> question.
> >>>
> >>> On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
> >>>> Hi Tim,
> >>>>
> >>>> I agree – creating a datasource from Vitrage to Congress is the
> >>>> first step, and we should have some concrete use case in mind to
> >>>> help guide this process.
> >>>>
> >>>> The most straightforward use case I would suggest is when there is
> >> a
> >>>> problem on an instance that is caused by some problem on the
> >>>> physical host. Then:
> >>>>
> >>>> ·Vitrage will notify about an alarm on the instance, which Congress
> >>>> will receive
> >>>>
> >>> Why does Congress need to receive the alarm?  DataSouce Driver pulls
> >>> data from Vitrage, so it looks like Congress should only pull the
> >>> cause of the failure from Vitrage.
> >>>
> >>> Best regards,
> >>> Masahito
> >>>
> >>>> ·Congress can then call the Vitrage RCA API. The response will
> >> state
> >>>> that the cause of the instance alarm is the host alarm.
> >>>>
> >>>> ·Congress policy can define that in such a case, the instance
> >> should
> >>>> be migrated to (or healed on) a different physical host
> >>>>
> >>>> Does this seem like a good first step for you?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Alexey
> >>>>
> >>>> *From:*Tim Hinrichs [mailto:t...@styra.com]
> >>>> *Sent:* Saturday, May 07, 2016 2:43 AM
> >>>> *To:* OpenStack Development Mailing List (not for usage questions)
> >>>> *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-
> >> Congress
> >>>> Collaboration
> >>>>
> >>>> Hi Alexey,
> >>>>
> >>>> Thanks for the overview of how you see a Congress-Vitrage
> >>>> integration being valuable.
> >>>>
> >>>> I'd imagine that the right first step in this integration would be
> >>>> creating a new datasource driver within Congress to pull data from
> >>>> Vitrage.  It doesn't need to pull all the data in your list to
> >>>> start, but enough so that we can try writing policy over that data.
> >>>> It's helpful to have a policy in mind that you want to write and
> >>>> then set up the datasource driver to grab enough of the Vitrage
> >> data
> >>>> to write that policy.  Here are the relevant docs.
> >>>>
> >>>> Datasource drivers
> >>>>
> >>>> http://docs.openstack.org/developer/congress/cloudservices.html
> >>>>
> >>>> Writing policy
> >>>>
> >>>> http://docs.openstack.org/developer/congress/policy.html
> >>>>
> >>>> Let me know if you have any questions,
> >>>>
> >>>> Tim
> >>>>
> >>>> On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL)
> >>>> <alexey.w...@nokia.com <mailto:alexey.w...@nokia.com>> wrote:
> >>>>
> >>>> Hi to all Vitrage and Congress contributors,
> >>>>
> >>>> We had a good introduction meeting in Austin and we (Vitrage)
> >>> think
> >>>> that we can have a good collaboration between the projects.
> >>>>
> >>>> Vitrage, as an Openstack Root Cause Analysis (RCA) Engine,
> >>>> builds
> >>> a
> >>>> topology graph of all the entities in the system (physical,
> >>> virtual
> >>>> and application) from different datasources. It thus can enrich
> >>>> Congress by providing more data about what is happening in the
> >>>> system. Additionally, the Vitrage RCA and deduce alarms &
> >> states
> >>>> mechanism can enhance the visibility of faults and how they
> >>>> inter-relate.  By using this information Congress could then
> >>> execute
> >>>> different policies and perform more accurate actions.
> >>>>
> >>>> Another good property of Vitrage is that it can receive data
> >> also
> >>>> from non-openstack sources, like Nagios, which monitor the
> >>> physical
> &g

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

2016-05-06 Thread Tim Hinrichs

Hi Alexey,

Thanks for the overview of how you see a Congress-Vitrage integration being
valuable.

I'd imagine that the right first step in this integration would be creating
a new datasource driver within Congress to pull data from Vitrage.  It
doesn't need to pull all the data in your list to start, but enough so that
we can try writing policy over that data.  It's helpful to have a policy in
mind that you want to write and then set up the datasource driver to grab
enough of the Vitrage data to write that policy.  Here are the relevant
docs.

Datasource drivers
http://docs.openstack.org/developer/congress/cloudservices.html

Writing policy
http://docs.openstack.org/developer/congress/policy.html

Let me know if you have any questions,
Tim



On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi to all Vitrage and Congress contributors,
>
> We had a good introduction meeting in Austin and we (Vitrage) think that
> we can have a good collaboration between the projects.
>
> Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a
> topology graph of all the entities in the system (physical, virtual and
> application) from different datasources. It thus can enrich Congress by
> providing more data about what is happening in the system. Additionally,
> the Vitrage RCA and deduce alarms & states mechanism can enhance the
> visibility of faults and how they inter-relate.  By using this information
> Congress could then execute different policies and perform more accurate
> actions.
>
> Another good property of Vitrage is that it can receive data also from
> non-openstack sources, like Nagios, which monitor the physical resources,
> including Switches (which are not modeled today in OpenStack).
>
> There are many ways in which Congress-Vitrage combination would be
> helpful. To take just one example:
> a. If a physical Switch is down, Vitrage can raise deduced alarms on the
> connected hosts and on the virtual machines affected by this change in
> switch state.
> b. Congress will then be notified by Vitrage about these alarms, which can
> set off Congress policies of migration.
> c. Furthermore, due to the RCA functionality, Congress will be aware that
> the Switch error is the source of the problem, and can determine the best
> place to create new instances of the VMs so that this  switch fault will
> not impact the new instances.
>
> As you can see, for each fault, we can use Vitrage to link it to other
> faults, and create alarms to reflect them. This is all done via Vitrage
> Templates, so the system is configurable to the needs of the user. Thus
> many more cases such as the example above could be thought of.
>
> To summarize, Vitrage can enrich Congress with the following four features:
> a. RCA
> b. Deduced alarms
> c. Physical, virtual and application layers
> d. Graph structure and topology of the system that defines the connections
> and relationships between all entities on which we can run quick graph
> algorithms to decide different actions to perform
>
> If you can think of additional use cases that can be used here, please
> share ☺
>
> For more data about Vitrage and its insights please take a look here:
> https://wiki.openstack.org/wiki/Vitrage
>
> Best Regards,
> Alexey Weyl
>
> __
> OpenStack Development Mailing 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] Austin recap

2016-05-03 Thread Tim Hinrichs

Hi all,

Here’s a quick summary of the Congress activities in Austin.  Everyone
should feel free to chime in with corrections and things I missed.

1. Talks

Masahito gave a talk on applying Congress for fault recovery in the context
of NFV.

https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199

Fabio gave a talk on applying Congress + Monasca to enforce
application-level SLAs.

https://www.openstack.org/summit/austin-2016/summit-schedule/events/7363

2. Integrations

We had discussions, both within the Congress Integrations fishbowl session,
and outside of that session on potential integrations with other OpenStack
projects.  Here's a quick overview.

- Monasca (fabiog). The proposed integration: Monasca pushes data to
Congress using the push driver to let Congress know about the alarms
Monasca configured.  Can use multiple alarms using a single table.
Eventually we talked about having Congress analyze the policy to configure
the alarms that Monasca uses, completing the loop.

- Watcher (acabot). Watcher aims to optimize the placement of VMs by
pulling data from Ceilometer/Monasca and Nova (including
affinity/anti-affinity info), computing necessary migrations for whichever
strategy is configured, and migrates the VMs.  Want to use Congress as a
source of policies that they take into account when computing the necessary
migrations.

- Nova scheduler.  There’s interest in policy-enabling the Nova scheduler,
and then integrating that with Congress in the context of delegation, both
to give Congress the ability to pull in the scheduling policy and to push
the scheduling policy.

- Mistral.  The use case for this integration is to help people create an
HA solution for VMs.  So have Congress monitor VMs, identify when they have
failed, and kick off a Mistral workflow to resurrect them.

- Vintrage.  Vintrage does root-cause-analysis.  It provides a graph-based
model for the structure of the datacenter (switches attached to
hypervisors, servers attached to hypervisors, etc.) and a templating
language for defining how to create new alarms from existing alarms.  The
action item that we left is that the Vintrage team will initiate a mailing
list thread where we discuss which Vintrage data might be valuable for
Congress policies.

3. Working sessions

- The new distributed architecture is nearing completion.  There seems to
be 1 blocker for having the basic functionality ready to test: at boot,
Congress doesn’t properly spin up datasources that have already been
configured in the database.  As an experiment to see how close we were to
completion, we started up the Congress server with just the API and policy
engine and saw the basics actually working!  When we added the datasources,
we found a bug where the API was assuming the datasources could be
referenced by UUID, when in fact they can only be referenced by Name on the
message-bus.   So while there’s still quite a bit to do, we’re getting
close to having all the basics working.

- We made progress on the high-availability and high-throughput design.
This is still very much open to design and discussion, so continuing the
design on the mailing list would be great.  Here are the highlights.

   o  Policy engine: split into (i) active-active for queries to deal with
high-throughput (ii) active-passive for action-execution (requiring
leader-election, etc.).  Policy CRUD modifies DB; undecided whether API
also informs all policy-engines, or whether they all sync from the DB.

   o  Pull datasources: no obvious need for replication, since they restart
really fast and will just re-pull the latest data anyhow

   o  Push datasources: Need HA for ensuring the pusher can always push,
e.g. the pusher drops the message onto oslo-messaging.  Still up for debate
is whether we also need HA for storing the data since there is no way to
ask for it after a restart; one suggestion is that every datasource must
allow us to ask for the state.  HT does not require replication, since
syncing the state between several instances would be required and would be
less performant than a single instance.

   o  API (didn’t really discuss this, so here’s my take).  No obvious need
for replication for HT, since if the API is a bottleneck, the backend will
be an even bigger bottleneck.  For HA, could do active-active since the API
is just a front-end to the message bus + database, though we would need to
look into locking now that there is no GIL.

It was great seeing everyone in Austin!
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

[openstack-dev] [Congress] No meeting on April 27

2016-04-22 Thread Tim Hinrichs

No meeting for next week (April 27), since we'll be in Austin at the
summit.  We will send out an update about what happened during the summit
next week.

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]Authorization mechanisms for each user

2016-04-19 Thread Tim Hinrichs

Hi Yuki,

Sounds good.  The Congress team will be at Austin next week at the summit.
Most of the team will be at most of the events that you find by searching
for "Congress".  Let us know if you want to meet face-to-face to discuss
further.

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress

Tim


On Mon, Apr 18, 2016 at 6:31 PM Yuki Nisiwaki <uckey.1...@gmail.com> wrote:

> Hi Tim,
>
> Thanks.
> Your information is very useful for me.
>
> >I know someone was doing what you are proposing to implement a
> sophisticated notion of quotas for Nova
> I'll read later and make use of it as sample program.
>
>
> >though there's been talk of a more dynamic policy.json in the past
> I didn't know there's been talk of a more dynamic policy.json.
> So I tried to search "dinamic policy.json" and
> I found the keystone blueprint (
> https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery
> ).
> And this dynamical policy blueprint might  adopt the pluggable policy
> backend.
> So I thought we can consider to use congress as this backend.
>
> I'll consider how to implement authorization system with above information
> as well.
>
>
> >One thing to think about is what kind of performance and availability
> needs you have.  Making Congress say Yes or No to every API call puts it on
> the critical path.
> Your point is very useful for me.
> Surely, I have to consider the performance problem.
>
>
> > longer term we could look into more exotic options, such as the cloud
> admin managing policy via Congress, and Congress distributing that policy
> to the services that need it.  Think of this as a mini-Congress running on
> each service.  This way, instead of each service contacting Congress on
> every API call, the service could make the Yes/No decision itself.
> This future plan is very interesting. I think this architecture is also
> useful other than this time use-case.
>
>
> Thanks your information,
> and I'll put these information in order by myself, and consider how to
> achieve it.
> I'm interested in Congress project, so I'll watch the activity of Congress.
>
> Best regards.
>
> Yuki
>
>
>
> 2016-04-19 7:35 GMT+09:00 Tim Hinrichs <t...@styra.com>:
>
>> Hi Yuki,
>>
>> That description was very helpful.  In short, policy.json doesn't work
>> because the person setting policy is not permitted to change policy.json
>> (which happens in part because policy.json has no API for controlling it).
>>
>> In that case, using Congress makes sense.  I know someone was doing what
>> you are proposing to implement a sophisticated notion of quotas for Nova.
>> As far as I know, Congress is the best option for your use case today
>>  (though there's been talk of a more dynamic policy.json in the past).  You
>> can find the plugin for Nova in the repo.
>>
>> https://github.com/openstack/congress/tree/master/contrib/nova
>>
>> One thing to think about is what kind of performance and availability
>> needs you have.  Making Congress say Yes or No to every API call puts it on
>> the critical path.  How many requests per second do you expect?  If each
>> one of those requests needs to talk to Congress, is the latency/throughput
>> of a round-trip to another service going to be a problem?  What happens if
>> the network is partitioned and the other services cannot reach Congress for
>> some period of time?  Can you deny or allow all access until the network
>> reconnects?
>>
>> The Congress team is getting close to finishing a new architecture aimed
>> at high-availability and high-throughput, so we'd love to hear more details
>> about what you think you need.
>>
>> Also, longer term we could look into more exotic options, such as the
>> cloud admin managing policy via Congress, and Congress distributing that
>> policy to the services that need it.  Think of this as a mini-Congress
>> running on each service.  This way, instead of each service contacting
>> Congress on every API call, the service could make the Yes/No decision
>> itself, and Congress would update each mini-Congress as needed.  That would
>> give you low-latency and high-availability, even in the presence of network
>> disconnections.
>>
>> Tim
>>
>>
>> On Sat, Apr 16, 2016 at 9:41 AM Yuki Nisiwaki <uckey.1...@gmail.com>
>> wrote:
>>
>>> Hi Masahito, Tim.
>>>
>>> Thanks for your messages.
>>>
>>> >> btw, I added [Congress] prefix in the subject.
>>> Firstly thanks for your point, I'm beginner openstacker. So this

Re: [openstack-dev] [Congress]Authorization mechanisms for each user

2016-04-18 Thread Tim Hinrichs

Hi Yuki,

That description was very helpful.  In short, policy.json doesn't work
because the person setting policy is not permitted to change policy.json
(which happens in part because policy.json has no API for controlling it).

In that case, using Congress makes sense.  I know someone was doing what
you are proposing to implement a sophisticated notion of quotas for Nova.
As far as I know, Congress is the best option for your use case today
 (though there's been talk of a more dynamic policy.json in the past).  You
can find the plugin for Nova in the repo.

https://github.com/openstack/congress/tree/master/contrib/nova

One thing to think about is what kind of performance and availability needs
you have.  Making Congress say Yes or No to every API call puts it on the
critical path.  How many requests per second do you expect?  If each one of
those requests needs to talk to Congress, is the latency/throughput of a
round-trip to another service going to be a problem?  What happens if the
network is partitioned and the other services cannot reach Congress for
some period of time?  Can you deny or allow all access until the network
reconnects?

The Congress team is getting close to finishing a new architecture aimed at
high-availability and high-throughput, so we'd love to hear more details
about what you think you need.

Also, longer term we could look into more exotic options, such as the cloud
admin managing policy via Congress, and Congress distributing that policy
to the services that need it.  Think of this as a mini-Congress running on
each service.  This way, instead of each service contacting Congress on
every API call, the service could make the Yes/No decision itself, and
Congress would update each mini-Congress as needed.  That would give you
low-latency and high-availability, even in the presence of network
disconnections.

Tim

On Sat, Apr 16, 2016 at 9:41 AM Yuki Nisiwaki  wrote:

> Hi Masahito, Tim.
>
> Thanks for your messages.
>
> >> btw, I added [Congress] prefix in the subject.
> Firstly thanks for your point, I'm beginner openstacker. So this
> information is very useful.
>
> Move to main topic.
>
> >So as Masahito mentioned, if you provide more details about your use case
> >(in particular what kinds of information you need for making authorization
> >decisions),
>
> I supposed that we use OpenStack as Public Cloud which have multiple
> tenants.
> So The cloud administrator on OpenStack who have the admin role in
> OpenStack
> and The deployer who is in charge of creating OpenStack environment and
> providing service are not same.
> So we desire some mechanism to enable the admin on OpenStack in tenant (or
> domain) to specify which service(or function) can the user to use.
>
> >the usual way to authorize API calls in OpenStack is
> >through policy.json.  If I remember right, you can make a decision about
> >whether an API call is permitted using (i) all the values in the API call
> >and (ii) the Keystone role of the user making the request.  I'm not sure
> if
> >you can also use the actual userID of the person making the request or
> not,
> >but as soon as you get to 10 users, you'll end up grouping individual
> users
> >into roles anyway.
>
> Surely, The policy.json have potential to cover above our needs.
> But as I mentioned before, the deployer and administrator of OpenStack
> isn't same.
> And the deployer want to restrict the admin from login to the server which
> start up api processes.
> So the admin on OpenStack can't login to the servers of working api
> process.
>
> But it can't definitely realized by policy.json.
> If we prepare the api server that works changing policy.json  and  provide
> the users.
> But I think this solution isn't very good.
> There are many reason of making this solution bad.
> first reason is to make the rule of policy.json complex.
> second reason is that policy file is distributed in many server and many
> directory.
>
>
> The reasons I'm interested in congress are followings.
>  - Congress can centrally manage policy rule.
>  - Congress can change policy or add policy via API.
> So honestly I don't concern about dynamical policy (e.g. depending on the
> policy, which network is connected to) in our use-case.
>
>
> if you'll allow a slight digression,
> If we integrate authorization mechanism to actual environment,
> we will prepare the translator from authorization specific policy to
> datalog and
> we don't expose the congress in order to improve usability in the user
> perspective.
>
> Can this mail give the image of what I want to do to you?
>
> Yuki
> 
> >Hi Yuki,
> >
> >As Masahito mentioned, the usual way to authorize API calls in OpenStack
> is
> >through policy.json.  If I remember right, you can make a decision about
> >whether an API call is permitted using (i) all the values in the API call
> >and (ii) the Keystone role of the user making the request.  I'm not sure
> if
> >you can also use

Re: [openstack-dev] [Congress]Authorization mechanisms for each user

2016-04-15 Thread Tim Hinrichs

Hi Yuki,

As Masahito mentioned, the usual way to authorize API calls in OpenStack is
through policy.json.  If I remember right, you can make a decision about
whether an API call is permitted using (i) all the values in the API call
and (ii) the Keystone role of the user making the request.  I'm not sure if
you can also use the actual userID of the person making the request or not,
but as soon as you get to 10 users, you'll end up grouping individual users
into roles anyway.

That said, Congress would be valuable for authorization decisions IF those
decisions require information other than (i) values in the API call and
(ii) the role of the user making the request.  For example, if you wanted
to stop someone from deleting a Neutron network whenever there is a Nova VM
attached to that network with status ACTIVE, then policy.json isn't
adequate, and Congress makes sense.

So as Masahito mentioned, if you provide more details about your use case
(in particular what kinds of information you need for making authorization
decisions), we can help you pick the right tool.

Tim

On Fri, Apr 15, 2016 at 1:06 AM Masahito MUROI 
wrote:

> Hi Yuki,
>
> This sounds interesting. AFAIK, there is no similar use-case you mentioned.
>
> On 2016/04/15 10:13, Yuki Nisiwaki wrote:
> > Hi openstacker working on congress.
> >
> > I want to implement the authorization mechanisms for each user, not role
> > base.
> > For example, User A can change security group, But User B can’t change
> > security group like IAM feature of AWS.
> >
> > In order to achieve it,
> > I’m considering whether can I utilize Congress feature.
> > I am thinking somehow that I can achieve it by following step.
> > 1. create policy for each user with datalog in congress
> > 2. prepare the wsgi filter for each project that works confirming
> > authorization of each user to Congress.
> Could you clarify your usecase? I think it can be done by roles and
> modifying policy.json. If you assume A and B are under some conditions,
> what kind of condition do you want to use?
>
> btw, I added [Congress] prefix in the subject.
>
> >
> > I think this use-case is very popular and there is someone who think
> > same thing.
> > But There is no information about it in any website (blog, presentation
> > in summit).
> > So why is there anyone who achieve it?
> > or does this approach have anxious point?
> > If you are interested in this approach or think same thing, I want to
> > know it.
> >
> >
> > Best regards
> >
> > Yuki Nishiwaki
> > NTT Communitions
> > Technology development
> > Cloud Core Technology Unit
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> best regards,
> Masahito
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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][release] missing build artifacts

2016-04-05 Thread Tim Hinrichs

Looks like the congress job is working now.  We have a tarball for our
latest RC:

http://tarballs.openstack.org/congress/congress-3.0.0.0rc3.tar.gz

Thierry added the links back for the tarball.

https://github.com/openstack/releases/commit/beee35379b3b52ed7d444d93d7afd8b6603f69b6

So it looks like everything is back on track for the Congress Mitaka
release.  Let me know if there's anything else I need to do.

Thanks for all the help release team!
Tim


On Sat, Apr 2, 2016 at 5:39 AM Doug Hellmann  wrote:

> Excerpts from Tim Hinrichs's message of 2016-04-01 22:46:59 +:
> > Hi Doug,
> >
> > Thanks for letting us know.  Here's what we're intending...
> > - We'd like to release the server code for Mitaka.
> > - We release the client to Pypi, so that's already taken care of.
> > - We haven't moved our docs off of readthedocs yet, so we're taking care
> of
> > that as well.
> >
> > I gave a +1 to your patch for adding openstack-server-release-jobs to
> zuul.
> > I also pushed a congress-only patch for the same, thinking that's
> probably
> > what you actually wanted us to do.
> > https://review.openstack.org/#/c/300682/
>
> Now that the jobs are in place, we should tag new release candidates
> using new versions and the same SHAs as the last candidate to get the
> artifacts built properly. You can submit the request for that using the
> releases repo, or you can tag yourself and submit the info after the
> fact. We will decide what to do about the old artifacts you have on
> launchpad separately.
>
> >
> > I gave a -1 to your patch that removes all the Congress deliverables from
> > openstack/releases, thinking that we can have this sorted out quickly.
> The
> > job we're missing just produces a tarball and uploads it, right?  We've
> > been manually doing releases up to this point, which is why we didn't
> have
> > the job in place.
> > https://review.openstack.org/300644
> >
> > I didn't touch your change on the artifact-link-mode, since it seems
> like a
> > short-term solution that may go in before we get everything sorted.
> > https://review.openstack.org/300457
>
> Yes, we'll merge that as a short-term fix until we have the rest of it
> worked out.
>
> Doug
>
> >
> > Tim
> >
> > On Fri, Apr 1, 2016 at 1:23 PM Doug Hellmann 
> wrote:
> >
> > > Congress team,
> > >
> > > We noticed in our audit of the links on
> > > http://releases.openstack.org/mitaka/index.html that the links to
> > > the build artifacts for congress point to missing files. The
> > > repository doesn't seem to have any real build jobs configured in
> > > openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> > > how tagging is producing a release for you.
> > >
> > > For now, we are disabling links to the artifacts for those repos
> > > via https://review.openstack.org/300457 but we're also planning to
> > > remove them from the official Mitaka page since there don't
> > > appear to be any actual related deliverables
> > > (https://review.openstack.org/300644).
> > >
> > > It would be good to understand what your intent is for builds. Can
> > > you follow up here on this thread with some details?
> > >
> > > Thanks,
> > > 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 Development Mailing 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][release] missing build artifacts

2016-04-01 Thread Tim Hinrichs

Hi Doug,

Thanks for letting us know.  Here's what we're intending...
- We'd like to release the server code for Mitaka.
- We release the client to Pypi, so that's already taken care of.
- We haven't moved our docs off of readthedocs yet, so we're taking care of
that as well.

I gave a +1 to your patch for adding openstack-server-release-jobs to zuul.
I also pushed a congress-only patch for the same, thinking that's probably
what you actually wanted us to do.
https://review.openstack.org/#/c/300682/

I gave a -1 to your patch that removes all the Congress deliverables from
openstack/releases, thinking that we can have this sorted out quickly.  The
job we're missing just produces a tarball and uploads it, right?  We've
been manually doing releases up to this point, which is why we didn't have
the job in place.
https://review.openstack.org/300644

I didn't touch your change on the artifact-link-mode, since it seems like a
short-term solution that may go in before we get everything sorted.
https://review.openstack.org/300457

Tim

On Fri, Apr 1, 2016 at 1:23 PM Doug Hellmann  wrote:

> Congress team,
>
> We noticed in our audit of the links on
> http://releases.openstack.org/mitaka/index.html that the links to
> the build artifacts for congress point to missing files. The
> repository doesn't seem to have any real build jobs configured in
> openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> how tagging is producing a release for you.
>
> For now, we are disabling links to the artifacts for those repos
> via https://review.openstack.org/300457 but we're also planning to
> remove them from the official Mitaka page since there don't
> appear to be any actual related deliverables
> (https://review.openstack.org/300644).
>
> It would be good to understand what your intent is for builds. Can
> you follow up here on this thread with some details?
>
> Thanks,
> 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] [Congress] Push Type Driver implementation

2016-03-24 Thread Tim Hinrichs

I tried the doctorDriver again.  This time I was successful!  I'm still
getting an error when listing the datasources though.  I tried updating and
installing my client, but no change.

// Create the datasource
$ openstack congress datasource create doctor doctor
+-+--+
| Field   | Value|
+-+--+
| config  | None |
| description | None |
| driver  | doctor   |
| enabled | True |
| id  | 3717095c-25a7-4fe2-8f18-25d845b11c60 |
| name| doctor   |
| type| None |
+-+--+

// Push data
$ curl -g -i -X PUT
http://localhost:1789/v1/data-sources/3717095c-25a7-4fe2-8f18-25d845b11c60/tables/events/rows
-H "User-Agent: python-congressclient" -H "Content-Type: application/json"
-H "Accept: application/json" -d  '[
>   {
> "id": "0123-4567-89ab",
> "time": "2016-02-22T11:48:55Z",
> "type": "compute.host.down",
> "details": {
> "hostname": "compute1",
> "status": "down",
> "monitor": "zabbix1",
> "monitor_event_id": "111"
> }
>   }
> ]'
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 0
X-Openstack-Request-Id: req-47c6dfdf-74cd-4101-829a-657b6aea1e2c
Date: Thu, 24 Mar 2016 18:28:31 GMT


// Ask for contents of table that we pushed
$ openstack congress datasource row list doctor events
++--+--+--++-+--+
| id | time | type | hostname | status
| monitor | monitor_event_id |
++--+--+--++-+--+
| 0123-4567-89ab | 2016-02-22T11:48 | compute.host.dow | compute1 | down
| zabbix1 | 111  |
|| :55Z | n|  |
 | |  |
++--+--+--++-+--+


// List the datasources
$ openstack congress datasource list
'NoneType' object has no attribute 'items'

Tim


On Thu, Mar 17, 2016 at 5:56 PM Tim Hinrichs <t...@styra.com> wrote:

> I tried the doctor driver out.  I just added the file to
> congress/datasources, and set up /etc/congress/congress.conf to include
> congress.datasources.doctor_driver.DoctorDriver.
>
> I could create a new doctor driver, but afterwards I couldn't list all the
> datasources, and I couldn't push any data to it.  See transcript below.
>
> $ openstack congress datasource create doctor doctor
> +-+--+
> | Field   | Value|
> +-+--+
> | config  | None |
> | description | None |
> | driver  | doctor   |
> | enabled | True |
> | id  | 906c6327-15f1-4f3c-aa51-1590540c06b9 |
> | name| doctor   |
> | type| None |
> +-+--+
>
> $ openstack congress datasource list
> 'NoneType' object has no attribute 'items'
>
> The other problem I saw was that the schema was fixed for the doctor
> driver.  So I tried to create a push driver that would accept any
> collection of tuples.  This wouldn't allow the user to push arbitrary JSON,
> but they could push any tuples they'd like.  While experimenting, I fixed
> the problem mentioned above by adding a single (unnecessary) configuration
> option.  Then I ran into a Datasource not found problem.  I pushed the code
> to review so we can all take a look.
>
> https://review.openstack.org/294348
>
> $ curl -g -i -X PUT
> http://localhost:1789/v1/data-sources/push/tables/data/rows -H
> "User-Agent: python-congressclient" -H "Content-Type: application/json" -H
> "Accept: application/json" -d '[[1]]'
> HTTP/1.1 404 Not Found
> Content-Type: application/json; charset=UTF-8
> Content-Length: 102
> X-Openstack-Request-Id: req-23432974-b107-4657-9bbc-c2e05fd25a98
> Date: Thu, 17 Mar 2016 21:13:03 GMT
>
> {"error": {"mess

Re: [openstack-dev] [Congress] HOL test completed

2016-03-21 Thread Tim Hinrichs

Fantastic! We have our rc1 request in for the same Sha. Hopefully that will
end up being Mitaka.

Tim
On Mon, Mar 21, 2016 at 4:48 PM Eric K  wrote:

> Happy to report that everything in Congress HOL* works as expected after
> all the merges today**.
>
> *
> https://docs.google.com/document/d/1ispwf56bX8sy9T0KZyosdHrSR9WHEVA1oGEIYA22Orw/pub
> **commit 5e2c7cde598fcb4ed781a211fb421a5e94afb406
> __
> OpenStack Development Mailing 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] Push Type Driver implementation

2016-03-19 Thread Tim Hinrichs

I tried the doctor driver out.  I just added the file to
congress/datasources, and set up /etc/congress/congress.conf to include
congress.datasources.doctor_driver.DoctorDriver.

I could create a new doctor driver, but afterwards I couldn't list all the
datasources, and I couldn't push any data to it.  See transcript below.

$ openstack congress datasource create doctor doctor
+-+--+
| Field   | Value|
+-+--+
| config  | None |
| description | None |
| driver  | doctor   |
| enabled | True |
| id  | 906c6327-15f1-4f3c-aa51-1590540c06b9 |
| name| doctor   |
| type| None |
+-+--+

$ openstack congress datasource list
'NoneType' object has no attribute 'items'

The other problem I saw was that the schema was fixed for the doctor
driver.  So I tried to create a push driver that would accept any
collection of tuples.  This wouldn't allow the user to push arbitrary JSON,
but they could push any tuples they'd like.  While experimenting, I fixed
the problem mentioned above by adding a single (unnecessary) configuration
option.  Then I ran into a Datasource not found problem.  I pushed the code
to review so we can all take a look.

https://review.openstack.org/294348

$ curl -g -i -X PUT
http://localhost:1789/v1/data-sources/push/tables/data/rows -H "User-Agent:
python-congressclient" -H "Content-Type: application/json" -H "Accept:
application/json" -d '[[1]]'
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=UTF-8
Content-Length: 102
X-Openstack-Request-Id: req-23432974-b107-4657-9bbc-c2e05fd25a98
Date: Thu, 17 Mar 2016 21:13:03 GMT

{"error": {"message": "Not Found::Datasource not found push", "error_data":
null, "error_code": 404}}

Masahito: do you know what the Datasource Not Found problem is? If not,
could you look into it? I ran into it with the Doctor Driver too.

Tim

On Thu, Mar 17, 2016 at 2:31 AM Masahito MUROI 
wrote:

> Hi folks,
>
> This[1] is the driver I mentioned at meeting. It is used for OPNFV
> Doctor[2]. So I plan to push it into master in Newton release, since
> feature freeze for Mitaka was passed and the schema of its translator is
> under the discussion.
>
> If it's worth to push it in current release to test push driver, I don't
> mind doing it.
>
> [1]
>
> https://github.com/muroi/congress/blob/doctor-poc/congress/datasources/doctor_driver.py
> [2] https://wiki.opnfv.org/doctor
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] PTL candidacy

2016-03-11 Thread Tim Hinrichs

Hi all,

I'm writing to announce my continued candidacy for Congress PTL.

In the Mitaka cycle we've been working hard and making great progress on a
number of things.  The largest change is a new distributed architecture
built on top of oslo-messaging.  That architecture is key to enabling us to
meet the high-availability and high throughput demands that we've heard
from the field.  We also saw the first new mechanism since the project's
inception for injecting data into Congress, so that external systems can
push data, instead of Congress pulling it.  In Mitaka, we also completed
the transition to Python3, and implemented the plugin interface for both
tempest and devstack.  It's also exciting that over the last two cycles, we
have seen longer-term commitments to Congress from the community, with 1
new core reviewer this cycle, and two other incredibly active contributors.

In Newton, my primary technical goal is to complete the migration to our
new distributed architecture.  I also hope to have Congress leverage that
new architecture to provide high-availability and high-throughput
solutions.  I plan to continue discussions with other projects to
understand how and where Congress can be useful. Finally, I'm looking
forward to stengthening the developer community around Congress.

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

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

2016-02-16 Thread Tim Hinrichs

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

[openstack-dev] [Congress] Mid-cycle sprint debrief

2016-02-02 Thread Tim Hinrichs

Hi all,

TL;DR.  We had a great midcycle sprint.  If you want to help us move
Congress toward its new distributed architecture, there are a list of items
you can help with below.


1. We had a productive mid-cycle sprint last week!  Here were the topics we
covered...

- Design discussions about implementing the distributed architecture using
oslo-messaging.

- Discussion about integrating Monasca so that when people write policy
Congress can use Monasca alarms to push information to us.

- Discussion with Su Zhang about his experiences using Congress at Symantec.

- Code sprint aimed at migrating off of our current, in-process message bus
to oslo-messaging.

For details about the discussions, check out the etherpad...
https://etherpad.openstack.org/p/congress-mitaka-sprint

2. Moving forward in the short-term, we are focusing on migrating from our
existing in-process message bus (DSE) to a small wrapper around
oslo-messaging (DSE2).

- As we migrate from DSE to DSE2, we're leaving the mainline code in place
and minimizing the changes so that it runs on both the old arch and the new
arch.  We use the flag 'distributed_architecture' to signal which version
we are running.

- Ideally the tests will all continue to function without modification in
both the old and new architectures.  But for those test files that don't
pass, we are copying them to congress/tests2 and modifying them there.

- We have disabled a few tests temporarily and marked them with TODO(dse2)
and an explanation as to why they are disabled so we can easily grep for
them later.

- tox -enew_arch will (soon) run all the tests in congress/tests2.

3. For those of you looking to help out, here are a few items you can sign
up for.

3.1. Work on porting congress/tests/test_congress.py to the new distributed
arch.  See congress/tests2/test_dse2.py for an example.  In fact, there may
be tests commented out in tests2/dse2/test_dse2.py that we should
re-enable/port.
https://bugs.launchpad.net/congress/+bug/1541008

3.2. Work on porting the remaining API models to the new arch.  See my
recent changesets for the basic idea.
https://review.openstack.org/#/c/274957/

https://bugs.launchpad.net/congress/+bug/1541001
https://bugs.launchpad.net/congress/+bug/1541002
https://bugs.launchpad.net/congress/+bug/1541003
https://bugs.launchpad.net/congress/+bug/1541004

3.3. Create a non-voting gate job for tox -enew_arch
https://bugs.launchpad.net/congress/+bug/1540990

3.4. Try out the scripts/start_process.py script to see how we would use it
for the new arch.  Eventually we'll want a non-voting job in the gate that
runs all the tempest tests on the new architecture.
https://bugs.launchpad.net/congress/+bug/1541019

Questions/comments?
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

[openstack-dev] [Congress] Mid-cycle sprint and next week's IRC

2016-01-20 Thread Tim Hinrichs

Just a reminder that next week Jan 26-Jan 28 is the Congress mid-cycle
Sprint in the Bay Area.  It's not too late to attend.  It'd be best to
register, but we'd love to have you in any case.

More details here:
https://wiki.openstack.org/wiki/Sprints/CongressMitakaSprint

Also, since we're at the Sprint next week, there will be NO IRC meeting Jan
27.

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] [infra] IRC broken

2015-12-09 Thread Tim Hinrichs

The issue with #openstack-meeting seems to have resolved itself about 35
minutes into our scheduled time.  The only thing that might be missing from
the logs are messages where people were trying to figure out what was going
on.  So if anyone missed the meeting, start at the 35 minute mark.

I included [infra] and a few more details below.

- It seemed there was a partitioning in #openstack-meeting for a while.  I
could #start the meeting, but except for 1 other person (masahito), no one
could see my messages.  I could exchange messages with masahito, but
neither of us could send messages to ekcs or ramineni.  I could, however,
see ekcs and ramineni's messages to each other.

- We had the same problem with #congress.  I eventually called ekcs, and we
tried to debug.

- I tried logging back in a couple of times, which eventually worked.  My
nick changed.  At that point, I could exchange messages with ekcs and
ramineni, and I could send messages to masahito, but I couldn't see
messages from masahito.

- Just as we were about to cancel the meeting, #congress started working
again.  Then #openstack-meeting started working, so we resumed the meeting.
 (I'm not sure #congress started working first, or if we just all happened
to notice #congress first.)

If anyone has any other pertinent details, please include them.

Tim

On Wed, Dec 9, 2015 at 5:07 PM Anita Kuno <ante...@anteaya.info> wrote:

> On 12/09/2015 07:33 PM, Tim Hinrichs wrote:
> > It seems IRC is broken for the meeting we're supposed to be having right
> > now.  The symptom is that you can logon but may only see a fragment of
> the
> > users/messages that are being sent.  We even had a partitioning where 2
> > people could exchange messages, and a different 2 people could exchange
> > messages, but not all 4 people could exchange messages.
> >
> > Unless it fixes itself in the next few minutes, we'll cancel and have the
> > discussion over email.  And given how late we're starting, we'll likely
> > have an email discussion anyway.
> >
> > 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
> >
>
> It seems you were able to hold your meeting?
>
> http://eavesdrop.openstack.org/meetings/congressteammeeting/2015/congressteammeeting.2015-12-10-00.00.log.html
>
> I don't see anything wrong with the #openstack-meeting channel.
>
> Do let infra know if you have additional details.
>
> Thank you,
> Anita.
>
> __
> OpenStack Development Mailing 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] IRC broken

2015-12-09 Thread Tim Hinrichs

It seems IRC is broken for the meeting we're supposed to be having right
now.  The symptom is that you can logon but may only see a fragment of the
users/messages that are being sent.  We even had a partitioning where 2
people could exchange messages, and a different 2 people could exchange
messages, but not all 4 people could exchange messages.

Unless it fixes itself in the next few minutes, we'll cancel and have the
discussion over email.  And given how late we're starting, we'll likely
have an email discussion anyway.

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] [Congress] Progress with Congress Install on OPNFV

2015-12-08 Thread Tim Hinrichs

Hi Bryan,

Yes.  After cloning congress, you run that command.

Tim

On Tue, Dec 8, 2015 at 1:12 PM SULLIVAN, BRYAN L <bs3...@att.com> wrote:

> Tim,
>
>
>
> Yes, using the stable version was my intent. I wasn’t sure how to do it,
> thanks.
>
>
>
> Just a clarification: re “after downloading congress” do you mean after
> cloning the repo? I guess so since it’s a git command.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> *From:* Tim Hinrichs [mailto:t...@styra.com]
> *Sent:* Tuesday, December 08, 2015 1:09 PM
> *To:* SULLIVAN, BRYAN L <bs3...@att.com>; openstack@lists.openstack.org
> *Subject:* Re: [Openstack] [Congress] Progress with Congress Install on
> OPNFV
>
>
>
> Hi Bryan,
>
>
>
> That's great news!  I'll add this to our IRC agenda for tomorrow.
>
>
>
> I don't know about the Horizon issue.  Janet, any ideas?
>
>
>
> One thing I'd suggest is to use the Liberty version of Congress with the
> Liberty version of OpenStack.  Pulling directly from master will be
> problematic (eventually) since it will deviate from the rest of the Liberty
> OpenStack projects.  All you need to do to checkout liberty is run the
> following command after downloading congress...
>
>
>
> $ cd congress
>
> $ git checkout stable/liberty
>
>
>
> Tim
>
>
>
> On Tue, Dec 8, 2015 at 12:12 PM SULLIVAN, BRYAN L <bs3...@att.com> wrote:
>
> Tim and Congress team, sending here as I didn’t get a response on
> #congress, and in OPNFV we are trying to get to code freeze for our 2nd
> release by the end of this year.
>
>
>
> I’ve been able to get Congress (latest github code) installed but not
> fully functional, on an OPNFV base with OpenStack Liberty. The APIs and
> datasources etc work, but for some reason the Horizon panel features for
> Policy are not present in Horizon. I need to know if, beyond the
> instructions in github for the standalone install, there is anything else I
> need to do to activate the Horizon Policy panel.
>
>
>
> FYI I used the github standalone instructions in a manual procedure:
> https://wiki.opnfv.org/copper/academy/joid/congress. I plan to fully
> automate this e.g. as a shell script or Ansible playbook once I get it
> fully working and repeatable.
>
>
>
> In the process I found a number of things that I’d like to bring up in the
> Congress team meeting, e.g.:
>
> -  Issues with python package dependencies: I’m trying to use
> virtualenv to minimize these, but there are still extra things that have to
> be installed sometimes, and I’m not sure why or how to ensure that these
> dependencies don’t change from install to install (which they do seem to).
>
> -  Changes to the specific instructions in the github readme,
> which I had to make to get it working
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> ___
> 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] [Congress] Progress with Congress Install on OPNFV

2015-12-08 Thread Tim Hinrichs

Hi Bryan,

That's great news!  I'll add this to our IRC agenda for tomorrow.

I don't know about the Horizon issue.  Janet, any ideas?

One thing I'd suggest is to use the Liberty version of Congress with the
Liberty version of OpenStack.  Pulling directly from master will be
problematic (eventually) since it will deviate from the rest of the Liberty
OpenStack projects.  All you need to do to checkout liberty is run the
following command after downloading congress...

$ cd congress
$ git checkout stable/liberty

Tim

On Tue, Dec 8, 2015 at 12:12 PM SULLIVAN, BRYAN L  wrote:

> Tim and Congress team, sending here as I didn’t get a response on
> #congress, and in OPNFV we are trying to get to code freeze for our 2nd
> release by the end of this year.
>
>
>
> I’ve been able to get Congress (latest github code) installed but not
> fully functional, on an OPNFV base with OpenStack Liberty. The APIs and
> datasources etc work, but for some reason the Horizon panel features for
> Policy are not present in Horizon. I need to know if, beyond the
> instructions in github for the standalone install, there is anything else I
> need to do to activate the Horizon Policy panel.
>
>
>
> FYI I used the github standalone instructions in a manual procedure:
> https://wiki.opnfv.org/copper/academy/joid/congress. I plan to fully
> automate this e.g. as a shell script or Ansible playbook once I get it
> fully working and repeatable.
>
>
>
> In the process I found a number of things that I’d like to bring up in the
> Congress team meeting, e.g.:
>
> -  Issues with python package dependencies: I’m trying to use
> virtualenv to minimize these, but there are still extra things that have to
> be installed sometimes, and I’m not sure why or how to ensure that these
> dependencies don’t change from install to install (which they do seem to).
>
> -  Changes to the specific instructions in the github readme,
> which I had to make to get it working
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
> ___
> 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

[openstack-dev] [Congress] Mid-cycle meet-up

2015-12-07 Thread Tim Hinrichs

Hi all,

We're having a mid-cycle meet-up January 26-28 in the Bay Area.

Here's a tentative schedule.  Comments, suggestions, questions?

Tue Jan 26: Discussion with Monasca team about integration.
- Intro to Congress (slides or whiteboard)
- Intro to Monasca (slides or whiteboard)
- Design discussion
- Prototyping

Wed Jan 27: Congress team code sprint for distributed arch

Thu Jan 28: Congress team design session for high availability and high
throughput

More logistics details will follow.

I hope everyone can make it!

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]role in Congress

2015-12-03 Thread Tim Hinrichs

Hi Yali,

To support the kind of collaboration you describe, we have multiple
policies.  (By "policy" here I mean a collection of rules.)  One reasonable
workflow is to designate some policy (e.g. "library") to be where people
define predicates and complicated relations that are useful for writing
policy in general, and then have everyone else use the tables defined in
"library".  I'd imagine we could do the same kind of workflow in the UI.

By the way, your original patch never got merged (it's got a -1 on review
and a -1 on tests), so before looking into adding new features it'd be
great if we could finish off your original patch.  Let us know if you want
help.

Tim


On Mon, Nov 30, 2015 at 2:20 AM Masahito MUROI <muroi.masah...@lab.ntt.co.jp>
wrote:

> Hi Yali,
>
> I'm not sure which your concern is about UI by Horizon or for a policy
> in Congress.
>
> On 2015/11/30 16:27, zhangyali (D) wrote:
> > Hi Tim,
> >
> > In the implementation of Congress UI, I have realized that we need to
> > add role assignment. In many systems and cases, RBAC (Role-Based Access
> > Control) is an vital function which are beneficial to the division of
> work.
> >
> > I think we should have “admin” and “tenant” user at least.  The admin
> > user could define predicates or complicated relations used in the
> > violations, and tenant user could just use the predicates defined by
> > admin user.
> >
> > A typical example is that, the owner of network connected to VM should
> > be in the same group with the owner of this VM. In this example,
> > same_group is a predicates or complicated relations. It should be
> I think this depends on how admin writes policy and what service works
> as Congress datasource. If admin want to adopt the policy to specific
> tenant, user or group, admin writes an additional policy to affect them
> by the policy.
>
>
> > defined by admin user. And this predicate could be used by any tenant
> > user. In this way, some typical or common predicates could be defined in
> > a individual admin board, and other tenant user could choose which one
> > to use.
> On the other hand, this mentions about which user has permission to edit
> and to see a policy by Horizon.
>
> best regard,
> Masahito
>
> >
> > Yali
> >
> > *发件人:*Tim Hinrichs [mailto:t...@styra.com]
> > *发送时间:*2015年11月30日10:37
> > *收件人:*zhangyali (D); OpenStack Development Mailing List (not for
> > usage questions)
> > *主题:*Re: [openstack-dev][congress]role in Congress
> >
> > Hi Yali,
> >
> > We didn't discuss role assignment for service users in Tokyo.  Could you
> > explain a bit more what you need?
> >
> > Tim
> >
> > On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) <zhangyali...@huawei.com
> > <mailto:zhangyali...@huawei.com>> wrote:
> >
> > Hi Tim and All,
> >
> > I remember there is a topic named “role assignment for service
> > users”in the Tokyo Summit. Since I have not heard any message of
> > this topic. Does anyone could contribute some information for me? I
> > think it is vital for my design of Congress UI in horizon. Thanks a
> lot!
> >
> > Best Regards,
> >
> > Yali
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539，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] [congress]role in Congress

2015-11-29 Thread Tim Hinrichs

Hi Yali,

We didn't discuss role assignment for service users in Tokyo.  Could you
explain a bit more what you need?

Tim

On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) 
wrote:

> Hi Tim and All,
>
>
>
> I remember there is a topic named “role assignment for service users” in
> the Tokyo Summit. Since I have not heard any message of this topic. Does
> anyone could contribute some information for me? I think it is vital for my
> design of Congress UI in horizon. Thanks a lot!
>
>
>
>
>
> Best Regards,
>
> Yali
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] tempest tests in gate not running

2015-11-23 Thread Tim Hinrichs

It looks like our tempest tests aren't running in the gate.  Here's a
recent patch that just merged this morning.

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

If you go to the testr results, you'll see a list of all the tests that
were run.

http://logs.openstack.org/05/242305/5/gate/gate-congress-dsvm-api/979bc9d/testr_results.html.gz

Two things: (i) there are many tests here that are not Congress-specific
and (ii) I don't see the Congress tests running at all.  During manual
testing both these issues were handled by the following lines in our gate
job config.

https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/congress.yaml#L33-L34

The good news, at least, is that congress is getting properly spun up.

http://logs.openstack.org/05/242305/5/gate/gate-congress-dsvm-api/979bc9d/logs/screen-congress.txt.gz

Would someone want to volunteer to dig into this?

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

[openstack-dev] [Congress] kilo bug on datasource listing

2015-11-20 Thread Tim Hinrichs

Congress stable-maintenance team:

We seem to have a bug in kilo that is making it tough for Bryan Sullivan to
get things up and running.  The swift driver doesn't have a 'secret' field,
which is causing a 500 error when listing datasources.  If I remember
right, we fixed this bug later.

https://bugs.launchpad.net/congress/+bug/1518496

Could someone volunteer to fix it?  I think we should do a release once
that's in.

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] [keystone] [Mistral] [Heat] Autoprovisioning, per-user projects, and Federation

2015-11-11 Thread Tim Hinrichs

Excerpts from Wed, Nov 11, 2015 at 10:14 AM Clint Byrum 
wrote:

> > But as Renat mentioned, the part about triggering Mistral workflows from
> > a message does not yet exist. As Tim pointed out, Congress could be a
> > solution to that (listening for a message and then starting the Mistral
> > workflow). That may be OK in the short term, but in the long term I'd
> > prefer that we implement the triggering thing in Mistral (since there
> > are *lots* of end-user use cases for this too), and have the workflow
> > optionally query Congress for the policy rather than having Congress in
> > the loop.
> >
>
> I agree 100% on the positioning of Congress vs. Mistral here.
>
>
One problem that I'd imagine Mistral would want to solve if it's picking up
events off the bus and executing workflows is how the operator configures
the event-to-workflow mapping logic.  In Adam's example, the operator would
want to say that every time the 'new-user-login-event' shows up on the bus
that Mistral should kick off the 'create-quota' workflow and the
'create-role' workflow.  In simple cases, this would just be a dictionary,
but what happens if the operator wants to condition workflow execution on
an AND/OR/NOT expression evaluated over state from different projects (e.g.
run 'create-quota' when a new user logs in and that user doesn't already
have a nova quota).

For the operator, the problem becomes more complicated when multiple
OpenStack projects are listening to the bus and kicking off
workflows/scripts/etc. The operator now has N projects to configure
(possibly in different ways) and needs to feel confident that there's not
some (rare) sequence of events that puts OpenStack as a whole into a bad
state because the events/workflows she configured have opposing goals.

The benefit of Congress is that there's one rich, declarative language that
operators can use to control the event-to-workflow mapping.  The operator
dictates which events/states (drawn from any collection of OpenStack
projects) should cause which workflows/templates/APIs (again from any
OpenStack project) to be executed.  And because the mapping is written
declaratively, it's feasible to do some conflict detection.

I'm not arguing that Mistral can't or shouldn't be adapted as was
suggested.  I'm just articulating what Congress brings to the table.

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] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

2015-11-09 Thread Tim Hinrichs

They shouldn't be combined because they can each be used without the
other.  That is, they each stand on their own.

Congress can be used for monitoring or delegating policy without attempting
to correct violations (i.e. without needing workflows).

Mistral can be used to make complex changes without writing a policy.

Tim





On Mon, Nov 9, 2015 at 8:57 AM Adam Young <ayo...@redhat.com> wrote:

> On 11/09/2015 10:57 AM, Tim Hinrichs wrote:
>
> Congress happens to have the capability to run a script/API call under
> arbitrary conditions on the state of other OpenStack projects, which
> sounded like what you wanted.  Or did I misread your original question?
>
> Congress and Mistral are definitely not competing.Congress lets
> people declare which states of the other OpenStack projects are permitted
> using a general purpose policy language, but it does not try to make
> complex changes (often requiring a workflow) to eliminate prohibited
> states.  Mistral lets people create a workflow that makes complex changes
> to other OpenStack projects, but it doesn't have a general purpose policy
> language that describes which states are permitted.  Congress and Mistral
> are complementary, and each can stand on its own.
>
>
> And why should not these two things be in a single project?
>
>
>
>
> Tim
>
>
> On Mon, Nov 9, 2015 at 6:46 AM Adam Young <ayo...@redhat.com> wrote:
>
>> On 11/06/2015 06:28 PM, Tim Hinrichs wrote:
>>
>> Congress allows users to write a policy that executes an action under
>> certain conditions.
>>
>> The conditions can be based on any data Congress has access to, which
>> includes nova servers, neutron networks, cinder storage, keystone users,
>> etc.  We also have some Ceilometer statistics; I'm not sure about whether
>> it's easy to get the Keystone notifications that you're talking about
>> today, but notifications are on our roadmap.  If the user's login is
>> reflected in the Keystone API, we may already be getting that event.
>>
>> The action could in theory be a mistral/heat API or an arbitrary script.
>> Right now we're set up to invoke any method on any of the python-clients
>> we've integrated with.  We've got an integration with heat but not
>> mistral.  New integrations are typically easy.
>>
>>
>> Sounds like Mistral and Congress are competing here, then.  Maybe we
>> should merge those efforts.
>>
>>
>>
>> Happy to talk more.
>>
>> Tim
>>
>>
>>
>> On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann <d...@doughellmann.com>
>> wrote:
>>
>>> Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:
>>> > On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann <d...@doughellmann.com>
>>> wrote:
>>> >
>>> > > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
>>> > > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
>>> > > > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
>>> > > > > > Can people help me work through the right set of tools for
>>> this use
>>> > > case
>>> > > > > > (has come up from several Operators) and map out a plan to
>>> implement
>>> > > it:
>>> > > > > >
>>> > > > > > Large cloud with many users coming from multiple Federation
>>> sources
>>> > > has
>>> > > > > > a policy of providing a minimal setup for each user upon first
>>> visit
>>> > > to
>>> > > > > > the cloud:  Create a project for the user with a minimal
>>> quota, and
>>> > > > > > provide them a role assignment.
>>> > > > > >
>>> > > > > > Here are the gaps, as I see it:
>>> > > > > >
>>> > > > > > 1.  Keystone provides a notification that a user has logged
>>> in, but
>>> > > > > > there is nothing capable of executing on this notification at
>>> the
>>> > > > > > moment.  Only Ceilometer listens to Keystone notifications.
>>> > > > > >
>>> > > > > > 2.  Keystone does not have a workflow engine, and should not be
>>> > > > > > auto-creating projects.  This is something that should be
>>> performed
>>> > > via
>>> > > > > > a Heat template, and Keystone does not know about Heat, nor
>>> sho

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

2015-11-09 Thread Tim Hinrichs

Congress happens to have the capability to run a script/API call under
arbitrary conditions on the state of other OpenStack projects, which
sounded like what you wanted.  Or did I misread your original question?

Congress and Mistral are definitely not competing.Congress lets people
declare which states of the other OpenStack projects are permitted using a
general purpose policy language, but it does not try to make complex
changes (often requiring a workflow) to eliminate prohibited states.
Mistral lets people create a workflow that makes complex changes to other
OpenStack projects, but it doesn't have a general purpose policy language
that describes which states are permitted.  Congress and Mistral are
complementary, and each can stand on its own.

Tim


On Mon, Nov 9, 2015 at 6:46 AM Adam Young <ayo...@redhat.com> wrote:

> On 11/06/2015 06:28 PM, Tim Hinrichs wrote:
>
> Congress allows users to write a policy that executes an action under
> certain conditions.
>
> The conditions can be based on any data Congress has access to, which
> includes nova servers, neutron networks, cinder storage, keystone users,
> etc.  We also have some Ceilometer statistics; I'm not sure about whether
> it's easy to get the Keystone notifications that you're talking about
> today, but notifications are on our roadmap.  If the user's login is
> reflected in the Keystone API, we may already be getting that event.
>
> The action could in theory be a mistral/heat API or an arbitrary script.
> Right now we're set up to invoke any method on any of the python-clients
> we've integrated with.  We've got an integration with heat but not
> mistral.  New integrations are typically easy.
>
>
> Sounds like Mistral and Congress are competing here, then.  Maybe we
> should merge those efforts.
>
>
>
> Happy to talk more.
>
> Tim
>
>
>
> On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann <d...@doughellmann.com>
> wrote:
>
>> Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:
>> > On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann <d...@doughellmann.com>
>> wrote:
>> >
>> > > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
>> > > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
>> > > > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
>> > > > > > Can people help me work through the right set of tools for this
>> use
>> > > case
>> > > > > > (has come up from several Operators) and map out a plan to
>> implement
>> > > it:
>> > > > > >
>> > > > > > Large cloud with many users coming from multiple Federation
>> sources
>> > > has
>> > > > > > a policy of providing a minimal setup for each user upon first
>> visit
>> > > to
>> > > > > > the cloud:  Create a project for the user with a minimal quota,
>> and
>> > > > > > provide them a role assignment.
>> > > > > >
>> > > > > > Here are the gaps, as I see it:
>> > > > > >
>> > > > > > 1.  Keystone provides a notification that a user has logged in,
>> but
>> > > > > > there is nothing capable of executing on this notification at
>> the
>> > > > > > moment.  Only Ceilometer listens to Keystone notifications.
>> > > > > >
>> > > > > > 2.  Keystone does not have a workflow engine, and should not be
>> > > > > > auto-creating projects.  This is something that should be
>> performed
>> > > via
>> > > > > > a Heat template, and Keystone does not know about Heat, nor
>> should
>> > > it.
>> > > > > >
>> > > > > > 3.  The Mapping code is pretty static; it assumes a user entry
>> or a
>> > > > > > group entry in identity when creating a role assignment, and
>> neither
>> > > > > > will exist.
>> > > > > >
>> > > > > > We can assume a special domain for Federated users to have
>> per-user
>> > > > > > projects.
>> > > > > >
>> > > > > > So; lets assume a Heat Template that does the following:
>> > > > > >
>> > > > > > 1. Creates a user in the per-user-projects domain
>> > > > > > 2. Assigns a role to the Federated user in that project
>> > > > > > 3. Sets the minimal quota for the user
&

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

2015-11-06 Thread Tim Hinrichs

Congress allows users to write a policy that executes an action under
certain conditions.

The conditions can be based on any data Congress has access to, which
includes nova servers, neutron networks, cinder storage, keystone users,
etc.  We also have some Ceilometer statistics; I'm not sure about whether
it's easy to get the Keystone notifications that you're talking about
today, but notifications are on our roadmap.  If the user's login is
reflected in the Keystone API, we may already be getting that event.

The action could in theory be a mistral/heat API or an arbitrary script.
Right now we're set up to invoke any method on any of the python-clients
we've integrated with.  We've got an integration with heat but not
mistral.  New integrations are typically easy.

Happy to talk more.

Tim



On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann  wrote:

> Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:
> > On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann 
> wrote:
> >
> > > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
> > > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
> > > > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
> > > > > > Can people help me work through the right set of tools for this
> use
> > > case
> > > > > > (has come up from several Operators) and map out a plan to
> implement
> > > it:
> > > > > >
> > > > > > Large cloud with many users coming from multiple Federation
> sources
> > > has
> > > > > > a policy of providing a minimal setup for each user upon first
> visit
> > > to
> > > > > > the cloud:  Create a project for the user with a minimal quota,
> and
> > > > > > provide them a role assignment.
> > > > > >
> > > > > > Here are the gaps, as I see it:
> > > > > >
> > > > > > 1.  Keystone provides a notification that a user has logged in,
> but
> > > > > > there is nothing capable of executing on this notification at the
> > > > > > moment.  Only Ceilometer listens to Keystone notifications.
> > > > > >
> > > > > > 2.  Keystone does not have a workflow engine, and should not be
> > > > > > auto-creating projects.  This is something that should be
> performed
> > > via
> > > > > > a Heat template, and Keystone does not know about Heat, nor
> should
> > > it.
> > > > > >
> > > > > > 3.  The Mapping code is pretty static; it assumes a user entry
> or a
> > > > > > group entry in identity when creating a role assignment, and
> neither
> > > > > > will exist.
> > > > > >
> > > > > > We can assume a special domain for Federated users to have
> per-user
> > > > > > projects.
> > > > > >
> > > > > > So; lets assume a Heat Template that does the following:
> > > > > >
> > > > > > 1. Creates a user in the per-user-projects domain
> > > > > > 2. Assigns a role to the Federated user in that project
> > > > > > 3. Sets the minimal quota for the user
> > > > > > 4. Somehow notifies the user that the project has been set up.
> > > > > >
> > > > > > This last probably assumes an email address from the Federated
> > > > > > assertion.  Otherwise, the user hits Horizon, gets a "not
> > > authenticated
> > > > > > for any projects" error, and is stumped.
> > > > > >
> > > > > > How is quota assignment done in the other projects now?  What
> happens
> > > > > > when a project is created in Keystone?  Does that information
> gets
> > > > > > transferred to the other services, and, if so, how?  Do most
> people
> > > use
> > > > > > a custom provisioning tool for this workflow?
> > > > > >
> > > > >
> > > > > I know at Dreamhost we built some custom integration that was
> triggered
> > > > > when someone turned on the Dreamcompute service in their account
> in our
> > > > > existing user management system. That integration created the
> account
> > > in
> > > > > keystone, set up a default network in neutron, etc. I've long
> thought
> > > we
> > > > > needed a "new tenant creation" service of some sort, that sits
> outside
> > > > > of our existing services and pokes them to do something when a new
> > > > > tenant is established. Using heat as the implementation makes
> sense,
> > > for
> > > > > things that heat can control, but we don't want keystone to depend
> on
> > > > > heat and we don't want to bake such a specialized feature into heat
> > > > > itself.
> > > > >
> > > >
> > > > I agree, an automation piece that is built-in and easy to add to
> > > > OpenStack would be great.
> > > >
> > > > I do not agree that it should be Heat. Heat is for managing stacks
> that
> > > > live on and change over time and thus need the complexity of the
> graph
> > > > model Heat presents.
> > > >
> > > > I'd actually say that Mistral or Ansible are better choices for
> this. A
> > > > service which listens to the notification bus and triggered a
> workflow
> > > > defined somewhere in either Ansible playbooks or Mistral's workflow
> > > > language would simply run through the "skel"

[openstack-dev] [Congress] Summit recap

2015-11-05 Thread Tim Hinrichs

Hi all,

It was great seeing so many Congress people in Tokyo last week!  Hopefully
you've all had a chance to recover by now.  Here's an overview of what
happened.  I was planning to go over this at this week's IRC meeting, but
forgot about the U.S. time change and missed the meeting--sorry about that.

1. Hands On Lab.   There were 40-50 people who attended, and all but 3-4 of
them got the VM we provided installed and worked through the lab.  1 of the
failures didn't have enough memory; 1 was something to do with VDX (?
Eric--is that right?); 1 was a version of Linux for which there wasn't a
VirtualBox installer.  The only weird problem was a glitch with the Horizon
interface that wouldn't show a table that we could show on the command
line.  Overall, people seemed to like Congress and what it had to offer.

2. Working session: distributed architecture
Base class is working with oslo-messaging, but unit tests are not working.
Peter is planning to debug and push to review in the next few weeks.

One thing we discussed was that the distributed architecture is only a
building block for an HA design.  But it does not deliver HA.  In
particular, for HA we will want to have multiple copies of the policy
engine, and these copies should be hidden from the user; the system should
take care of mapping an API call intended for the policy engine to one of
the copies.  The distributed architecture does not hide the existence of
multiple policy engines; rather, the user is responsible for spinning up
multiple policy engines, giving them different names, and directing API
requests to whichever one of the policy engines she wants to interact with.

3. Working session: infrastructure/testing
- We agreed to add Murano tests to our gate (as non-voting) to ensure that
we know when we add something to Congress that breaks Murano.  Should be
sufficient to simply copy their jenkins job into the Congress job-list and
make that job non-voting.

- We discussed the problem of datasource drivers, where to store them, and
how to test them.  Neutron has a similar issue with vendor-specific
plugins.  We thought it would be nice to have a separate requirements.txt
file for each driver; but then it is unclear how to test datasource drivers
in the gate because setup.py only installs the 1 requirements.txt in the
root directory.  So in the end, we decided the right thing was to have 1
requirements.txt file that includes all the dependencies for the OpenStack
drivers so that we can test those in the gate, and to have a separate
requirements.txt for each of the non-OpenStack drivers, since we can't test
those in the gate anyway.

4. Working session: Monasca and NFV.
- Fabio introduced us to Monasca, which is a monitoring project about to be
accepted into the BigTent.  It is an alternative to Ceilometer and focused
on high-performance.  They have alarms that can be set to inform the caller
any time a certain kind of event occurs.  Monasca is supposed to get a
superset of the data that Congress currently has drivers for.  They
suggested that Congress could automatically generate alarms based on the
data required by policy.  As a first step, we decided to write a simple
datasource driver to integrate with Monasca, as an easy way for the
Congress team to get familiar with Monasca.

- OPNFV Doctor project.  The Doctor project aims to detect and manage
faults in OPNFV platforms.  They hoped to use Congress to help identify
faults.  They wanted to connect Zabbix to Congress, which creates events
and have Congress push out config changes.  Concretely they asked for a
push-style datasource driver so that Zabbix could push data to Congress
through the API.  The blueprint for that work is here:
https://blueprints.launchpad.net/congress/+spec/push-type-datasource-driver

5. Discussion about Application-level Intent.

Outside the working sessions we talked with Ken Owens and his team about
application-level intent.  They are planning on building an
application-specific policy engine within the Congress framework.  For each
VM in an application, the user can rank the sensitivity of that VM as
low/medium/high for a handful of properties, e.g. latency, throughput.  The
provisioning system (which is external to Congress) then provisions the app
according to that policy, and the policy engine within Congress continually
monitors those properties and corrects violations.  The plan is to start
this as a completely standalone policy engine running a Congress node but
build it with an eye toward eventually delegating from the agnostic policy
engine to the application-intent engine.

6. Senlin project.  I heard about this project for the first time at the
summit.  It's policy-based cluster management.  Here's an email with more
details.

http://lists.openstack.org/pipermail/openstack-dev/2015-November/078498.html

It'd be great if those attended could respond with clarifications,
comments, and things I missed.

Let me know if anyone has questions/comments.
Tim

[openstack-dev] [Congress] IRC canceled during summit

2015-10-23 Thread Tim Hinrichs

As you might expect, next week's IRC is canceled since many of us will be
attending the Tokyo summit.

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

[openstack-dev] [Congress] Monasca @10a on Thu in Tokyo

2015-10-22 Thread Tim Hinrichs

Hi all,

At the summit next week, we're planning on a 10a meeting on Thursday with
the Monasca team for a deep dive.  All are welcome.

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 and Monasca Joint Session at Tokyo Design Summit

2015-10-19 Thread Tim Hinrichs

Fabio,

I haven't heard back on this so I'm assuming Wed 3:40-4:20 works for you.

Tim


On Wed, Oct 14, 2015 at 10:51 AM Tim Hinrichs <t...@styra.com> wrote:

> Hi Fabio,
>
> We now have a schedule.  I've tentatively booked you for half of our slot
> Wed 3:40-4:20.  Does that work for your team?  You can find the other
> options at...
>
> https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress
>
> Tim
>
>
> On Thu, Oct 1, 2015 at 2:06 PM Fabio Giannetti (fgiannet) <
> fgian...@cisco.com> wrote:
>
>> Thanks a lot Tim.
>> I really appreciate.
>> Fabio
>>
>> From: Tim Hinrichs <t...@styra.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: Thursday, October 1, 2015 at 7:40 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Congress] Congress and Monasca Joint
>> Session at Tokyo Design Summit
>>
>> Hi Fabio,
>>
>> The Congress team talked this over during our IRC yesterday.  It looks
>> like can meet with your team during one of our meeting slots.  As far as I
>> know the schedule for those meetings hasn't been set.  But once it is I'll
>> reach out (or you can) to discuss the day/time.
>>
>> Tim
>>
>> On Mon, Sep 28, 2015 at 2:51 PM Tim Hinrichs <t...@styra.com> wrote:
>>
>>>
>>> Hi Fabio: Thanks for reaching out.  We should definitely talk at the
>>> summit.  I don't know if we can devote 1 of the 3 allocated Congress
>>> sessions to Monasca, but we'll talk it over during IRC on Wed and let you
>>> know.  Or do you have a session we could use for the discussion?  In any
>>> case, I'm confident we can make good progress toward integrating Congress
>>> and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
>>> learning more!
>>>
>>> Congress team: if we could all quickly browse the Monasca wiki before
>>> Wed's IRC, that would be great:
>>> https://wiki.openstack.org/wiki/Monasca
>>>
>>> Tim
>>>
>>>
>>>
>>> On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
>>> fgian...@cisco.com> wrote:
>>>
>>>> Tim and Congress folks,
>>>>   I am writing on behalf of the Monasca community and I would like to
>>>> explore the possibility of holding a joint session during the Tokyo Design
>>>> Summit.
>>>> We would like to explore:
>>>>
>>>>1. how to integrate Monasca with Congress so then Monasca can
>>>>provide metrics, logs and event data for policy evaluation/enforcement
>>>>2. How to leverage Monasca alarming to automatically notify about
>>>>statuses that may imply policy breach
>>>>3. How to automatically (if possible) convert policies (or
>>>>subparts) into Monasca alarms.
>>>>
>>>> Please point me to a submission page if I have to create a formal
>>>> proposal for the topic and/or let me know other forms we can interact at
>>>> the Summit.
>>>> Thanks in advance,
>>>> Fabio
>>>>
>>>> *Fabio Giannetti*
>>>> Cloud Innovation Architect
>>>> Cisco Services
>>>> fgian...@cisco.com
>>>> Phone: *+1 408 527 1134*
>>>> Mobile: *+1 408 854 0020*
>>>>
>>>> *Cisco Systems, Inc.*
>>>> 285 W. Tasman Drive
>>>> San Jose
>>>> California
>>>> 95134
>>>> United States
>>>> Cisco.com <http://www.cisco.com/>
>>>>
>>>>  Think before you print.
>>>>
>>>> This email may contain confidential and privileged material for the
>>>> sole use of the intended recipient. Any review, use, distribution or
>>>> disclosure by others is strictly prohibited. If you are not the intended
>>>> recipient (or authorized to receive for the recipient), please contact the
>>>> sender by reply email and delete all copies of this message.
>>>>
>>>> Please click here
>>>> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
>>>> Company Registration Information.
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing 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] [Congress] Tokyo summit schedule

2015-10-14 Thread Tim Hinrichs

Hi all,

I put a tentative schedule online for the Tokyo summit.  If there are
things you'd like to discuss that aren't on there, let me know.

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress

Masahito: could you reach out to the OPNFV people that wanted to talk about
their use cases and see if the schedule works for them?

I'll reach out to the Monasca team and check with them as well.

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 and Monasca Joint Session at Tokyo Design Summit

2015-10-14 Thread Tim Hinrichs

Hi Fabio,

We now have a schedule.  I've tentatively booked you for half of our slot
Wed 3:40-4:20.  Does that work for your team?  You can find the other
options at...

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress

Tim


On Thu, Oct 1, 2015 at 2:06 PM Fabio Giannetti (fgiannet) <
fgian...@cisco.com> wrote:

> Thanks a lot Tim.
> I really appreciate.
> Fabio
>
> From: Tim Hinrichs <t...@styra.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, October 1, 2015 at 7:40 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Congress] Congress and Monasca Joint
> Session at Tokyo Design Summit
>
> Hi Fabio,
>
> The Congress team talked this over during our IRC yesterday.  It looks
> like can meet with your team during one of our meeting slots.  As far as I
> know the schedule for those meetings hasn't been set.  But once it is I'll
> reach out (or you can) to discuss the day/time.
>
> Tim
>
> On Mon, Sep 28, 2015 at 2:51 PM Tim Hinrichs <t...@styra.com> wrote:
>
>>
>> Hi Fabio: Thanks for reaching out.  We should definitely talk at the
>> summit.  I don't know if we can devote 1 of the 3 allocated Congress
>> sessions to Monasca, but we'll talk it over during IRC on Wed and let you
>> know.  Or do you have a session we could use for the discussion?  In any
>> case, I'm confident we can make good progress toward integrating Congress
>> and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
>> learning more!
>>
>> Congress team: if we could all quickly browse the Monasca wiki before
>> Wed's IRC, that would be great:
>> https://wiki.openstack.org/wiki/Monasca
>>
>> Tim
>>
>>
>>
>> On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
>> fgian...@cisco.com> wrote:
>>
>>> Tim and Congress folks,
>>>   I am writing on behalf of the Monasca community and I would like to
>>> explore the possibility of holding a joint session during the Tokyo Design
>>> Summit.
>>> We would like to explore:
>>>
>>>1. how to integrate Monasca with Congress so then Monasca can
>>>provide metrics, logs and event data for policy evaluation/enforcement
>>>2. How to leverage Monasca alarming to automatically notify about
>>>statuses that may imply policy breach
>>>3. How to automatically (if possible) convert policies (or subparts)
>>>into Monasca alarms.
>>>
>>> Please point me to a submission page if I have to create a formal
>>> proposal for the topic and/or let me know other forms we can interact at
>>> the Summit.
>>> Thanks in advance,
>>> Fabio
>>>
>>> *Fabio Giannetti*
>>> Cloud Innovation Architect
>>> Cisco Services
>>> fgian...@cisco.com
>>> Phone: *+1 408 527 1134*
>>> Mobile: *+1 408 854 0020*
>>>
>>> *Cisco Systems, Inc.*
>>> 285 W. Tasman Drive
>>> San Jose
>>> California
>>> 95134
>>> United States
>>> Cisco.com <http://www.cisco.com/>
>>>
>>>  Think before you print.
>>>
>>> This email may contain confidential and privileged material for the sole
>>> use of the intended recipient. Any review, use, distribution or disclosure
>>> by others is strictly prohibited. If you are not the intended recipient (or
>>> authorized to receive for the recipient), please contact the sender by
>>> reply email and delete all copies of this message.
>>>
>>> Please click here
>>> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
>>> Company Registration Information.
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] Tokyo sessions

2015-10-08 Thread Tim Hinrichs

Rui is right.  Below I expanded on the short description Rui provided above.

Discussions with external teams: OPNFV, Monasca
Integration with other projects: congress gating (nova, neutron, etc.),
devstack plugin, keystone
Distributed architecture and additional features for M

Tim


On Wed, Oct 7, 2015 at 8:03 PM Rui Chen <chenrui.m...@gmail.com> wrote:

> In my memory, there are 4 topics about OPNFV, congress gating,
> distributed arch, Monasca.
>
> Some details in IRC meeting log
>
> http://eavesdrop.openstack.org/meetings/congressteammeeting/2015/congressteammeeting.2015-10-01-00.01.log.html
>
> 2015-10-08 9:48 GMT+08:00 zhangyali (D) <zhangyali...@huawei.com>:
>
>> Hi Tim,
>>
>>
>>
>> Thanks for informing the meeting information. But does the meeting have
>> some topics scheduled? I think it’s better to know what we are going to
>> talk. Thanks so much!
>>
>>
>>
>> Yali
>>
>>
>>
>> *发件人:* Tim Hinrichs [mailto:t...@styra.com]
>> *发送时间:* 2015年10月2日 2:52
>> *收件人:* OpenStack Development Mailing List (not for usage questions)
>> *主题:* [openstack-dev] [Congress] Tokyo sessions
>>
>>
>>
>> Hi all,
>>
>>
>>
>> We just got a tentative assignment for our meeting times in Tokyo.  Our 3
>> meetings are scheduled back-to-back-to-back on Wed afternoon from
>> 2:00-4:30p.  I don't think there's much chance of getting the meetings
>> moved, but does anyone have a hard conflict?
>>
>>
>>
>> Here's our schedule for Wed:
>>
>>
>>
>> Wed 11:15-12:45 HOL
>>
>> Wed 2:00-2:40 Working meeting
>>
>> Wed 2:50-3:30 Working meeting
>>
>> Wed 3:40-4:20 Working meeting
>>
>>
>>
>> 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
>>
>>
> __
> OpenStack Development Mailing 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] Couple new bugs for liberty

2015-10-06 Thread Tim Hinrichs

Hi all,

Another round of manual testing revealed a couple more bugs.  The ones at
the bottom without the Fix-committed:

https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc2

I have a patch for 1503392 in review.

It'd be great if someone could pick up
https://bugs.launchpad.net/congress/+bug/1503443

After that, I think we'll be about done with liberty.

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 and Monasca Joint Session at Tokyo Design Summit

2015-10-01 Thread Tim Hinrichs

Hi Fabio,

The Congress team talked this over during our IRC yesterday.  It looks like
can meet with your team during one of our meeting slots.  As far as I know
the schedule for those meetings hasn't been set.  But once it is I'll reach
out (or you can) to discuss the day/time.

Tim

On Mon, Sep 28, 2015 at 2:51 PM Tim Hinrichs <t...@styra.com> wrote:

>
> Hi Fabio: Thanks for reaching out.  We should definitely talk at the
> summit.  I don't know if we can devote 1 of the 3 allocated Congress
> sessions to Monasca, but we'll talk it over during IRC on Wed and let you
> know.  Or do you have a session we could use for the discussion?  In any
> case, I'm confident we can make good progress toward integrating Congress
> and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
> learning more!
>
> Congress team: if we could all quickly browse the Monasca wiki before
> Wed's IRC, that would be great:
> https://wiki.openstack.org/wiki/Monasca
>
> Tim
>
>
>
> On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
> fgian...@cisco.com> wrote:
>
>> Tim and Congress folks,
>>   I am writing on behalf of the Monasca community and I would like to
>> explore the possibility of holding a joint session during the Tokyo Design
>> Summit.
>> We would like to explore:
>>
>>1. how to integrate Monasca with Congress so then Monasca can provide
>>metrics, logs and event data for policy evaluation/enforcement
>>2. How to leverage Monasca alarming to automatically notify about
>>statuses that may imply policy breach
>>3. How to automatically (if possible) convert policies (or subparts)
>>into Monasca alarms.
>>
>> Please point me to a submission page if I have to create a formal
>> proposal for the topic and/or let me know other forms we can interact at
>> the Summit.
>> Thanks in advance,
>> Fabio
>>
>> *Fabio Giannetti*
>> Cloud Innovation Architect
>> Cisco Services
>> fgian...@cisco.com
>> Phone: *+1 408 527 1134*
>> Mobile: *+1 408 854 0020*
>>
>> *Cisco Systems, Inc.*
>> 285 W. Tasman Drive
>> San Jose
>> California
>> 95134
>> United States
>> Cisco.com <http://www.cisco.com/>
>>
>>  Think before you print.
>>
>> This email may contain confidential and privileged material for the sole
>> use of the intended recipient. Any review, use, distribution or disclosure
>> by others is strictly prohibited. If you are not the intended recipient (or
>> authorized to receive for the recipient), please contact the sender by
>> reply email and delete all copies of this message.
>>
>> Please click here
>> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
>> Company Registration Information.
>>
>> __
>> OpenStack Development Mailing 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] Tokyo sessions

2015-10-01 Thread Tim Hinrichs

Hi all,

We just got a tentative assignment for our meeting times in Tokyo.  Our 3
meetings are scheduled back-to-back-to-back on Wed afternoon from
2:00-4:30p.  I don't think there's much chance of getting the meetings
moved, but does anyone have a hard conflict?

Here's our schedule for Wed:

Wed 11:15-12:45 HOL
Wed 2:00-2:40 Working meeting
Wed 2:50-3:30 Working meeting
Wed 3:40-4:20 Working meeting

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 Usecases VM

2015-09-30 Thread Tim Hinrichs

stantiates the Usecase-VM. However creating a OVA file is possible only
> when the VM is halted which means Openstack is not running and the user
> will have to run devstack again (which is time consuming) when the VM is
> restarted.
>
>
>
> The option is to take a snapshot. It appears that taking a snapshot of the
> VM and using it in another setup is not very straight forward. It involves
> modifying the .vbox file and seems that it is prone to user errors. I am
> leaning towards halting the machine and generating an OVA file.
>
>
>
> I am looking for suggestions ….
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com <sha...@brocade.com>]
> *Sent:* Thursday, September 24, 2015 9:53 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> First of all I apologize for not making it at the meeting yesterday, could
> not cut short another overlapping meeting.
>
>
>
> Also, Tim thanks for the feedback. I have addressed some of the issues you
> posed however I am still working on some of the subtle issues raised. Once
> I have addressed all I will post another VM by end of the week.
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Tim Hinrichs [mailto:t...@styra.com <t...@styra.com>]
> *Sent:* Friday, September 18, 2015 5:14 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> It's great to have this available!  I think it'll help people understand
> what's going on MUCH more quickly.
>
>
>
> Some thoughts.
>
> - The image is 3GB, which took me 30 minutes to download.  Are all VMs
> this big?  I think we should finish this as a VM but then look into doing
> it with containers to make it EVEN easier for people to get started.
>
>
>
> [shivharis] Yes, unfortunately that is the case. The disk size I set is
> 20GB – but the OVA compress the image and disk to 3 GB. I will looking at
> other options.
>
>
>
>
>
> - It gave me an error about a missing shared directory when I started up.
>
> [shivharis] will fix this
>
>
>
> - I expected devstack to be running when I launched the VM.  devstack
> startup time is substantial, and if there's a problem, it's good to assume
> the user won't know how to fix it.  Is it possible to have devstack up and
> running when we start the VM?  That said, it started up fine for me.
>
> [shivharis] OVA files can be created only when the VM is halted, so
> devstack will be down when you bring up  the VM. I agree a snapshot will be
> a better choice.
>
>
>
> - It'd be good to have a README to explain how to use the use-case
> structure. It wasn't obvious to me.
>
> [shivharis] added.
>
>
>
> - The top-level dir of the Congress_Usecases folder has a
> Congress_Usecases folder within it.  I assume the inner one shouldn't be
> there?
>
> [shivharis] my automation issues, fixed.
>
>
>
> - When I ran the 10_install_policy.sh, it gave me a bunch of authorization
> problems.
>
> [shivharis] fixed
>
>
>
> But otherwise I think the setup looks reasonable.  Will there be an undo
> script so that we can run the use cases one after another without worrying
> about interactions?
>
> [shivharis] tricky, will find some way out.
>
>
>
> Tim
>
>
>
> [shivharis] Thanks
>
>
>
> On Fri, Sep 18, 2015 at 11:03 AM Shiv Haris <sha...@brocade.com> wrote:
>
> Hi Congress folks,
>
>
>
> BTW the login/password for the VM is vagrant/vagrant
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com]
> *Sent:* Thursday, September 17, 2015 5:03 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Hi All,
>
>
>
> I have put my VM (virtualbox) at:
>
>
>
> http://paloaltan.net/Congress/Congress_Usecases_SEPT_17_2015.ova
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__paloaltan.net_Congress_Congress-5FUsecases-5FSEPT-5F17-5F2015.ova=BQMGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=djA1lFdIf0--GIJ_8gr44Q=3IP4igrLri-BaK8VbjbEq2l_AGknCI7-t3UbP5VwlU8=wVyys8I915mHTzrOp8f0KLqProw6ygNfaMSP0T-yqCg=>
>
>
>
> I usually run this on a macbook air – but it should work on other
> platfroms as well. I chose virtualbox since it is free.
>
>
>
> Please send me your usecases – I can incorporate in the VM and send you an
> updated image. Please take a look at the structure I have in place for the
> first usecase; would prefer it be the same for other usecases. (However I
> am still open to suggestions for changes)
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
>
> __
> OpenStack Development Mailing 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] hands on lab

2015-09-28 Thread Tim Hinrichs

Hi Alex,

I went through the HOL.  Some feedback...

1.  When starting up, it paused for a while showing the following
messages.  Maybe that caused the issues I mention below.
Waiting for network configuration...
Waiting up to 60 more seconds for network configuration...

2.  Maybe spell out the first paragraph of "Starting the Devstack VM".
Maybe something like

To run the devstack VM, first install VirtualBox.  Then download the image
from XXX and start the VM.  (From VirtualBox's File menu, Import Appliance
and then choose the file you downloaded.)

Now you'll want to ssh to the VM from your laptop so it's easier to copy
and paste.  (The VM is setup to use bridge networking with DHCP.) To find
the IP address, login to the VM through the console.

username: congress
password: congress

Run ‘ifconfig’ to get the IP address of the VM for eth0

$ ifconfig eth0

Now open a terminal from your laptop and ssh to that IP address using the
same username and password from above.

Now that devstack is running, you can point your laptop's browser to the
VM's IP address you found earlier to use Horizon.

 3. Connection problems.
Horizon.  The browser brought up the login screen but gave me the message
"Unable to establish connection to keystone endpoint." after I provided
admin/password.

Congress.  From the congress log I see connection errors happening for
keystone and neutron.

Looking at the Keystone screen log I don't see much of anything.  Here's
the API log in its entirety.  Seems it hasn't gotten any requests today
(Sept 28).

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 52799(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 65278(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 63428(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 135994(us)

10.1.184.61 - - [17/Sep/2015:12:05:09 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 56581(us)

10.1.184.61 - - [17/Sep/2015:12:05:09 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 55412(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/users HTTP/1.1" 200
1679 "-" "python-keystoneclient" 13630(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/OS-KSADM/roles
HTTP/1.1" 200 397 "-" "python-keystoneclient" 10940(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/tenants HTTP/1.1"
200 752 "-" "python-keystoneclient" 12387(us)

The VM has eth0 bridged.  I can ping google.com from inside the VM; I can
ssh to the VM from my laptop.

Any ideas what's going on?  (I'm trying to unstack/clean/stack to see if
that works, but it'll take a while.)

Tim

On Thu, Sep 17, 2015 at 6:05 PM Alex Yip  wrote:

> Hi all,
> I have created a VirtualBox VM that matches the Vancouver handson-lab here:
>
>
> https://drive.google.com/file/d/0B94E7u1TIA8oTEdOQlFERkFwMUE/view?usp=sharing
>
> There's also an updated instruction document here:
>
>
> https://docs.google.com/document/d/1ispwf56bX8sy9T0KZyosdHrSR9WHEVA1oGEIYA22Orw/pub
>
> If you have some time, please try it out to see if it all works as
> expected.
> thanks, Alex
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Congress Usecases VM

2015-09-28 Thread Tim Hinrichs

When I tried to import the image, it gave me an error.


Could not create the imported medium
'/Users/tim/VirtualBox
VMs/Congress_Usecases/Congress_Usecases_SEPT_25_2015-disk1.vmdk'
.

VMDK: Compressed image is corrupted
'/Congress_Usecases_SEPT_25_2015-disk1.vmdk' (VERR_ZIP_CORRUPTED).


Tim



On Fri, Sep 25, 2015 at 3:38 PM Shiv Haris <sha...@brocade.com> wrote:

> Thanks Alex, Zhou,
>
>
>
> I get errors from congress when I do a re-join. These errors seem to due
> to the order in which the services are coming up. Hence I still depend on
> running stack.sh after the VM is up and running. Please try out the new VM
> – also advise if you need to add any of your use cases. Also re-join starts
> “screen” – do we expect the end user to know how to use “screen”.
>
>
>
> I do understand that running “stack.sh” takes time to run – but it does
> not do things that appear to be any kind of magic which we want to avoid in
> order to get the user excited.
>
>
>
> I have uploaded a new version of the VM please experiment with this and
> let me know:
>
>
>
> http://paloaltan.net/Congress/Congress_Usecases_SEPT_25_2015.ova
>
>
>
> (root: vagrant password: vagrant)
>
>
>
> -Shiv
>
>
>
>
>
>
>
> *From:* Alex Yip [mailto:a...@vmware.com]
> *Sent:* Thursday, September 24, 2015 5:09 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> I was able to make devstack run without a network connection by disabling
> tempest.  So, I think it uses the loopback IP address, and that does not
> change, so rejoin-stack.sh works without a network at all.
>
>
>
> - Alex
>
>
>
>
> --
>
> *From:* Zhou, Zhenzan <zhenzan.z...@intel.com>
> *Sent:* Thursday, September 24, 2015 4:56 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Rejoin-stack.sh works only if its IP was not changed. So using NAT network
> and fixed ip inside the VM can help.
>
>
>
> BR
>
> Zhou Zhenzan
>
>
>
> *From:* Alex Yip [mailto:a...@vmware.com <a...@vmware.com>]
> *Sent:* Friday, September 25, 2015 01:37
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> I have been using images, rather than snapshots.
>
>
>
> It doesn't take that long to start up.  First, I boot the VM which takes a
> minute or so.  Then I run rejoin-stack.sh which takes just another minute
> or so.  It's really not that bad, and rejoin-stack.sh restores vms and
> openstack state that was running before.
>
>
>
> - Alex
>
>
>
>
> --
>
> *From:* Shiv Haris <sha...@brocade.com>
> *Sent:* Thursday, September 24, 2015 10:29 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Hi Congress folks,
>
>
>
> I am looking for ideas. We want the Openstack to be running when the user
> instantiates the Usecase-VM. However creating a OVA file is possible only
> when the VM is halted which means Openstack is not running and the user
> will have to run devstack again (which is time consuming) when the VM is
> restarted.
>
>
>
> The option is to take a snapshot. It appears that taking a snapshot of the
> VM and using it in another setup is not very straight forward. It involves
> modifying the .vbox file and seems that it is prone to user errors. I am
> leaning towards halting the machine and generating an OVA file.
>
>
>
> I am looking for suggestions ….
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com <sha...@brocade.com>]
> *Sent:* Thursday, September 24, 2015 9:53 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> First of all I apologize for not making it at the meeting yesterday, could
> not cut short another overlapping meeting.
>
>
>
> Also, Tim thanks for the feedback. I have addressed some of the issues you
> posed however I am still working on some of the subtle issues raised. Once
> I have addressed all I will post another VM by end of the week.
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Tim Hinrichs [mailto:t...@styra.com <t...@styra.com>]
> *Sent:* Friday, September 18, 2015 5:14 PM
> *To:* OpenStack Development Mail

Re: [openstack-dev] [Congress] Congress and Monasca Joint Session at Tokyo Design Summit

2015-09-28 Thread Tim Hinrichs

Hi Fabio: Thanks for reaching out.  We should definitely talk at the
summit.  I don't know if we can devote 1 of the 3 allocated Congress
sessions to Monasca, but we'll talk it over during IRC on Wed and let you
know.  Or do you have a session we could use for the discussion?  In any
case, I'm confident we can make good progress toward integrating Congress
and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
learning more!

Congress team: if we could all quickly browse the Monasca wiki before Wed's
IRC, that would be great:
https://wiki.openstack.org/wiki/Monasca

Tim



On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
fgian...@cisco.com> wrote:

> Tim and Congress folks,
>   I am writing on behalf of the Monasca community and I would like to
> explore the possibility of holding a joint session during the Tokyo Design
> Summit.
> We would like to explore:
>
>1. how to integrate Monasca with Congress so then Monasca can provide
>metrics, logs and event data for policy evaluation/enforcement
>2. How to leverage Monasca alarming to automatically notify about
>statuses that may imply policy breach
>3. How to automatically (if possible) convert policies (or subparts)
>into Monasca alarms.
>
> Please point me to a submission page if I have to create a formal proposal
> for the topic and/or let me know other forms we can interact at the Summit.
> Thanks in advance,
> Fabio
>
> *Fabio Giannetti*
> Cloud Innovation Architect
> Cisco Services
> fgian...@cisco.com
> Phone: *+1 408 527 1134*
> Mobile: *+1 408 854 0020*
>
> *Cisco Systems, Inc.*
> 285 W. Tasman Drive
> San Jose
> California
> 95134
> United States
> Cisco.com 
>
>  Think before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Please click here
>  for
> Company Registration Information.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress] Congress Usecases VM

2015-09-21 Thread Tim Hinrichs

Did the client install properly?  Then you can use ...

$ openstack help congress

Tim

On Sun, Sep 20, 2015 at 12:35 AM himanshu sharma <him.fun...@gmail.com>
wrote:

> Hi,
>
> Greetings for the day.
>
> I am finding problem in finding the CLI commands for congress in which I
> can create, delete a rule within a policy and viewing different data
> sources.
> Can you please provide me the list of CLI commands for the same.
> Waiting for the reply.
>
>
> Regards
> Himanshu Sharma
>
> On Sat, Sep 19, 2015 at 5:44 AM, Tim Hinrichs <t...@styra.com> wrote:
>
>> It's great to have this available!  I think it'll help people understand
>> what's going on MUCH more quickly.
>>
>> Some thoughts.
>> - The image is 3GB, which took me 30 minutes to download.  Are all VMs
>> this big?  I think we should finish this as a VM but then look into doing
>> it with containers to make it EVEN easier for people to get started.
>>
>> - It gave me an error about a missing shared directory when I started up.
>>
>> - I expected devstack to be running when I launched the VM.  devstack
>> startup time is substantial, and if there's a problem, it's good to assume
>> the user won't know how to fix it.  Is it possible to have devstack up and
>> running when we start the VM?  That said, it started up fine for me.
>>
>> - It'd be good to have a README to explain how to use the use-case
>> structure. It wasn't obvious to me.
>>
>> - The top-level dir of the Congress_Usecases folder has a
>> Congress_Usecases folder within it.  I assume the inner one shouldn't be
>> there?
>>
>> - When I ran the 10_install_policy.sh, it gave me a bunch of
>> authorization problems.
>>
>> But otherwise I think the setup looks reasonable.  Will there be an undo
>> script so that we can run the use cases one after another without worrying
>> about interactions?
>>
>> Tim
>>
>>
>> On Fri, Sep 18, 2015 at 11:03 AM Shiv Haris <sha...@brocade.com> wrote:
>>
>>> Hi Congress folks,
>>>
>>>
>>>
>>> BTW the login/password for the VM is vagrant/vagrant
>>>
>>>
>>>
>>> -Shiv
>>>
>>>
>>>
>>>
>>>
>>> *From:* Shiv Haris [mailto:sha...@brocade.com]
>>> *Sent:* Thursday, September 17, 2015 5:03 PM
>>> *To:* openstack-dev@lists.openstack.org
>>> *Subject:* [openstack-dev] [Congress] Congress Usecases VM
>>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> I have put my VM (virtualbox) at:
>>>
>>>
>>>
>>> http://paloaltan.net/Congress/Congress_Usecases_SEPT_17_2015.ova
>>>
>>>
>>>
>>> I usually run this on a macbook air – but it should work on other
>>> platfroms as well. I chose virtualbox since it is free.
>>>
>>>
>>>
>>> Please send me your usecases – I can incorporate in the VM and send you
>>> an updated image. Please take a look at the structure I have in place for
>>> the first usecase; would prefer it be the same for other usecases. (However
>>> I am still open to suggestions for changes)
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -Shiv
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] stable/kilo

2015-09-21 Thread Tim Hinrichs

Could someone look into why we can't get this change to merge into
stable/kilo.  Note that kilo was last cycle's release.

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

I tried a couple of obvious things but still no luck:
https://review.openstack.org/#/c/225332/

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 Usecases VM

2015-09-18 Thread Tim Hinrichs

It's great to have this available!  I think it'll help people understand
what's going on MUCH more quickly.

Some thoughts.
- The image is 3GB, which took me 30 minutes to download.  Are all VMs this
big?  I think we should finish this as a VM but then look into doing it
with containers to make it EVEN easier for people to get started.

- It gave me an error about a missing shared directory when I started up.

- I expected devstack to be running when I launched the VM.  devstack
startup time is substantial, and if there's a problem, it's good to assume
the user won't know how to fix it.  Is it possible to have devstack up and
running when we start the VM?  That said, it started up fine for me.

- It'd be good to have a README to explain how to use the use-case
structure. It wasn't obvious to me.

- The top-level dir of the Congress_Usecases folder has a Congress_Usecases
folder within it.  I assume the inner one shouldn't be there?

- When I ran the 10_install_policy.sh, it gave me a bunch of authorization
problems.

But otherwise I think the setup looks reasonable.  Will there be an undo
script so that we can run the use cases one after another without worrying
about interactions?

Tim


On Fri, Sep 18, 2015 at 11:03 AM Shiv Haris  wrote:

> Hi Congress folks,
>
>
>
> BTW the login/password for the VM is vagrant/vagrant
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com]
> *Sent:* Thursday, September 17, 2015 5:03 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Hi All,
>
>
>
> I have put my VM (virtualbox) at:
>
>
>
> http://paloaltan.net/Congress/Congress_Usecases_SEPT_17_2015.ova
>
>
>
> I usually run this on a macbook air – but it should work on other
> platfroms as well. I chose virtualbox since it is free.
>
>
>
> Please send me your usecases – I can incorporate in the VM and send you an
> updated image. Please take a look at the structure I have in place for the
> first usecase; would prefer it be the same for other usecases. (However I
> am still open to suggestions for changes)
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
> __
> OpenStack Development Mailing 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] PTL candidacy

2015-09-15 Thread Tim Hinrichs

Hi all,

I’m writing to announce my candidacy for Congress PTL for the Mitaka
cycle.  I’m excited at the prospect of continuing the development of our
community, our code base, and our integrations with other projects.

This past cycle has been exciting in that we saw several new, consistent
contributors, who actively pushed code, submitted reviews, wrote specs, and
participated in the mid-cycle meet-up.  Additionally, our integration with
the rest of the OpenStack ecosystem improved with our move to running
tempest tests in the gate instead of manually or with our own CI.  The code
base matured as well, as we rounded out some of the features we added near
the end of the Kilo cycle.  We also began making the most significant
architectural change in the project’s history, in an effort meet our
high-availability and API throughput targets.

I’m looking forward to the Mitaka cycle.  My highest priority for the code
base is completing the architectural changes that we began in Liberty.
These changes are undoubtedly the right way forward for production use
cases, but it is equally important that we make Congress easy to use and
understand for both new developers and new end users.  I also plan to
further our integration with the OpenStack ecosystem by better utilizing
the plugin architectures that are available (e.g. devstack and tempest).  I
will also work to begin (or continue) dialogues with other projects that
might benefit from consuming Congress.  Finally I’m excited to continue
working with our newest project members, helping them toward becoming core
contributors.

See you all in Tokyo!
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] IRC hangout

2015-09-14 Thread Tim Hinrichs

Hi Shiv,

Our IRC is #congress.

Tim

On Mon, Sep 14, 2015 at 10:45 AM Shiv Haris  wrote:

> Hi,
>
>
>
> What is the IRC channel where congress folks hangout. I  tried
> #openstack-congress on freenode but is seems not correct.
>
>
>
> -Shiv
>
>
>
>
>
>
>
> *From:* Su Zhang [mailto:westlif...@gmail.com]
> *Sent:* Tuesday, August 25, 2015 5:17 PM
> *To:* openstack-dev
> *Subject:* [openstack-dev] [congress] simulation example in the doc not
> working
>
>
>
> Hello,
>
>
>
> In simulation examples at
> http://congress.readthedocs.org/en/latest/enforcement.html?highlight=simulation
> ,
>
> the "action_policy" is replaced with "null". However, "null" is not
> considered as a valid policy as I keep receiving 400 errors.
>
> Could someone let me know the easiest way to get around this error?
>
> How to create a simple action policy just for test purpose as of now?
>
>
>
> Thanks,
>
>
>
> --
>
> Su Zhang
> __
> OpenStack Development Mailing 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] Ending feature freeze

2015-09-10 Thread Tim Hinrichs

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  in the commit msg
$ git cherry-pick -x 

// 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
__
OpenStack Development Mailing 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] bugs for liberty release

2015-09-04 Thread Tim Hinrichs

Hi all,

I've found a few bugs that we could/should fix by the liberty release.  I
tagged them with "liberty-rc".  If we could all pitch in, that'd be great.
Let me know which ones you'd like to work on so I can assign them to you in
launchpad.

https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc

Thanks,
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

[openstack-dev] [Congress] Feedback on distributed architecture

2015-09-02 Thread Tim Hinrichs

I ran the basics of our new distributed architecture by Shawn from
Twitter.  Here's his response.


 We just held a Congress mid-cycle meet-up to discuss its distributed
architecture.  We decided on an architecture where the policy engine runs
in its own process; each datasource driver runs in its own process; the API
runs in its own process; and all communicate over a RabbitMQ-style message
bus.

This would enable you to choose which part of Congress you run on which
physical host.  You could run the policy engine on the same box as the
service you're using policy to protect.  You can build the datasource
driver logic into a datasource and push deltas directly to the RabbitMQ
message bus.  And of course you could run everything on a
Congress-dedicated box and ignore these details.

See any major problems with Congress's new distributed architecture, or
things you think should change?  Do you think that running the policy
engine on the same box as the service you're protecting is a good idea or a
bad one?

I suspect RabbitMQ may end up being a bottleneck but it makes sense
to deal with that when it comes up. Will you be relying on
RabbitMQ-specific features or will any given AMQP broker suffice? Which
version of AMQP will you be using?


OpenStack has a wrapper around AMQP buses, and we're using that.  We
haven't gone any further into choices about which plugin to use.

I think the choice of where to run the datasource makes sense,
though I need to give some thought to wiring up my datasources directly to
the AMQP broker instead of submitting via a well-defined REST or thrift API
with realtime payload validation, backpressure, etc. I can't tell whether
my hesitation is legit or just FUD.

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] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs

2015-08-27 Thread Tim Hinrichs

I pushed a patch for Congress dependent on your patch.

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

Tim


On Thu, Aug 27, 2015 at 8:05 AM Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi,

 I think filing the cross-project bug is ok. I've already uploaded patch
 for sahara jobs - https://review.openstack.org/217751

 Thanks.

 On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent chd...@redhat.com wrote:


 [If any of this is wrong I hope someone from infra or qa will
 correct me. Thanks. This feels a bit cumbersome so perhaps there is
 a way to do it in a more automagic fashion[1].]

 In the near future ceilometer will be removing itself from the core
 of devstack and using a plugin instead. This is to allow more
 independent control and flexibility.

 These are the related reviews:

 * remove from devstack: https://review.openstack.org/196383
 * updated jenkins jobs: https://review.openstack.org/196446

 If a project is using ceilometer in its gate jobs then before the
 above can merge adjustments need to be made to make sure that the
 ceilometer plugin is enabled. The usual change for this would be a
 form of:

   DEVSTACK_LOCAL_CONFIG+=$'\n'enable_plugin ceilometer git://
 git.openstack.org/openstack/ceilometer

 I'm not entirely clear on what we will need to do coordinate this,
 but it is clear some coordination will need to be done such that
 ceilometer remains in devstack until everything that is using
 ceilometer in devstack is ready to use the plugin.

 A grep through the jenkins jobs suggests that the projects in
 $SUBJECT (rally, sahara, heat, congress, tripleo) will need some
 changes.

 How shall we proceed with this?

 One option is for project team members[2] to make a stack of dependent
 patches that are dependent on 196446 above (which itself is dependent
 on 196383) so that it all happens in one fell swoop.

 What are the other options?

 Thanks for your input.

 [1] That is, is it worth considering adding functionality to
 devstack's sense of enabled such that if a service is enabled
 devstack knows how to look for a plugin if it doesn't find local
 support. With the destruction of the stackforge namespace we can
 perhaps guess the git URL for plugins?

 [2] Or me if that's better.

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

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




 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.
 __
 OpenStack Development Mailing 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] simulation example in the doc not working

2015-08-25 Thread Tim Hinrichs

Hi Su,

Try using 'action' instead of 'null'.  'action' is a built-in policy.  It's
possible that seemingly insignificant changes made the API call more strict
and now force the policy you provide to actually exist.  Let me know if
that doesn't work, and I'll investigate further.

Tim


On Tue, Aug 25, 2015 at 5:18 PM Su Zhang westlif...@gmail.com wrote:

 Hello,

 In simulation examples at
 http://congress.readthedocs.org/en/latest/enforcement.html?highlight=simulation
 ,
 the action_policy is replaced with null. However, null is not
 considered as a valid policy as I keep receiving 400 errors.
 Could someone let me know the easiest way to get around this error?
 How to create a simple action policy just for test purpose as of now?

 Thanks,

 --
 Su Zhang

 __
 OpenStack Development Mailing 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][requirements] Requirements proposal job fails

2015-08-20 Thread Tim Hinrichs

Thanks for sorting that out.  +1ed the change.

Tim


On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger a...@suse.com wrote:

 On 08/20/2015 09:32 PM, Robert Collins wrote:
  It was just removed from global requirements, because it was not used.
  That's clearly wrong. So let's refer that and add it back.

 Ah, that explains it, let's revert the change:
 https://review.openstack.org/#/c/215306/

 Thanks,
 Andreas
 --
   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Graham Norton,
 HRB 21284 (AG Nürnberg)
  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


 __
 OpenStack Development Mailing 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] [Murano] multiple numbers of arguments for table

2015-08-18 Thread Tim Hinrichs

Hi all,

We're contemplating a small syntax change in the Congress policy language
and wanted to see if it would cause anyone problems.

Currently you can write rules that give a single table differing numbers of
columns.  In the following example, the 'error' table has both 1 column and
2 columns.

error(vm) :- blah blah
error(vm, net) :- blah blah

We're contemplating removing this flexibility and making every table have a
fixed number of columns.  (We only support differing numbers of columns in
very special cases anyway.)

Would this cause any problems?  Murano team?

Thanks,
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] [murano] Congress jenkins job is failing

2015-08-18 Thread Tim Hinrichs

Looks like we merged a database schema change without the migration
script.  I'm on it.  (We'll get our tempest tests running in gate again
ASAP.)

Tim


On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha filip.bl...@hp.com wrote:

 Hi Congress team.

 Our jenkins job testing integration congress and murano is failing.
 Congress fails to start on some DB error [1] . Does anyone know what
 could be the problem?

 [1]

 http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033

 Thanks
 Filip

 __
 OpenStack Development Mailing 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] [murano] Congress jenkins job is failing

2015-08-18 Thread Tim Hinrichs

Hi Filip,

I just submitted a revert of the problematic change.  Once it merges, all
should be well again.  Sorry for the trouble.

Tim

On Tue, Aug 18, 2015 at 7:57 AM Tim Hinrichs t...@styra.com wrote:

 Looks like we merged a database schema change without the migration
 script.  I'm on it.  (We'll get our tempest tests running in gate again
 ASAP.)

 Tim


 On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha filip.bl...@hp.com wrote:

 Hi Congress team.

 Our jenkins job testing integration congress and murano is failing.
 Congress fails to start on some DB error [1] . Does anyone know what
 could be the problem?

 [1]

 http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033

 Thanks
 Filip

 __
 OpenStack Development Mailing 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] Confused syntax error when inserting rule.

2015-08-14 Thread Tim Hinrichs

Hi Rui,

The problem with the following rule is that there are a bunch of hidden
variables in the not cinder:volumes(...) literal.  The error message
shows the hidden variables.  The syntax restriction is that every variable
in a negative literal must appear in a positive literal in the body.  Those
hidden variables fail to satisfy that restriction, hence the error.

 error(id) :- cinder:volumes(id=id), not cinder:volumes(id=id,
status=available)

The reason the other rule worked is that you made the hidden variables
equivalent to the ones in the positive literal, e.g. x_0_1 shows up in both
the positive and negative literals.

error(x) :- cinder:volumes(x, _x_0_1, _x_0_2, _x_0_3, _x_0_4, _x_0_5,
_x_0_6, _x_0_7, _x_0_8),not cinder:volumes(x, _x_0_1, _x_0_2,
\available\,_x_0_4, _x_0_5, _x_0_6, _x_0_7, _x_0_8)

But in the auto-generated one, the variables in the two literals are
different e.g. _x_0_1 and _x_1_1

error(id) :- cinder:volumes(id, _x_0_1, _x_0_2, _x_0_3, _x_0_4, _x_0_5,
_x_0_6, _x_0_7, _x_0_8), not cinder:volumes(id, _x_1_1, _x_1_2,
available, _x_1_4, _x_1_5, _x_1_6, _x_1_7, _x_1_8).  Unsafe lits: not
cinder:volumes(id, _x_1_1, _x_1_2, available, _x_1_4, _x_1_5, _x_1_6,
_x_1_7, _x_1_8)

Probably the solution you want is to write 2 rules:

error(id) :- cinder:volumes(id=id), not avail_cinder_vol(id)
avail_cinder_vol(id) :- cinder:volumes(id=id, status=available)

Tim

On Thu, Aug 13, 2015 at 8:07 PM Rui Chen chenrui.m...@gmail.com wrote:

 Sorry, send the same mail again, please comments at here, the other mail
 lack title.

 2015-08-14 11:03 GMT+08:00 Rui Chen chenrui.m...@gmail.com:

 Hi folks:

 I face a problem when I insert a rule into Congress. I want to find
 out all of the volumes that are not available status, so I draft a rule
 like this:

 error(id) :- cinder:volumes(id=id), not cinder:volumes(id=id,
 status=available)

 But when I create the rule, a error is raised:

 (openstack) congress policy rule create chenrui_p error(id) :-
 cinder:volumes(id=id),not cinder:volumes(id=id, status=\available\)
 ERROR: openstack Syntax error for rule::Errors: Could not reorder rule
 error(id) :- cinder:volumes(id, _x_0_1, _x_0_2, _x_0_3, _x_0_4, _x_0_5,
 _x_0_6, _x_0_7, _x_0_8), not cinder:volumes(id, _x_1_1, _x_1_2,
 available, _x_1_4, _x_1_5, _x_1_6, _x_1_7, _x_1_8).  Unsafe lits: not
 cinder:volumes(id, _x_1_1, _x_1_2, available, _x_1_4, _x_1_5, _x_1_6,
 _x_1_7, _x_1_8) (vars set(['_x_1_2', '_x_1_1', '_x_1_6', '_x_1_7',
 '_x_1_4', '_x_1_5', '_x_1_8'])) (HTTP 400) (Request-ID:
 req-1f4432d6-f869-472b-aa7d-4cf78dd96fa1)

 I check the Congress policy docs [1], looks like that the rule don't
 break any syntax restrictions.

 If I modify the rule like this, it works:

 (openstack) congress policy rule create chenrui_p error(x) :-
 cinder:volumes(x, _x_0_1, _x_0_2, _x_0_3, _x_0_4, _x_0_5, _x_0_6, _x_0_7,
 _x_0_8),not cinder:volumes(x, _x_0_1, _x_0_2, \available\,_x_0_4, _x_0_5,
 _x_0_6, _x_0_7, _x_0_8)

 +-++
 | Field   | Value
  |

 +-++
 | comment | None
   |
 | id  | ad121e09-ba0a-45d6-bd18-487d975d5bf5
   |
 | name| None
   |
 | rule| error(x) :-
  |
 | | cinder:volumes(x, _x_0_1, _x_0_2, _x_0_3, _x_0_4, _x_0_5,
 _x_0_6, _x_0_7, _x_0_8), |
 | | not cinder:volumes(x, _x_0_1, _x_0_2, available,
 _x_0_4, _x_0_5, _x_0_6, _x_0_7, _x_0_8) |

 +-++

 I'm not sure this is a bug or I miss something from docs, so I need
 some feedback from mail list.
 Feel free to discuss about it.


 [1]:
 http://congress.readthedocs.org/en/latest/policy.html#datalog-syntax-restrictions


 Best Regards.


 __
 OpenStack Development Mailing 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] Mid-cycle sprint summary

2015-08-07 Thread Tim Hinrichs

Hi all,

We just finished up a great 2 day sprint focusing on a new distributed
architecture for Congress.  Details can be found in the etherpad:

https://etherpad.openstack.org/p/congress-liberty-sprint

Here's the summary.

1. Architecture.  Each datasource driver will run in its own process; each
policy engine will run in its own process; the API will run in its own
process.  All processes will communicate using oslo-messaging.  We decided
to remove the functionality for creating/deleting datasources, since that
functionality will be handled by the operating system.

2. Blueprints.  The blueprints we created all start with dist-.  Please
sign up if you're interested.  If you attended the sprint and volunteered
for a blueprint but did not sign up, please do so.

https://blueprints.launchpad.net/congress

3. Code commits.  We're making changes in place on master.  The plan is to
make most of the changes without breaking existing functionality.  Then
there will be one or two changes at the end that swap out the current,
single-process architecture for the new, multi-process architecture.

4. Timelines.  We're hoping to have the basic functionality in place by
Tokyo.  We will release the current architecture for liberty and the new
architecture for M.

Thanks for a great sprint, everyone!

Let me know if you have questions.
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

[openstack-dev] [Congress] meeting time change

2015-07-31 Thread Tim Hinrichs

Hi all,

We managed to find a day/time where all the active contributors can attend
(without being up too early/late).  The room, day, and time have all
changed.

Room: #openstack-meeting-2
Time: Wednesday 5p Pacific = Thursday midnight UTC

Next week we begin with this new schedule.

And don't forget that next week Thu/Fri is our Mid-cycle sprint.  Hope to
see you there!

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

1 2 3 >

1 - 100 of 200 matches

Mail list logo