Open Stack

Excerpts from Renat Akhmerov's message of 2017-10-18 11:46:46 +0700:
> 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?

I'm not sure why you think it would be less of a burden for you to
maintain the library under oslo than mistral, but I was presenting an
alternative not a strong objection to having oslo take on the library.

If the library has no dependencies on libraries like oslo.config,
then we would want to leave "oslo" or "mistral" out of the name to
encourage adoption outside of openstack. So, think about whatever
name you might have used for that github repository.

It seems like the next step is to get more of the oslo team involved
in the conversation to see whether they are willing to take
responsibility for a new repository. Maybe one of you can add it
to the meeting agenda for next week?

Dogu


> 
> 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