Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171018/f560b601/attachment.html>