Re: [openstack-dev] [nova][oslo][policy] oslo.policy adoption in Nova.

[Lei Zhang]

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 
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  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  > 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 
> 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 <
> d...@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-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
>
>
>
> --
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
​Jeffrey
 Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [nova][oslo][policy] oslo.policy adoption in Nova.

[Sergey Vilgelm]

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  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  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  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  
> > > >>> 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-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
> 
> 
> 
> -- 
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][oslo][policy] oslo.policy adoption in Nova.

[Sergey Vilgelm]

If i understood correctly, the main difference is that the parse_rule
function is a private now in the oslo.policy library, also Jeffrey Zhang
has changed this function and put into nova.policy module. I offer remove
this function from the nova and make a public in the oslo.policy.

On Mon, Aug 3, 2015 at 2:13 PM, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Davanum Srinivas (dims)'s message of 2015-08-03 06:46:26
 -0400:
  Doug,
 
  All the features needed for Nova to work is present in oslo.policy
  (i.e. all features from old oslo-incubator copy is present in
  oslo.policy)

 Great! I was worried that the copy local to nova had somehow been
 modified or extended and that work hadn't been carried over to the
 library.

 We should try to find someone to write the blueprint/spec for the
 new features, and to do the implementation work, but until they are
 identified we should not postpone migrations to the supported
 versions of the policy code. The incubated version has already been
 deleted, so at this point the only way for a project to receive
 fixes or features for policy code is to move to the library version.

 Doug

 
  -- dims
 
  On Mon, Aug 3, 2015 at 5:16 AM, Doug Hellmann d...@doughellmann.com
 wrote:
   Excerpts from Davanum Srinivas (dims)'s message of 2015-08-02 21:16:32
 -0400:
   Sean, Nova-cores,
  
   The following Nova review is stuck:
   https://review.openstack.org/#/c/198065/
  
   What's the minimum features in oslo.policy that we have to add in
   oslo.policy to unblock that work?
  
   If we get Nova wants to put defaults in code working, is that enough
   for getting oslo.policy into Nova for liberty?
  
   Does the copy of the policy code in the nova repository have features
   not present in the incubated copy for some reason?
  
   As long as the library has feature parity with the incubated version of
   the code, the only time we should block on adoption is if the API is
   broken in some way. New features can come after adoption is complete,
   but shouldn't block moving to the supported version of the code in
   question.
  
   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




-- 
Thanks,
Sergey Vilgelm
OpenStack Software Engineer
Mirantis Inc.
Skype: sergey.vilgelm
Phone: +36 70 512 3836
__
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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

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 d...@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 d...@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-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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2015-08-02 21:16:32 -0400:
 Sean, Nova-cores,
 
 The following Nova review is stuck:
 https://review.openstack.org/#/c/198065/
 
 What's the minimum features in oslo.policy that we have to add in
 oslo.policy to unblock that work?
 
 If we get Nova wants to put defaults in code working, is that enough
 for getting oslo.policy into Nova for liberty?

Does the copy of the policy code in the nova repository have features
not present in the incubated copy for some reason?

As long as the library has feature parity with the incubated version of
the code, the only time we should block on adoption is if the API is
broken in some way. New features can come after adoption is complete,
but shouldn't block moving to the supported version of the code in
question.

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

Re: [openstack-dev] [nova][oslo][policy] oslo.policy adoption in Nova.

[Davanum Srinivas]

Doug,

All the features needed for Nova to work is present in oslo.policy
(i.e. all features from old oslo-incubator copy is present in
oslo.policy)

-- dims

On Mon, Aug 3, 2015 at 5:16 AM, Doug Hellmann d...@doughellmann.com wrote:
 Excerpts from Davanum Srinivas (dims)'s message of 2015-08-02 21:16:32 -0400:
 Sean, Nova-cores,

 The following Nova review is stuck:
 https://review.openstack.org/#/c/198065/

 What's the minimum features in oslo.policy that we have to add in
 oslo.policy to unblock that work?

 If we get Nova wants to put defaults in code working, is that enough
 for getting oslo.policy into Nova for liberty?

 Does the copy of the policy code in the nova repository have features
 not present in the incubated copy for some reason?

 As long as the library has feature parity with the incubated version of
 the code, the only time we should block on adoption is if the API is
 broken in some way. New features can come after adoption is complete,
 but shouldn't block moving to the supported version of the code in
 question.

 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

Excerpts from Sergey Vilgelm's message of 2015-08-03 19:05:52 +0300:
 If i understood correctly, the main difference is that the parse_rule
 function is a private now in the oslo.policy library, also Jeffrey Zhang
 has changed this function and put into nova.policy module. I offer remove
 this function from the nova and make a public in the oslo.policy.

It sounds like the change in the policy library API made it harder
to integrate with nova.

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).

Doug

 
 On Mon, Aug 3, 2015 at 2:13 PM, Doug Hellmann d...@doughellmann.com wrote:
 
  Excerpts from Davanum Srinivas (dims)'s message of 2015-08-03 06:46:26
  -0400:
   Doug,
  
   All the features needed for Nova to work is present in oslo.policy
   (i.e. all features from old oslo-incubator copy is present in
   oslo.policy)
 
  Great! I was worried that the copy local to nova had somehow been
  modified or extended and that work hadn't been carried over to the
  library.
 
  We should try to find someone to write the blueprint/spec for the
  new features, and to do the implementation work, but until they are
  identified we should not postpone migrations to the supported
  versions of the policy code. The incubated version has already been
  deleted, so at this point the only way for a project to receive
  fixes or features for policy code is to move to the library version.
 
  Doug
 
  
   -- dims
  
   On Mon, Aug 3, 2015 at 5:16 AM, Doug Hellmann d...@doughellmann.com
  wrote:
Excerpts from Davanum Srinivas (dims)'s message of 2015-08-02 21:16:32
  -0400:
Sean, Nova-cores,
   
The following Nova review is stuck:
https://review.openstack.org/#/c/198065/
   
What's the minimum features in oslo.policy that we have to add in
oslo.policy to unblock that work?
   
If we get Nova wants to put defaults in code working, is that enough
for getting oslo.policy into Nova for liberty?
   
Does the copy of the policy code in the nova repository have features
not present in the incubated copy for some reason?
   
As long as the library has feature parity with the incubated version of
the code, the only time we should block on adoption is if the API is
broken in some way. New features can come after adoption is complete,
but shouldn't block moving to the supported version of the code in
question.
   
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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Sergey Vilgelm]

On Mon, Aug 3, 2015 at 9:37 PM, Doug Hellmann d...@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]

[1] https://review.openstack.org/#/c/208617/


-- 
Thanks,
Sergey Vilgelm
OpenStack Software Engineer
Mirantis Inc.
Skype: sergey.vilgelm
Phone: +36 70 512 3836
__
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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2015-08-03 06:46:26 -0400:
 Doug,
 
 All the features needed for Nova to work is present in oslo.policy
 (i.e. all features from old oslo-incubator copy is present in
 oslo.policy)

Great! I was worried that the copy local to nova had somehow been
modified or extended and that work hadn't been carried over to the
library.

We should try to find someone to write the blueprint/spec for the
new features, and to do the implementation work, but until they are
identified we should not postpone migrations to the supported
versions of the policy code. The incubated version has already been
deleted, so at this point the only way for a project to receive
fixes or features for policy code is to move to the library version.

Doug

 
 -- dims
 
 On Mon, Aug 3, 2015 at 5:16 AM, Doug Hellmann d...@doughellmann.com wrote:
  Excerpts from Davanum Srinivas (dims)'s message of 2015-08-02 21:16:32 
  -0400:
  Sean, Nova-cores,
 
  The following Nova review is stuck:
  https://review.openstack.org/#/c/198065/
 
  What's the minimum features in oslo.policy that we have to add in
  oslo.policy to unblock that work?
 
  If we get Nova wants to put defaults in code working, is that enough
  for getting oslo.policy into Nova for liberty?
 
  Does the copy of the policy code in the nova repository have features
  not present in the incubated copy for some reason?
 
  As long as the library has feature parity with the incubated version of
  the code, the only time we should block on adoption is if the API is
  broken in some way. New features can come after adoption is complete,
  but shouldn't block moving to the supported version of the code in
  question.
 
  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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

Excerpts from Morgan Fainberg's message of 2015-08-04 06:05:56 +1000:
 
  On Aug 4, 2015, at 05:49, Doug Hellmann d...@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 d...@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-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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Doug Hellmann]

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 d...@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.

Doug

 
 [1] https://review.openstack.org/#/c/208617/
 

__
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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Morgan Fainberg]

 On Aug 4, 2015, at 05:49, Doug Hellmann d...@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 d...@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. 

 Doug
 
 
 [1] https://review.openstack.org/#/c/208617/
 
 __
 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] [nova][oslo][policy] oslo.policy adoption in Nova.

[Davanum Srinivas]

Sean, Nova-cores,

The following Nova review is stuck:
https://review.openstack.org/#/c/198065/

What's the minimum features in oslo.policy that we have to add in
oslo.policy to unblock that work?

If we get Nova wants to put defaults in code working, is that enough
for getting oslo.policy into Nova for liberty?

Thanks,
dims


-- 
Davanum Srinivas :: https://twitter.com/dims

__
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