<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi nova-team,<br class=""><br class="">Jeffrey Zhang has updated his patch[1].<div class="">Dan Smith, Could you remove -2?</div><div class=""><br class=""></div><div class="">[1] <a href="https://review.openstack.org/#/c/198065" class="">https://review.openstack.org/#/c/198065</a></div><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Aug 20, 2015, at 17:26, Sergey Vilgelm <<a href="mailto:svilgelm@mirantis.com" class="">svilgelm@mirantis.com</a>> wrote:<br class=""><br class="">Nova-cores,<br class="">Do you have any decision about the patch: <a href="https://review.openstack.org/#/c/198065/" class="">https://review.openstack.org/#/c/198065/</a> ?<br class="">Dan Smith, Could you remove -2?<br class="">Jeffrey Zhang, What is your opinion?<br class=""><br class="">On Tue, Aug 4, 2015 at 12:26 AM, Doug Hellmann <doug@doughellmann.com> wrote:<br class="">Excerpts from Doug Hellmann's message of 2015-08-03 16:19:31 -0400:<br class="">> Excerpts from Morgan Fainberg's message of 2015-08-04 06:05:56 +1000:<br class="">> ><br class="">> > > On Aug 4, 2015, at 05:49, Doug Hellmann <doug@doughellmann.com> wrote:<br class="">> > ><br class="">> > > Excerpts from Sergey Vilgelm's message of 2015-08-03 22:11:50 +0300:<br class="">> > >>> On Mon, Aug 3, 2015 at 9:37 PM, Doug Hellmann <doug@doughellmann.com> wrote:<br class="">> > >>><br class="">> > >>> Making that function public may be the most expedient fix, but the<br class="">> > >>> parser was made private for a reason, so before we expose it we<br class="">> > >>> should understand why, and if there are alternatives (such as<br class="">> > >>> creating a fixture in oslo.policy to do what the nova tests need).<br class="">> > >><br class="">> > >> Probably we may extend the Rules class and add the similar functions as a<br class="">> > >> classmethod?<br class="">> > >> I've created a patch for slo.policy as example[1]<br class="">> > ><br class="">> > > Well, my point was that the folks working on that library considered the<br class="">> > > entire parser to be private. That could just be overly ambitious API<br class="">> > > pruning, or there could be some underlying reason (like, the syntax may<br class="">> > > be changing or we want apps to interact with APIs and not generate DSL<br class="">> > > and feed it to the library). So we should find out about the reason<br class="">> > > before looking for alternative places to expose the parser.<br class="">> > ><br class="">> ><br class="">> > 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.<br class="">><br class="">> It would be easy enough to provide a fixture, which would make it clear<br class="">> that the API is meant for testing and not for general use. I see a<br class="">> couple of options:<br class="">><br class="">> 1. a fixture that takes some DSL text and creates a new Enforcer<br class="">> instance populated with the rules based on parsing the text<br class="">><br class="">> 2. a fixture that takes some DSL text *and* an existing Enforcer<br class="">> instance and replaces the rules inside that Enforcer instance with the<br class="">> rules represented by the DSL text<br class="">><br class="">> Option 1 feels a little cleaner but option 2 is more like how Nova<br class="">> is using parse_rule() now and may be easier to drop in.<br class=""><br class="">Brant also pointed out on IRC that the Rules class already has a<br class="">load_json() class method that invokes the parser, so maybe the thing to<br class="">do is update nova's tests to use that method. A fixture would still be<br class="">an improvement, but using the existing code will let us move ahead<br class="">faster (assuming we've decided not to wait for the new features to be<br class="">implemented).<br class=""><br class="">Doug<br class=""><br class="">><br class="">> Doug<br class="">><br class="">> ><br class="">> > > Doug<br class="">> > ><br class="">> > >><br class="">> > >> [1] https://review.openstack.org/#/c/208617/<br class="">> > ><br class="">> > > __________________________________________________________________________<br class="">> > > OpenStack Development Mailing List (not for usage questions)<br class="">> > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">> ><br class="">><br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class=""><br class=""><br class=""><br class="">-- <br class="">Thanks,<br class="">Sergey Vilgelm<br class="">OpenStack Software Engineer<br class="">Mirantis Inc.<br class="">Skype: sergey.vilgelm<br class="">Phone: +36 70 512 3836<br class=""></blockquote><br class=""><div class=""><br class="">—<br class="">Sergey Vilgelm<br class="">OpenStack Software Engineer<br class="">Mirantis Inc.<br class=""></div><br class=""></div></body></html>