Re: [openstack-dev] [oslo][mistral] Mistral expressions package

2017-10-18 Thread Renat Akhmerov
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

2017-10-18 Thread ChangBo Guo
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

2017-10-18 Thread Doug Hellmann
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

2017-10-17 Thread 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...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_

Re: [openstack-dev] [oslo][mistral] Mistral expressions package

2017-10-10 Thread Doug Hellmann
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

2017-10-09 Thread HADDLETON, Robert W (Bob)

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

2017-10-09 Thread Doug Hellmann
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

2017-10-09 Thread Bob Haddleton

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