Open Stack

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.

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
>