Open Stack

Excerpts from Doug Hellmann's message of 2015-08-03 16:19:31 -0400:
> Excerpts from Morgan Fainberg's message of 2015-08-04 06:05:56 +1000:
> > 
> > > On Aug 4, 2015, at 05:49, Doug Hellmann <doug at doughellmann.com> wrote:
> > > 
> > > Excerpts from Sergey Vilgelm's message of 2015-08-03 22:11:50 +0300:
> > >>> On Mon, Aug 3, 2015 at 9:37 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> > >>> 
> > >>> Making that function public may be the most expedient fix, but the
> > >>> parser was made private for a reason, so before we expose it we
> > >>> should understand why, and if there are alternatives (such as
> > >>> creating a fixture in oslo.policy to do what the nova tests need).
> > >> 
> > >> Probably we may extend the Rules class and add the similar functions as a
> > >> classmethod?
> > >> I've created a patch for slo.policy as example[1]
> > > 
> > > Well, my point was that the folks working on that library considered the
> > > entire parser to be private. That could just be overly ambitious API
> > > pruning, or there could be some underlying reason (like, the syntax may
> > > be changing or we want apps to interact with APIs and not generate DSL
> > > and feed it to the library). So we should find out about the reason
> > > before looking for alternative places to expose the parser.
> > > 
> > 
> > The idea is to have apis vs dsl generation. But we did a "everything private that isnt clearly used" as a starting point. I would prefer to not make this public and have a fixture instead. That said, i am not hard-set against a change to make it public. 
> 
> It would be easy enough to provide a fixture, which would make it clear
> that the API is meant for testing and not for general use. I see a
> couple of options:
> 
> 1. a fixture that takes some DSL text and creates a new Enforcer
>    instance populated with the rules based on parsing the text
> 
> 2. a fixture that takes some DSL text *and* an existing Enforcer
>    instance and replaces the rules inside that Enforcer instance with the
>    rules represented by the DSL text
> 
> Option 1 feels a little cleaner but option 2 is more like how Nova
> is using parse_rule() now and may be easier to drop in.

Brant also pointed out on IRC that the Rules class already has a
load_json() class method that invokes the parser, so maybe the thing to
do is update nova's tests to use that method. A fixture would still be
an improvement, but using the existing code will let us move ahead
faster (assuming we've decided not to wait for the new features to be
implemented).

Doug

> 
> Doug
> 
> > 
> > > Doug
> > > 
> > >> 
> > >> [1] https://review.openstack.org/#/c/208617/
> > > 
> > > __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
>