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 <[email protected]>: > 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 <[email protected]>, 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: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
