Re: [openstack-dev] [oslo][mistral] Mistral expressions package
Ok, thanks for your input. I’d personally say it’s not really worth it but if Bob wants to do it that’s ok. Thanks Renat Akhmerov @Nokia On 19 Oct 2017, 12:46 +0700, ChangBo Guo , wrote: > 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 : > > > 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 , 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-requ...@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
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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 : > 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 , 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-requ...@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-requ...@l
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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 , 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-requ...@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 gover
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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 , 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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-requ...@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 <>__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][mistral] Mistral expressions package
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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
