Open Stack

The dependencies of  mistral expressions package make it hard to be adopted
as a module of oslo library,  we need oslo library keep simple.
we have a adopt process [1]  which is not merged to help guide the adoption
process if we agree.  agree with Dough, we can discuss in the Oslo weekly
meeting.[2]


[1] https://review.openstack.org/312233
[2] http://eavesdrop.openstack.org/#Oslo_Team_Meeting

2017-10-18 12:46 GMT+08:00 Renat Akhmerov <renat.akhmerov at gmail.com>:

> Hi,
>
> I’m not too happy about the idea of creating one more subproject within
> Mistral. I don’t even see now what else this new library project managed by
> Mistral team will contain besides this expression utils module. I’m also
> not sure about its name. We already have mistral-lib which was created for
> a different purpose (public APIs for making Mistral extensions like actions
> and YAQL/Jinja functions).
>
> Just to clarify: the code we’re talking about is really small and stable
> (we haven’t touched it for a while, it just works), and it’s generic so it
> can be reused in many situations by many projects. That’s why we had an
> idea to find a place within one of the Oslo libraries, just to make one
> more package (or even module), for example, in oslo.utils. As far as
> maintaining this code, we could still do that. But anyway, if that’s not
> OK, I’d just suggest we leave it as it is. If this code needs to be reused
> somewhere else outside OpenStack space (like in Bob’s case) may be it’s
> just simpler to create a project on github?
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> On 10 Oct 2017, 22:11 +0700, Doug Hellmann <doug at doughellmann.com>, wrote:
>
> Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58
> -0500:
>
> On 10/9/2017 2:35 PM, Doug Hellmann wrote:
>
> Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
>
> Hello Oslo team:
>
> The Mistral project has an expressions package [0] that is used to
> evaluate inline expressions using a context. It has a pluggable
> architecture that presently supports Jinja and YAQL expression
> evaluation. It also allows custom functions[1] to provide Python
> implementations of functionality that is then made available to the
> expression evaluation engines.
>
> This functionality was originally developed to support dynamic
> processing within Mistral workflows, but is also very useful in other
> applications that use templates which require runtime evaluation of
> expressions.
>
> I'd like to explore extracting this functionality from mistral to make
> it more widely available with minimal dependencies.
>
> The expressions dependencies are pretty limited:
>
> Jinja2
> oslo.utils
> oslo.log
> stevedore
> yaql
>
> and since 60% are already oslo-maintained packages, it seemed like a
> logical place to start.
>
> I'd appreciate feedback on the topic. There is no real OpenStack
> dependency in the functionality, so maybe a standalone package on pypi
> makes sense.
>
> Thanks for your help,
>
> Bob Haddleton
>
>
> [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> [1]
> https://github.com/openstack/mistral/blob/master/mistral/
> utils/expression_utils.py#L63
>
> Oslo is a good place for things like this that have no other obvious
> home, but if the Mistral team is already managing the code is there any
> reason they couldn't also manage the library after you pull it out of
> the service? It's much easier for any project team to manage a library
> now, and we have several other examples of that pattern already.
>
> 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
>
> Hi Doug:
>
> That's probably fine, we're just not sure what the process should be and
> where the library would land?  Do you have an example that we could use
> as a pattern?
>
> Thanks
>
> Bob
>
>
> The first step is to create the repository with the library code. Then
> you would add that repository to the list managed by the mistral team by
> modifying the project list file in the governance repository.
>
> Any of the project client libraries would work as an example of how to
> set up the CI, governance, and release configuration. I think most of
> the steps are covered in
> https://docs.openstack.org/infra/manual/creators.html as well.
>
> If the code is already isolated well within the mistral repo and you
> want to preserve its history, you may also want to take a look at
> http://git.openstack.org/cgit/openstack/oslo.tools/tree/
> filter_git_history.sh
> as a tool for making the new repository.
>
> I'm happy to help you work out a more detailed plan. Let me know if that
> would be useful.
>
> 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
>
>


-- 
ChangBo Guo(gcb)
Community Director @EasyStack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171019/2a77c5b2/attachment.html>