[openstack-dev] [nova][oslo][policy] oslo.policy adoption in Nova.
Sergey Vilgelm
svilgelm at mirantis.com
Mon Aug 3 16:05:52 UTC 2015
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 <doug at 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 <doug at 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-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/50e51ae3/attachment.html>
More information about the OpenStack-dev
mailing list