Open Stack

The oslo.policy has a class method `from_dict` which can be helpful.
So I replaced the `parse_rule` with `from_dict`, and it works as expect.

Is there any other feature that oslo.policy doesn't have?



On Mon, Sep 7, 2015 at 6:48 PM, Sergey Vilgelm <svilgelm at mirantis.com>
wrote:

> Hi nova-team,
>
> Jeffrey Zhang has updated his patch[1].
> Dan Smith, Could you remove -2?
>
> [1] https://review.openstack.org/#/c/198065
>
>
> On Aug 20, 2015, at 17:26, Sergey Vilgelm <svilgelm at mirantis.com> wrote:
>
> Nova-cores,
> Do you have any decision about the patch:
> https://review.openstack.org/#/c/198065/ ?
> Dan Smith, Could you remove -2?
> Jeffrey Zhang, What is your opinion?
>
> On Tue, Aug 4, 2015 at 12:26 AM, Doug Hellmann <doug at doughellmann.com
> > wrote:
> 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
> > >
> >
>
> __________________________________________________________________________
> 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
>
>
>
> --
> Thanks,
> Sergey Vilgelm
> OpenStack Software Engineer
> Mirantis Inc.
> Skype: sergey.vilgelm
> Phone: +36 70 512 3836
>
>
>
> —
> Sergey Vilgelm
> OpenStack Software Engineer
> Mirantis Inc.
>
>
> __________________________________________________________________________
> 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
>
>


-- 
​Jeffrey
 Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150908/263636e7/attachment.html>