[openstack-dev] [mistral] Renat is on vacation until Dec 17th

2018-11-29 Thread Renat Akhmerov
Hi,

I’ll be on vacation till Dec 17th. I’ll be replying emails but with delays.

Thanks

Renat Akhmerov
@Nokia
__
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] [mistral][tc] Seeking feedback on the OpenStack cloud vision

2018-10-24 Thread Zane Bitter

Greetings, Mistral team!
As you may be aware, I've been working with other folks in the community 
on documenting a vision for OpenStack clouds (formerly known as the 
'Technical Vision') - essentially to interpret the mission statement in 
long-form, in a way that we can use to actually help guide decisions. 
You can read the latest draft here: https://review.openstack.org/592205


We're trying to get feedback from as many people as possible - in many 
ways the value is in the process of coming together to figure out what 
we're trying to achieve as a community with OpenStack and how we can 
work together to build it. The document is there to help us remember 
what we decided so we don't have to do it all again over and over.


The vision is structured with two sections that apply broadly to every 
project in OpenStack - describing the principles that we believe are 
essential to every cloud, and the ones that make OpenStack different 
from some other clouds. The third section is a list of design goals that 
we want OpenStack as a whole to be able to meet - ideally each project 
would be contributing toward one or more of these design goals.


I see Mistral contributing to two of the design goals. First, it helps 
with Customisable Integration by enabling application developers to 
incorporate glue logic between cloud services or between the application 
and cloud services, and host it in the cloud without the need to 
pre-allocate a VM for it. Secondly, it also contributes to the Built-in 
Reliability and Durability goal by providing applications with a 
highly-reliable way of maintaining workflow state without the need for 
the application itself to do it.


The sections on Bidirectional Compatibility and Interoperability will 
probably be relevant to design decisions in Mistral, since workbooks are 
one of the artifact types that I'd expect to help with interoperability 
across clouds. The Cross-Project Dependencies section may also be of 
special interest to review, since Mistral is a service that many other 
OpenStack services could potentially rely on.


If you would like me or another TC member to join one of your team IRC 
meetings to discuss further what the vision means for your team, please 
reply to this thread to set it up. You are also welcome to bring up any 
questions in the TC IRC channel, #openstack-tc - there's more of us 
around during Office Hours 
(https://governance.openstack.org/tc/#office-hours), but you can talk to 
us at any time.


Feedback can also happen either in this thread or on the review 
https://review.openstack.org/592205


If the team is generally happy with the vision as it is and doesn't have 
any specific feedback, that's cool but I'd like to request that at least 
the PTL leave a vote on the review. It's important to know whether we 
are actually developing a consensus in the community or just talking to 
ourselves :)


many thanks,
Zane.

__
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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-21 Thread Renat Akhmerov
Hi Ken,

Awesome! IMO it works for us.

Thanks

Renat Akhmerov
@Nokia
On 20 Oct 2018, 01:19 +0700, Ken Giusti , wrote:
> Hi Renat,
> After discussing this a bit with Ben on IRC we're going to push the removal 
> off to T milestone 1.
>
> I really like Ben's idea re: adding a blocking entry to your project's 
> setup.cfg file.  We can remove the explicit check for blocking in 
> oslo.messaging so you won't get an annoying warning if you want to load 
> blocking on your own.
>
> Let me know what you think, thanks.
>
> > On Fri, Oct 19, 2018 at 12:02 AM Renat Akhmerov  
> > wrote:
> > > Hi,
> > >
> > >
> > > @Ken, I understand your considerations. I get that. I’m only asking not 
> > > to remove it *for now*. And yes, if you think it should be discouraged 
> > > from using it’s totally fine. But practically, it’s been the only 
> > > reliable option for Mistral so far that may be our fault, I have to 
> > > admit, because we weren’t able to make it work well with other executor 
> > > types but we’ll try to fix that.
> > >
> > > By the way, I was playing with different options yesterday and it seems 
> > > like that setting the executor to “threading” and the 
> > > “executor_thread_pool_size” property to 1 behaves the same way as 
> > > “blocking”. So may be that’s an option for us too, even if “blocking” is 
> > > completely removed. But I would still be in favour of having some extra 
> > > time to prove that with thorough testing.
> > >
> > > @Ben, including the executor via setup.cfg also looks OK to me. I see no 
> > > issues with this approach.
> > >
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > > On 18 Oct 2018, 23:35 +0700, Ben Nemec , wrote:
> > > >
> > > >
> > > > On 10/18/18 9:59 AM, Ken Giusti wrote:
> > > > > Hi Renat,
> > > > >
> > > > > The biggest issue with the blocking executor (IMHO) is that it blocks
> > > > > the protocol I/O while  RPC processing is in progress.  This increases
> > > > > the likelihood that protocol processing will not get done in a timely
> > > > > manner and things start to fail in weird ways.  These failures are
> > > > > timing related and are typically hard to reproduce or root-cause.   
> > > > > This
> > > > > isn't something we can fix as blocking is the nature of the executor.
> > > > >
> > > > > If we are to leave it in we'd really want to discourage its use.
> > > >
> > > > Since it appears the actual executor code lives in futurist, would it be
> > > > possible to remove the entrypoint for blocking from oslo.messaging and
> > > > have mistral just pull it in with their setup.cfg? Seems like they
> > > > should be able to add something like:
> > > >
> > > > oslo.messaging.executors =
> > > > blocking = futurist:SynchronousExecutor
> > > >
> > > > to their setup.cfg to keep it available to them even if we drop it from
> > > > oslo.messaging itself. That seems like a good way to strongly discourage
> > > > use of it while still making it available to projects that are really
> > > > sure they want it.
> > > >
> > > > >
> > > > > However I'm ok with leaving it available if the policy for using
> > > > > blocking is 'use at your own risk', meaning that bug reports may have 
> > > > > to
> > > > > be marked 'won't fix' if we have reason to believe that blocking is at
> > > > > fault.  That implies removing 'blocking' as the default executor value
> > > > > in the API and having applications explicitly choose it.  And we keep
> > > > > the deprecation warning.
> > > > >
> > > > > We could perhaps implement time duration checks around the executor
> > > > > callout and log a warning if the executor blocked for an extended 
> > > > > amount
> > > > > of time (extended=TBD).
> > > > >
> > > > > Other opinions so we can come to a consensus?
> > > > >
> > > > >
> > > > > On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov 
> > > > >  > > > > > wrote:
> > > > >
> > > > > Hi Oslo Team,
> > > > >
> > > > > Can we retain “blocking” executor for now in Oslo Messaging?
> > > > >
> > > > >
> > > > > Some background..
> > > > >
> > > > > For a while we had to use Oslo Messaging with “blocking” executor in
> > > > > Mistral because of incompatibility of MySQL driver with green
> > > > > threads when choosing “eventlet” executor. Under certain conditions
> > > > > we would get deadlocks between green threads. Some time ago we
> > > > > switched to using PyMysql driver which is eventlet friendly and did
> > > > > a number of tests that showed that we could safely switch to
> > > > > “eventlet” executor (with that driver) so we introduced a new option
> > > > > in Mistral where we could choose an executor in Oslo Messaging. The
> > > > > corresponding bug is [1].
> > > > >
> > > > > The issue is that we recently found that not everything actually
> > > > > works as expected when using combination PyMysql + “eventlet”
> > > > > executor. We also tried “threading” executor and the system *seems*
> > > > > to work with it but surprisingly 

Re: [openstack-dev] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-19 Thread Ken Giusti
Hi Renat,
After discussing this a bit with Ben on IRC we're going to push the removal
off to T milestone 1.

I really like Ben's idea re: adding a blocking entry to your project's
setup.cfg file.  We can remove the explicit check for blocking in
oslo.messaging so you won't get an annoying warning if you want to load
blocking on your own.

Let me know what you think, thanks.

On Fri, Oct 19, 2018 at 12:02 AM Renat Akhmerov 
wrote:

> Hi,
>
>
> @Ken, I understand your considerations. I get that. I’m only asking not to
> remove it *for now*. And yes, if you think it should be discouraged from
> using it’s totally fine. But practically, it’s been the only reliable
> option for Mistral so far that may be our fault, I have to admit, because
> we weren’t able to make it work well with other executor types but we’ll
> try to fix that.
>
> By the way, I was playing with different options yesterday and it seems
> like that setting the executor to “threading” and the
> “executor_thread_pool_size” property to 1 behaves the same way as
> “blocking”. So may be that’s an option for us too, even if “blocking” is
> completely removed. But I would still be in favour of having some extra
> time to prove that with thorough testing.
>
> @Ben, including the executor via setup.cfg also looks OK to me. I see no
> issues with this approach.
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> On 18 Oct 2018, 23:35 +0700, Ben Nemec , wrote:
>
>
>
> On 10/18/18 9:59 AM, Ken Giusti wrote:
>
> Hi Renat,
>
> The biggest issue with the blocking executor (IMHO) is that it blocks
> the protocol I/O while  RPC processing is in progress.  This increases
> the likelihood that protocol processing will not get done in a timely
> manner and things start to fail in weird ways.  These failures are
> timing related and are typically hard to reproduce or root-cause.   This
> isn't something we can fix as blocking is the nature of the executor.
>
> If we are to leave it in we'd really want to discourage its use.
>
>
> Since it appears the actual executor code lives in futurist, would it be
> possible to remove the entrypoint for blocking from oslo.messaging and
> have mistral just pull it in with their setup.cfg? Seems like they
> should be able to add something like:
>
> oslo.messaging.executors =
> blocking = futurist:SynchronousExecutor
>
> to their setup.cfg to keep it available to them even if we drop it from
> oslo.messaging itself. That seems like a good way to strongly discourage
> use of it while still making it available to projects that are really
> sure they want it.
>
>
> However I'm ok with leaving it available if the policy for using
> blocking is 'use at your own risk', meaning that bug reports may have to
> be marked 'won't fix' if we have reason to believe that blocking is at
> fault.  That implies removing 'blocking' as the default executor value
> in the API and having applications explicitly choose it.  And we keep
> the deprecation warning.
>
> We could perhaps implement time duration checks around the executor
> callout and log a warning if the executor blocked for an extended amount
> of time (extended=TBD).
>
> Other opinions so we can come to a consensus?
>
>
> On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov  > wrote:
>
> Hi Oslo Team,
>
> Can we retain “blocking” executor for now in Oslo Messaging?
>
>
> Some background..
>
> For a while we had to use Oslo Messaging with “blocking” executor in
> Mistral because of incompatibility of MySQL driver with green
> threads when choosing “eventlet” executor. Under certain conditions
> we would get deadlocks between green threads. Some time ago we
> switched to using PyMysql driver which is eventlet friendly and did
> a number of tests that showed that we could safely switch to
> “eventlet” executor (with that driver) so we introduced a new option
> in Mistral where we could choose an executor in Oslo Messaging. The
> corresponding bug is [1].
>
> The issue is that we recently found that not everything actually
> works as expected when using combination PyMysql + “eventlet”
> executor. We also tried “threading” executor and the system *seems*
> to work with it but surprisingly performance is much worse.
>
> Given all of that we’d like to ask Oslo Team not to remove
> “blocking” executor for now completely, if that’s possible. We have
> a strong motivation to switch to “eventlet” for other reasons
> (parallelism => better performance etc.) but seems like we need some
> time to make it smoothly.
>
>
> [1] https://bugs.launchpad.net/mistral/+bug/1696469
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> __
> 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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-18 Thread Renat Akhmerov
Hi,


@Ken, I understand your considerations. I get that. I’m only asking not to 
remove it *for now*. And yes, if you think it should be discouraged from using 
it’s totally fine. But practically, it’s been the only reliable option for 
Mistral so far that may be our fault, I have to admit, because we weren’t able 
to make it work well with other executor types but we’ll try to fix that.

By the way, I was playing with different options yesterday and it seems like 
that setting the executor to “threading” and the “executor_thread_pool_size” 
property to 1 behaves the same way as “blocking”. So may be that’s an option 
for us too, even if “blocking” is completely removed. But I would still be in 
favour of having some extra time to prove that with thorough testing.

@Ben, including the executor via setup.cfg also looks OK to me. I see no issues 
with this approach.


Thanks

Renat Akhmerov
@Nokia
On 18 Oct 2018, 23:35 +0700, Ben Nemec , wrote:
>
>
> On 10/18/18 9:59 AM, Ken Giusti wrote:
> > Hi Renat,
> >
> > The biggest issue with the blocking executor (IMHO) is that it blocks
> > the protocol I/O while  RPC processing is in progress.  This increases
> > the likelihood that protocol processing will not get done in a timely
> > manner and things start to fail in weird ways.  These failures are
> > timing related and are typically hard to reproduce or root-cause.   This
> > isn't something we can fix as blocking is the nature of the executor.
> >
> > If we are to leave it in we'd really want to discourage its use.
>
> Since it appears the actual executor code lives in futurist, would it be
> possible to remove the entrypoint for blocking from oslo.messaging and
> have mistral just pull it in with their setup.cfg? Seems like they
> should be able to add something like:
>
> oslo.messaging.executors =
> blocking = futurist:SynchronousExecutor
>
> to their setup.cfg to keep it available to them even if we drop it from
> oslo.messaging itself. That seems like a good way to strongly discourage
> use of it while still making it available to projects that are really
> sure they want it.
>
> >
> > However I'm ok with leaving it available if the policy for using
> > blocking is 'use at your own risk', meaning that bug reports may have to
> > be marked 'won't fix' if we have reason to believe that blocking is at
> > fault.  That implies removing 'blocking' as the default executor value
> > in the API and having applications explicitly choose it.  And we keep
> > the deprecation warning.
> >
> > We could perhaps implement time duration checks around the executor
> > callout and log a warning if the executor blocked for an extended amount
> > of time (extended=TBD).
> >
> > Other opinions so we can come to a consensus?
> >
> >
> > On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov  > > wrote:
> >
> > Hi Oslo Team,
> >
> > Can we retain “blocking” executor for now in Oslo Messaging?
> >
> >
> > Some background..
> >
> > For a while we had to use Oslo Messaging with “blocking” executor in
> > Mistral because of incompatibility of MySQL driver with green
> > threads when choosing “eventlet” executor. Under certain conditions
> > we would get deadlocks between green threads. Some time ago we
> > switched to using PyMysql driver which is eventlet friendly and did
> > a number of tests that showed that we could safely switch to
> > “eventlet” executor (with that driver) so we introduced a new option
> > in Mistral where we could choose an executor in Oslo Messaging. The
> > corresponding bug is [1].
> >
> > The issue is that we recently found that not everything actually
> > works as expected when using combination PyMysql + “eventlet”
> > executor. We also tried “threading” executor and the system *seems*
> > to work with it but surprisingly performance is much worse.
> >
> > Given all of that we’d like to ask Oslo Team not to remove
> > “blocking” executor for now completely, if that’s possible. We have
> > a strong motivation to switch to “eventlet” for other reasons
> > (parallelism => better performance etc.) but seems like we need some
> > time to make it smoothly.
> >
> >
> > [1] https://bugs.launchpad.net/mistral/+bug/1696469
> >
> >
> > Thanks
> >
> > Renat Akhmerov
> > @Nokia
> > __
> > 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
> >
> >
> >
> > --
> > Ken Giusti  (kgiu...@gmail.com )
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 

Re: [openstack-dev] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-18 Thread Ben Nemec



On 10/18/18 9:59 AM, Ken Giusti wrote:

Hi Renat,

The biggest issue with the blocking executor (IMHO) is that it blocks 
the protocol I/O while  RPC processing is in progress.  This increases 
the likelihood that protocol processing will not get done in a timely 
manner and things start to fail in weird ways.  These failures are 
timing related and are typically hard to reproduce or root-cause.   This 
isn't something we can fix as blocking is the nature of the executor.


If we are to leave it in we'd really want to discourage its use.


Since it appears the actual executor code lives in futurist, would it be 
possible to remove the entrypoint for blocking from oslo.messaging and 
have mistral just pull it in with their setup.cfg? Seems like they 
should be able to add something like:


oslo.messaging.executors =
  blocking = futurist:SynchronousExecutor

to their setup.cfg to keep it available to them even if we drop it from 
oslo.messaging itself. That seems like a good way to strongly discourage 
use of it while still making it available to projects that are really 
sure they want it.




However I'm ok with leaving it available if the policy for using 
blocking is 'use at your own risk', meaning that bug reports may have to 
be marked 'won't fix' if we have reason to believe that blocking is at 
fault.  That implies removing 'blocking' as the default executor value 
in the API and having applications explicitly choose it.  And we keep 
the deprecation warning.


We could perhaps implement time duration checks around the executor 
callout and log a warning if the executor blocked for an extended amount 
of time (extended=TBD).


Other opinions so we can come to a consensus?


On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov > wrote:


Hi Oslo Team,

Can we retain “blocking” executor for now in Oslo Messaging?


Some background..

For a while we had to use Oslo Messaging with “blocking” executor in
Mistral because of incompatibility of MySQL driver with green
threads when choosing “eventlet” executor. Under certain conditions
we would get deadlocks between green threads. Some time ago we
switched to using PyMysql driver which is eventlet friendly and did
a number of tests that showed that we could safely switch to
“eventlet” executor (with that driver) so we introduced a new option
in Mistral where we could choose an executor in Oslo Messaging. The
corresponding bug is [1].

The issue is that we recently found that not everything actually
works as expected when using combination PyMysql + “eventlet”
executor. We also tried “threading” executor and the system *seems*
to work with it but surprisingly performance is much worse.

Given all of that we’d like to ask Oslo Team not to remove
“blocking” executor for now completely, if that’s possible. We have
a strong motivation to switch to “eventlet” for other reasons
(parallelism => better performance etc.) but seems like we need some
time to make it smoothly.


[1] https://bugs.launchpad.net/mistral/+bug/1696469


Thanks

Renat Akhmerov
@Nokia
__
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



--
Ken Giusti  (kgiu...@gmail.com )

__
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 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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-18 Thread Ken Giusti
Hi Renat,

The biggest issue with the blocking executor (IMHO) is that it blocks the
protocol I/O while  RPC processing is in progress.  This increases the
likelihood that protocol processing will not get done in a timely manner
and things start to fail in weird ways.  These failures are timing related
and are typically hard to reproduce or root-cause.   This isn't something
we can fix as blocking is the nature of the executor.

If we are to leave it in we'd really want to discourage its use.

However I'm ok with leaving it available if the policy for using blocking
is 'use at your own risk', meaning that bug reports may have to be marked
'won't fix' if we have reason to believe that blocking is at fault.  That
implies removing 'blocking' as the default executor value in the API and
having applications explicitly choose it.  And we keep the deprecation
warning.

We could perhaps implement time duration checks around the executor callout
and log a warning if the executor blocked for an extended amount of time
(extended=TBD).

Other opinions so we can come to a consensus?


On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov 
wrote:

> Hi Oslo Team,
>
> Can we retain “blocking” executor for now in Oslo Messaging?
>
>
> Some background..
>
> For a while we had to use Oslo Messaging with “blocking” executor in
> Mistral because of incompatibility of MySQL driver with green threads when
> choosing “eventlet” executor. Under certain conditions we would get
> deadlocks between green threads. Some time ago we switched to using PyMysql
> driver which is eventlet friendly and did a number of tests that showed
> that we could safely switch to “eventlet” executor (with that driver) so we
> introduced a new option in Mistral where we could choose an executor in
> Oslo Messaging. The corresponding bug is [1].
>
> The issue is that we recently found that not everything actually works as
> expected when using combination PyMysql + “eventlet” executor. We also
> tried “threading” executor and the system *seems* to work with it but
> surprisingly performance is much worse.
>
> Given all of that we’d like to ask Oslo Team not to remove “blocking”
> executor for now completely, if that’s possible. We have a strong
> motivation to switch to “eventlet” for other reasons (parallelism => better
> performance etc.) but seems like we need some time to make it smoothly.
>
>
> [1] https://bugs.launchpad.net/mistral/+bug/1696469
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> __
> 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
>


-- 
Ken Giusti  (kgiu...@gmail.com)
__
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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-18 Thread Renat Akhmerov
Hi Oslo Team,

Can we retain “blocking” executor for now in Oslo Messaging?


Some background..

For a while we had to use Oslo Messaging with “blocking” executor in Mistral 
because of incompatibility of MySQL driver with green threads when choosing 
“eventlet” executor. Under certain conditions we would get deadlocks between 
green threads. Some time ago we switched to using PyMysql driver which is 
eventlet friendly and did a number of tests that showed that we could safely 
switch to “eventlet” executor (with that driver) so we introduced a new option 
in Mistral where we could choose an executor in Oslo Messaging. The 
corresponding bug is [1].

The issue is that we recently found that not everything actually works as 
expected when using combination PyMysql + “eventlet” executor. We also tried 
“threading” executor and the system seems to work with it but surprisingly 
performance is much worse.

Given all of that we’d like to ask Oslo Team not to remove “blocking” executor 
for now completely, if that’s possible. We have a strong motivation to switch 
to “eventlet” for other reasons (parallelism => better performance etc.) but 
seems like we need some time to make it smoothly.


[1] https://bugs.launchpad.net/mistral/+bug/1696469


Thanks

Renat Akhmerov
@Nokia
__
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] [mistral] Extend created(updated)_at by started(finished)_at to clarify the duration of the task

2018-10-01 Thread Dougal Matthews
On Wed, 26 Sep 2018 at 12:03, Олег Овчарук  wrote:

> Hi everyone! Please take a look to the blueprint that i've just created
> https://blueprints.launchpad.net/mistral/+spec/mistral-add-started-finished-at
>
> I'd like to implement this feature, also I want to update CloudFlow when
> this will be done. Please let me know in the blueprint if I can start
> implementing.
>

I agree with Renat, this sounds like a useful addition to me. I have added
to to the Stein launchpad milestone.


> __
> 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 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] [mistral] Extend created(updated)_at by started(finished)_at to clarify the duration of the task

2018-09-27 Thread Renat Akhmerov
Hi Oleg,

I looked at the blueprint. Looks good to me, I understand the motivation 
behind. The fact that we use created_at and updated_at now to see the duration 
of the task is often confusing, I agree. So this would be a good addition and 
it is backward compatible. The only subtle thing is that when you make changes 
in CloudFlow we’ll have to make a note that since version X of CloudFlow (that 
will be using new fields to calculate durations) it will require Mistral Stein. 
Or, another option is to make it flexible: if those fields are present in the 
HTTP response, we can use them for calculation and if not, use the old way.

Thanks

Renat Akhmerov
@Nokia
On 26 Sep 2018, 18:02 +0700, Олег Овчарук , wrote:
> Hi everyone! Please take a look to the blueprint that i've just created  
> https://blueprints.launchpad.net/mistral/+spec/mistral-add-started-finished-at
> I'd like to implement this feature, also I want to update CloudFlow when this 
> will be done. Please let me know in the blueprint if I can start implementing.
> __
> 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 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] [mistral] Extend created(updated)_at by started(finished)_at to clarify the duration of the task

2018-09-26 Thread Олег Овчарук
Hi everyone! Please take a look to the blueprint that i've just created
https://blueprints.launchpad.net/mistral/+spec/mistral-add-started-finished-at

I'd like to implement this feature, also I want to update CloudFlow when
this will be done. Please let me know in the blueprint if I can start
implementing.
__
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] [mistral] [PTL] PTL on Vacation 17th - 28th September

2018-09-11 Thread Dougal Matthews
Hey all,

I'll be on vacation from 17th to the 28th of September. I don't anticipate
anything coming up but Renat Akhmerov is standing in as PTL while I'm out.

Cheers,
Dougal
__
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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

2018-09-07 Thread Pierre Gaxatte
> Backporting a migration like that is OK as long as you don't skip
> migrations, that is to say revision '030' of the database should be the
> same on all branches.  Given we've only just released rocky I expect
> that will be the case here.
> 
> You absolutely must have a release note and call it out as upgrade impact
> and of course this is a minor release not a patch release.
The release note was not in the initial change so here it is:
https://review.openstack.org/#/c/600018

Any input is welcome as the wording and content might not be exactly
what you expect.

Regards,
Pierre

__
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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

2018-09-06 Thread Tony Breeds
On Wed, Sep 05, 2018 at 10:54:25AM +0100, Dougal Matthews wrote:
> On 5 September 2018 at 10:52, Dougal Matthews  wrote:
> 
> > (Note: I added [release] to the email subject, as I think that will make
> > it visible to the right folks.)
> >
> 
> Darn. It should have been [stable]. I have added that now. Sorry for the
> noise.

Backporting a migration like that is OK as long as you don't skip
migrations, that is to say revision '030' of the database should be the
same on all branches.  Given we've only just released rocky I expect
that will be the case here.

You absolutely must have a release note and call it out as upgrade impact
and of course this is a minor release not a patch release.

If y'all push a release note (probably on master too?) then I'm okay
with the backport and release

Yours Tony.


signature.asc
Description: PGP signature
__
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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

2018-09-06 Thread Renat Akhmerov
I’m also in favour of backporting it because it solves a real production 
problem.

Thanks

Renat Akhmerov
@Nokia
On 5 Sep 2018, 16:55 +0700, Dougal Matthews , wrote:
> > On 5 September 2018 at 10:52, Dougal Matthews  wrote:
> > > > (Note: I added [release] to the email subject, as I think that will 
> > > > make it visible to the right folks.)
> >
> > Darn. It should have been [stable]. I have added that now. Sorry for the 
> > noise.
> >
> __
> 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 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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

2018-09-05 Thread Dougal Matthews
On 5 September 2018 at 10:52, Dougal Matthews  wrote:

> (Note: I added [release] to the email subject, as I think that will make
> it visible to the right folks.)
>

Darn. It should have been [stable]. I have added that now. Sorry for the
noise.
__
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] [mistral][release] Cherry-pick migration to stable/rocky

2018-09-05 Thread Dougal Matthews
On 5 September 2018 at 10:31, Pierre Gaxatte 
wrote:

> Hello,
>
> Related change: https://review.openstack.org/#/c/599606
>
> I'd like to push this to stable/rocky because this bug affects me in
> production and I'd like to be able to upgrade to rocky to fix this. I
> understand that new migrations should not be added to a stable branch
> and Renat Akhmerov advised me to ask here to make an exception.
>
> Now for some context on this bug:
>
> The `auth_context` in `delayed_calls_v2` holds the entire catalog
> provided by the client to run actions and currently it can hold 64kB on
> mysql (JsonDictType => TEXT field).
>
> Some of our customers have a large catalog because we expose many
> regions to them and a region weighs around 5kB in our catalog (many
> services, long URL for the endpoints...).
> So above around 10 regions presented to a project the catalog cannot be
> held in the `auth_context` field and no execution can be performed in
> mistral from this project.
>
> The change fixes that simply by increasing the maximum size of the field.
>
> So I'm seeking approval from the stable branch team to merge this change.
>
> Thanks,
> Pierre
>

Thanks for sending this email.

I am happy for the change to be backported, given the Rocky release is just
out the door the changes are minimal and easy to apply. The impact is also
high enough as it resolves problems for real production environments.

We should add a release note to the backport, but I am happy for this to be
added as a follow up (before we make the next Rocky release).

(Note: I added [release] to the email subject, as I think that will make it
visible to the right folks.)

Cheers
__
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] [mistral] Cherry-pick migration to stable/rocky

2018-09-05 Thread Pierre Gaxatte
Hello,

Related change: https://review.openstack.org/#/c/599606

I'd like to push this to stable/rocky because this bug affects me in
production and I'd like to be able to upgrade to rocky to fix this. I
understand that new migrations should not be added to a stable branch
and Renat Akhmerov advised me to ask here to make an exception.

Now for some context on this bug:

The `auth_context` in `delayed_calls_v2` holds the entire catalog
provided by the client to run actions and currently it can hold 64kB on
mysql (JsonDictType => TEXT field).

Some of our customers have a large catalog because we expose many
regions to them and a region weighs around 5kB in our catalog (many
services, long URL for the endpoints...).
So above around 10 regions presented to a project the catalog cannot be
held in the `auth_context` field and no execution can be performed in
mistral from this project.

The change fixes that simply by increasing the maximum size of the field.

So I'm seeking approval from the stable branch team to merge this change.

Thanks,
Pierre

__
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] [mistral] No Denver PTG Sessions

2018-08-21 Thread Renat Akhmerov
It’s disappointing that we can’t make it this time. Really bad coincidence of 
different issues..

I’d love to have a virtual PTG and Dmitry’s notes look very helpful to me.

Thanks

Renat Akhmerov
@Nokia
On 21 Aug 2018, 17:15 +0700, Dmitry Tantsur , wrote:
> On 08/21/2018 10:22 AM, Dougal Matthews wrote:
> > Hi all,
> >
> > Unfortunately due to some personal conflicts and trouble with travel plans,
> > there will be no Mistral cores at the Denver PTG. This means that we have 
> > had to
> > cancel the Mistral sessions. I recently asked if anyone was planning to 
> > attend
> > and only got one maybe.
> >
> > I am considering trying to arrange a "virtual PTG", so we can do some 
> > planning
> > for Stein. However, I'm not sure how/if that could work. Do you think this 
> > would
> > be a good idea? Suggestions how to organise one would be very welcome!
>
> We did a few virtual midcycles for ironic, and it ended up quite well. While 
> it
> did require some people to stay awake at unusual times, it did allow people
> without travel budget to attend.
>
> Initially we used the OpenStack SIP system, but we found Bluejeans to be a bit
> easier to use. I think it has a limit of 300 participants, which is more than
> enough. Anyone from Red Hat can host it.
>
> We dedicated 1-2 days with 4-5 hours each. I'd recommend against taking up the
> whole day - will be too exhausting. The first time we tried splitting the 
> slots
> into two per day: APAC friendly and EMEA friendly. Relatively few people 
> showed
> up at the former, so the next time we only had one slot.
>
> As with the PTG, having an agenda upfront helps a lot. We did synchronization
> and notes through an etherpad - exactly the same was as on the PTG.
>
> Hope that helps,
> Dmitry
>
> >
> > Thanks,
> > Dougal
> >
> >
> > __
> > 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 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 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] [mistral] No Denver PTG Sessions

2018-08-21 Thread Dmitry Tantsur

On 08/21/2018 10:22 AM, Dougal Matthews wrote:

Hi all,

Unfortunately due to some personal conflicts and trouble with travel plans, 
there will be no Mistral cores at the Denver PTG. This means that we have had to 
cancel the Mistral sessions. I recently asked if anyone was planning to attend 
and only got one maybe.


I am considering trying to arrange a "virtual PTG", so we can do some planning 
for Stein. However, I'm not sure how/if that could work. Do you think this would 
be a good idea? Suggestions how to organise one would be very welcome!


We did a few virtual midcycles for ironic, and it ended up quite well. While it 
did require some people to stay awake at unusual times, it did allow people 
without travel budget to attend.


Initially we used the OpenStack SIP system, but we found Bluejeans to be a bit 
easier to use. I think it has a limit of 300 participants, which is more than 
enough. Anyone from Red Hat can host it.


We dedicated 1-2 days with 4-5 hours each. I'd recommend against taking up the 
whole day - will be too exhausting. The first time we tried splitting the slots 
into two per day: APAC friendly and EMEA friendly. Relatively few people showed 
up at the former, so the next time we only had one slot.


As with the PTG, having an agenda upfront helps a lot. We did synchronization 
and notes through an etherpad - exactly the same was as on the PTG.


Hope that helps,
Dmitry



Thanks,
Dougal


__
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 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] [mistral] No Denver PTG Sessions

2018-08-21 Thread Dougal Matthews
Hi all,

Unfortunately due to some personal conflicts and trouble with travel plans,
there will be no Mistral cores at the Denver PTG. This means that we have
had to cancel the Mistral sessions. I recently asked if anyone was planning
to attend and only got one maybe.

I am considering trying to arrange a "virtual PTG", so we can do some
planning for Stein. However, I'm not sure how/if that could work. Do you
think this would be a good idea? Suggestions how to organise one would be
very welcome!

Thanks,
Dougal
__
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] [mistral] Denver PTG

2018-08-17 Thread Dougal Matthews
Hey all,

I wanted to reach out and see who is interested in attending the Mistral
sessions at the Denver PTG. Unfortunately I wont be able to make it but
Renat Akhmerov may be able to go and run the sessions. Most of the other
Mistral cores wont be able to attend unfortunately.

Please reply as soon as you can.

Thanks,
Dougal
__
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] mistral-dashboard 7.0.0.0rc1 (rocky)

2018-08-09 Thread no-reply

Hello everyone,

A new release candidate for mistral-dashboard for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


http://git.openstack.org/cgit/openstack/mistral-dashboard/log/?h=stable/rocky

Release notes for mistral-dashboard can be found at:

http://docs.openstack.org/releasenotes/mistral-dashboard/




__
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] mistral-extra 7.0.0.0rc1 (rocky)

2018-08-09 Thread no-reply

Hello everyone,

A new release candidate for mistral-extra for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral-extra/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/mistral-extra/log/?h=stable/rocky

Release notes for mistral-extra can be found at:

http://docs.openstack.org/releasenotes/mistral-extra/




__
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] mistral 7.0.0.0rc1 (rocky)

2018-08-09 Thread no-reply

Hello everyone,

A new release candidate for mistral for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/mistral/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/rocky

Release notes for mistral can be found at:

http://docs.openstack.org/releasenotes/mistral/




__
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] [mistral] Clearing out old gerrit reviews

2018-08-06 Thread Renat Akhmerov
Awesome! We need to do it periodically :) It’ll be easier to sort out patches.

Thanks

Renat Akhmerov
@Nokia
On 6 Aug 2018, 16:24 +0700, Dougal Matthews , wrote:
>
>
> > On 3 August 2018 at 10:45, Dougal Matthews  wrote:
> > > > On 9 July 2018 at 16:13, Dougal Matthews  wrote:
> > > > > Hey folks,
> > > > >
> > > > > I'd like to propose that we start abandoning old Gerrit reviews.
> > > > >
> > > > > This report shows how stale and out of date some of the reviews are:
> > > > > http://stackalytics.com/report/reviews/mistral-group/open
> > > > >
> > > > > I would like to initially abandon anything without any activity for a 
> > > > > year, but we might want to consider a shorter limit - maybe 6 months. 
> > > > > Reviews can be restored, so the risk is low.
> > > > >
> > > > > What do you think? Any objections or counter suggestions?
> > > > >
> > > > > If I don't hear any complaints, I'll go ahead with this next week (or 
> > > > > maybe the following week).
> > > >
> > > > That time line was ambitious. I didn't get started :-)
> > > >
> > > > However, I did decide it would be best to formalise this plan 
> > > > somewhere. So I quickly wrote up the plan in a Mistral policy spec. If 
> > > > we can agree there and merge it, then I'll go ahead and start the 
> > > > cleanup.
> > > >
> > > > https://review.openstack.org/#/c/588492/
> >
> > The spec merged today, so I did a first pass and abandoned 24 reviews that 
> > met the criteria.
> >
> > It will be interesting to see if any of them are restored.
> >
> > Dougal
> >
> >
> > > >
> > > >
> > > > >
> > > > > Cheers,
> > > > > Dougal
> > >
>
> __
> 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 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] [mistral] Clearing out old gerrit reviews

2018-08-06 Thread Dougal Matthews
On 3 August 2018 at 10:45, Dougal Matthews  wrote:

> On 9 July 2018 at 16:13, Dougal Matthews  wrote:
>
>> Hey folks,
>>
>> I'd like to propose that we start abandoning old Gerrit reviews.
>>
>> This report shows how stale and out of date some of the reviews are:
>> http://stackalytics.com/report/reviews/mistral-group/open
>>
>> I would like to initially abandon anything without any activity for a
>> year, but we might want to consider a shorter limit - maybe 6 months.
>> Reviews can be restored, so the risk is low.
>>
>> What do you think? Any objections or counter suggestions?
>>
>> If I don't hear any complaints, I'll go ahead with this next week (or
>> maybe the following week).
>>
>
> That time line was ambitious. I didn't get started :-)
>
> However, I did decide it would be best to formalise this plan somewhere.
> So I quickly wrote up the plan in a Mistral policy spec. If we can agree
> there and merge it, then I'll go ahead and start the cleanup.
>
> https://review.openstack.org/#/c/588492/
>

The spec merged today, so I did a first pass and abandoned 24 reviews that
met the criteria.

It will be interesting to see if any of them are restored.

Dougal



>
>
>
>>
>> Cheers,
>> Dougal
>>
>
>
__
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] [mistral] Clearing out old gerrit reviews

2018-08-03 Thread Adriano Petrich
Same.

On 3 August 2018 at 13:15, Renat Akhmerov  wrote:

> Dougal, the policy looks good for me. I gave it the second +2 but didn’t
> approve yet so that others could also review (e.g. Adriano and Vitalii).
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> On 3 Aug 2018, 16:46 +0700, Dougal Matthews , wrote:
>
> On 9 July 2018 at 16:13, Dougal Matthews  wrote:
>
>> Hey folks,
>>
>> I'd like to propose that we start abandoning old Gerrit reviews.
>>
>> This report shows how stale and out of date some of the reviews are:
>> http://stackalytics.com/report/reviews/mistral-group/open
>>
>> I would like to initially abandon anything without any activity for a
>> year, but we might want to consider a shorter limit - maybe 6 months.
>> Reviews can be restored, so the risk is low.
>>
>> What do you think? Any objections or counter suggestions?
>>
>> If I don't hear any complaints, I'll go ahead with this next week (or
>> maybe the following week).
>>
>
> That time line was ambitious. I didn't get started :-)
>
> However, I did decide it would be best to formalise this plan somewhere.
> So I quickly wrote up the plan in a Mistral policy spec. If we can agree
> there and merge it, then I'll go ahead and start the cleanup.
>
> https://review.openstack.org/#/c/588492/
>
>
>
>>
>> Cheers,
>> Dougal
>>
>
> __
> 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 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 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] [mistral] Clearing out old gerrit reviews

2018-08-03 Thread Renat Akhmerov
Dougal, the policy looks good for me. I gave it the second +2 but didn’t 
approve yet so that others could also review (e.g. Adriano and Vitalii).

Thanks

Renat Akhmerov
@Nokia
On 3 Aug 2018, 16:46 +0700, Dougal Matthews , wrote:
> > On 9 July 2018 at 16:13, Dougal Matthews  wrote:
> > > Hey folks,
> > >
> > > I'd like to propose that we start abandoning old Gerrit reviews.
> > >
> > > This report shows how stale and out of date some of the reviews are:
> > > http://stackalytics.com/report/reviews/mistral-group/open
> > >
> > > I would like to initially abandon anything without any activity for a 
> > > year, but we might want to consider a shorter limit - maybe 6 months. 
> > > Reviews can be restored, so the risk is low.
> > >
> > > What do you think? Any objections or counter suggestions?
> > >
> > > If I don't hear any complaints, I'll go ahead with this next week (or 
> > > maybe the following week).
> >
> > That time line was ambitious. I didn't get started :-)
> >
> > However, I did decide it would be best to formalise this plan somewhere. So 
> > I quickly wrote up the plan in a Mistral policy spec. If we can agree there 
> > and merge it, then I'll go ahead and start the cleanup.
> >
> > https://review.openstack.org/#/c/588492/
> >
> >
> > >
> > > Cheers,
> > > Dougal
>
> __
> 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 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] [mistral] Removing Inactive Cores

2018-08-03 Thread Renat Akhmerov
Lingxian, and any time welcome back as an active contributor if you wish! :) I 
want to thank you for all contribution and achievements you made for our 
project!

Renat Akhmerov
@Nokia
On 3 Aug 2018, 17:14 +0700, Lingxian Kong , wrote:
> +1 for me, i am still watching mistral :-)
>
> Cheers,
> Lingxian Kong
>
>
> > On Fri, Aug 3, 2018 at 9:58 PM Dougal Matthews  wrote:
> > > Hey,
> > >
> > > As we are approaching the end of Rocky I am doing some house keeping.
> > >
> > > The people below have been removed from the Mistral core team due to 
> > > reviewing inactivity in the last 180 days[1]. I would like to thank them 
> > > for their contributions and they are welcome to re-join the Mistral core 
> > > team if they become active in the future.
> > >
> > > - Lingxian Kong
> > > - Winson Chan
> > >
> > > [1] http://stackalytics.com/report/contribution/mistral-group/180
> > >
> > > Thanks,
> > > Dougal
> > > __
> > > 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 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 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] [mistral] Removing Inactive Cores

2018-08-03 Thread Lingxian Kong
+1 for me, i am still watching mistral :-)

Cheers,
Lingxian Kong


On Fri, Aug 3, 2018 at 9:58 PM Dougal Matthews  wrote:

> Hey,
>
> As we are approaching the end of Rocky I am doing some house keeping.
>
> The people below have been removed from the Mistral core team due to
> reviewing inactivity in the last 180 days[1]. I would like to thank them
> for their contributions and they are welcome to re-join the Mistral core
> team if they become active in the future.
>
> - Lingxian Kong
> - Winson Chan
>
> [1] http://stackalytics.com/report/contribution/mistral-group/180
>
> Thanks,
> Dougal
> __
> 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 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] [mistral] Removing Inactive Cores

2018-08-03 Thread Dougal Matthews
Hey,

As we are approaching the end of Rocky I am doing some house keeping.

The people below have been removed from the Mistral core team due to
reviewing inactivity in the last 180 days[1]. I would like to thank them
for their contributions and they are welcome to re-join the Mistral core
team if they become active in the future.

- Lingxian Kong
- Winson Chan

[1] http://stackalytics.com/report/contribution/mistral-group/180

Thanks,
Dougal
__
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] [mistral] Clearing out old gerrit reviews

2018-08-03 Thread Dougal Matthews
On 9 July 2018 at 16:13, Dougal Matthews  wrote:

> Hey folks,
>
> I'd like to propose that we start abandoning old Gerrit reviews.
>
> This report shows how stale and out of date some of the reviews are:
> http://stackalytics.com/report/reviews/mistral-group/open
>
> I would like to initially abandon anything without any activity for a
> year, but we might want to consider a shorter limit - maybe 6 months.
> Reviews can be restored, so the risk is low.
>
> What do you think? Any objections or counter suggestions?
>
> If I don't hear any complaints, I'll go ahead with this next week (or
> maybe the following week).
>

That time line was ambitious. I didn't get started :-)

However, I did decide it would be best to formalise this plan somewhere. So
I quickly wrote up the plan in a Mistral policy spec. If we can agree there
and merge it, then I'll go ahead and start the cleanup.

https://review.openstack.org/#/c/588492/



>
> Cheers,
> Dougal
>
__
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] [mistral] Mistral Monthly August 2018

2018-08-01 Thread Dougal Matthews
Hey everyone!

It is time to wrap-up the last month and have a look and see what has
happened.


# General News

We are now close to the end of the Rocky release cycle! It has been a
pleasure serving at the PTL and it looks like you are stuck with me for
Stein :)

- https://governance.openstack.org/election/

I would be interested to hear about high levels goals and themes for Stein.
What do you think the project should do and focus on? Let me know!


# Releases

- The finaly Rocky releases were made for mistral-lib and
python-mistralclient
- https://docs.openstack.org/releasenotes/python-mistralclient/rocky.html
- Next week we will release the RC1 for mistral, mistral-dashboard and
mistral-extra
- We skipped RC3 for the above repos, due to CI issues and other delays.
The changes can wait for the RC1 release


# Notable Changes and Additions

- 17 new actions for OpenStack Tacker were added
- A new policy was added to control which users can create and update
actions and workflows
- A new configuration option (oslo_rpc_executor) was added to change the
oslo RPC executor. It can now be eventlet, blocking or threading
- A new keystone configuration group was added, replacing the
keystone_authtoken group (which is now deprecated, but not removed)
- 166 new actions were added for OpenStack Manila
- Workbooks now support namespaces, previously only Workflows had support
- The Mistral development container now supports Keycloak

Lots of other small changes and bug fixes! It has been a busy month :)


# Milestones, Reviews, Bugs and Blueprints

- 55 commits and 251 reviews
- 100 Open bugs (Down from 105, yay!)
- Rocky-3 numbers:
Blueprints: 1 Unknown, 4 Not started, 3 Started, 1 Slow progress, 2
Implemented
Bugs: 1 Incomplete, 3 Invalid, 20 Confirmed, 7 Triaged, 8 In Progress,
21 Fix Released

Lots of bug fixes landed, good work!

Thanks all,
Dougal
__
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] [mistral] Clearing out old gerrit reviews

2018-07-10 Thread Adriano Petrich
Agreed.

On 10 July 2018 at 05:42, Renat Akhmerov  wrote:

> Dougal, I’m totally OK with this idea.
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> On 9 Jul 2018, 22:14 +0700, Dougal Matthews , wrote:
>
> Hey folks,
>
> I'd like to propose that we start abandoning old Gerrit reviews.
>
> This report shows how stale and out of date some of the reviews are:
> http://stackalytics.com/report/reviews/mistral-group/open
>
> I would like to initially abandon anything without any activity for a
> year, but we might want to consider a shorter limit - maybe 6 months.
> Reviews can be restored, so the risk is low.
>
> What do you think? Any objections or counter suggestions?
>
> If I don't hear any complaints, I'll go ahead with this next week (or
> maybe the following week).
>
> Cheers,
> Dougal
> __
> 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 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 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] [mistral] Clearing out old gerrit reviews

2018-07-09 Thread Renat Akhmerov
Dougal, I’m totally OK with this idea.

Thanks

Renat Akhmerov
@Nokia
On 9 Jul 2018, 22:14 +0700, Dougal Matthews , wrote:
> Hey folks,
>
> I'd like to propose that we start abandoning old Gerrit reviews.
>
> This report shows how stale and out of date some of the reviews are:
> http://stackalytics.com/report/reviews/mistral-group/open
>
> I would like to initially abandon anything without any activity for a year, 
> but we might want to consider a shorter limit - maybe 6 months. Reviews can 
> be restored, so the risk is low.
>
> What do you think? Any objections or counter suggestions?
>
> If I don't hear any complaints, I'll go ahead with this next week (or maybe 
> the following week).
>
> Cheers,
> Dougal
> __
> 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 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] [mistral] Clearing out old gerrit reviews

2018-07-09 Thread Dougal Matthews
Hey folks,

I'd like to propose that we start abandoning old Gerrit reviews.

This report shows how stale and out of date some of the reviews are:
http://stackalytics.com/report/reviews/mistral-group/open

I would like to initially abandon anything without any activity for a year,
but we might want to consider a shorter limit - maybe 6 months. Reviews can
be restored, so the risk is low.

What do you think? Any objections or counter suggestions?

If I don't hear any complaints, I'll go ahead with this next week (or maybe
the following week).

Cheers,
Dougal
__
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] [mistral][ptl] PTL On Vacation 3rd - 6th July

2018-07-02 Thread Dougal Matthews
Hey all,

I'll be out for the rest of the week after today. I don't anticipate
anything coming up but Renat Akhmerov is standing in as PTL while I'm out.

See you all on Monday next week.

Cheers,
Dougal
__
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] [mistral] Mistral Monthly July 2018

2018-07-02 Thread Dougal Matthews
Hey Mistralites!

Here is your monthly recap of whats what in the Mistral community. Arriving
to you a day late as the 1st was a Sunday. When that happens I'll just aim
to send it as close to the 1st as I can. Either slightly early or slightly
late.


# General News

Vitalii Solodilov joined the Mistral core team. He has been contributing
regularly with high quality patches and reviews for a while now. Welcome
aboard!


# Releases

No releases this month. Rocky-3 is at the end of July, so we will see more
release activity this month.


# Notable Changes and Additions

- The action-execution-reporting blueprint was completed. This work sees a
heatbeat used to check that action executions are still running. If they
have stopped they will be closed. Previously they would be stuck in the
RUNNING state.
- A number of configuration options were added to change settings in the
YAQL engine.


# Milestones, Reviews, Bugs and Blueprints

- 26 commits and 222 reviews
- 105 Open bugs (no change from last month).
- Rocky-3 numbers:
Blueprints: 1 Unknown, 4 Not started, 3 Started, 1 Slow progress, 2
Implemented
Bugs: 2 Incomplete, 2 Invalid, 16 Confirmed, 7 Triaged, 13 In Progress,
3 Fix Released



That's all I have for this month! We have lots to do for Rocky-3, so back
to work! :-)

Dougal
__
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] [mistral] Promoting Vitalii Solodilov to the Mistral core team

2018-06-21 Thread Dougal Matthews
On 19 June 2018 at 10:27, Renat Akhmerov  wrote:

> Hi,
>
> I’d like to promote Vitalii Solodilov to the core team of Mistral. In my
> opinion, Vitalii is a very talented engineer  who has been demonstrating it
> by providing very high quality code and reviews in the last 6-7 months.
> He’s one of the people who doesn’t hesitate taking responsibility for
> solving challenging technical tasks. It’s been a great pleasure to work
> with Vitalii and I hope can will keep up doing great job.
>
> Core members, please vote.
>


Thanks all for the votes and thank you Renat for nominating. I have added
Vitalii to the core reviewers. Welcome aboard, you can now +2! :-)




>
> Vitalii’s statistics: http://stackalytics.com/?module=
> mistral-group=marks_id=mcdoker18
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> 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 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] [mistral] Promoting Vitalii Solodilov to the Mistral core team

2018-06-21 Thread Adriano Petrich
+1

On 19 June 2018 at 10:47, Dougal Matthews  wrote:

>
>
> On 19 June 2018 at 10:27, Renat Akhmerov  wrote:
>
>> Hi,
>>
>> I’d like to promote Vitalii Solodilov to the core team of Mistral. In my
>> opinion, Vitalii is a very talented engineer  who has been demonstrating it
>> by providing very high quality code and reviews in the last 6-7 months.
>> He’s one of the people who doesn’t hesitate taking responsibility for
>> solving challenging technical tasks. It’s been a great pleasure to work
>> with Vitalii and I hope can will keep up doing great job.
>>
>> Core members, please vote.
>>
>
> +1 from me. Vitalii has been one of the most active reviewers and code
> contributors through Queens and Rocky.
>
>
> Vitalii’s statistics: http://stackalytics.com/?module=mistral-group;
>> metric=marks_id=mcdoker18
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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 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] [mistral] Promoting Vitalii Solodilov to the Mistral core team

2018-06-19 Thread Dougal Matthews
On 19 June 2018 at 10:27, Renat Akhmerov  wrote:

> Hi,
>
> I’d like to promote Vitalii Solodilov to the core team of Mistral. In my
> opinion, Vitalii is a very talented engineer  who has been demonstrating it
> by providing very high quality code and reviews in the last 6-7 months.
> He’s one of the people who doesn’t hesitate taking responsibility for
> solving challenging technical tasks. It’s been a great pleasure to work
> with Vitalii and I hope can will keep up doing great job.
>
> Core members, please vote.
>

+1 from me. Vitalii has been one of the most active reviewers and code
contributors through Queens and Rocky.


Vitalii’s statistics: http://stackalytics.com/?module=
> mistral-group=marks_id=mcdoker18
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> 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 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] [mistral] Promoting Vitalii Solodilov to the Mistral core team

2018-06-19 Thread András Kövi
+1 well deserved!

Renat Akhmerov  ezt írta (időpont: 2018. jún.
19., K, 11:28):

> Hi,
>
> I’d like to promote Vitalii Solodilov to the core team of Mistral. In my
> opinion, Vitalii is a very talented engineer  who has been demonstrating it
> by providing very high quality code and reviews in the last 6-7 months.
> He’s one of the people who doesn’t hesitate taking responsibility for
> solving challenging technical tasks. It’s been a great pleasure to work
> with Vitalii and I hope can will keep up doing great job.
>
> Core members, please vote.
>
> Vitalii’s statistics:
> http://stackalytics.com/?module=mistral-group=marks_id=mcdoker18
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> __
> 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 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] [mistral] Promoting Vitalii Solodilov to the Mistral core team

2018-06-19 Thread Renat Akhmerov
Hi,

I’d like to promote Vitalii Solodilov to the core team of Mistral. In my 
opinion, Vitalii is a very talented engineer  who has been demonstrating it by 
providing very high quality code and reviews in the last 6-7 months. He’s one 
of the people who doesn’t hesitate taking responsibility for solving 
challenging technical tasks. It’s been a great pleasure to work with Vitalii 
and I hope can will keep up doing great job.

Core members, please vote.

Vitalii’s statistics: 
http://stackalytics.com/?module=mistral-group=marks_id=mcdoker18

Thanks

Renat Akhmerov
@Nokia
__
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] [mistral] Mistral Monthly June 2018

2018-06-01 Thread Dougal Matthews
Hey Mistralites!

Welcome to the second edition of Mistral Monthly.

# Summit

Brad Crochet done a great job giving the Mistral project update talk. Check
it out: https://www.youtube.com/watch?v=y9qieruccO4

Also checkout the Congress update, they discuss their recent support for
Mistral. https://www.youtube.com/watch?v=5YYcysVyLCo


# Releases

Fairly quiet this month. Just a few bugfix releases. One still in flight.

- Pike
  - Mistral 5.2.4 will be released soon: https://review.openstack.org/#
/c/568881/
- Queens
  - Mistral 6.0.3 https://docs.openstack.org/releasenotes/mistral/queens.
html

Rocky Milestone 2 will be released next week. So there will be more release
news next time.


# Notable changes and additions

- We now have Zun and Qinling OpenStack actions in master.
- Two significant performance improvements were made relating to workflow
environments and the deletion of objects.
- Mistral is now using stestr in all repos. For more details, see:
https://review.openstack.org/#/c/519751/


# Milestones, Reviews, Bugs and Blueprints

- We have 105 open bugs (down from 109 last month).
  - Zero are untriaged
  - One is "critical" (but that is likely a lie as it has been critical and
ignored for some time)
- Rocky-2 still now has 58 bugs assigned to it (it was 44 last month!).
Only 13 are fixed released. Most of these will move to Rocky-3 next week.
- 4 blueprints are targeted at Rocky 2 (I have already bumped 4 that were
inactive). Two are implemented. The other two will likely slip to Rocky-3
- 29 commits were merged.
- There were 176 reviews in total, 126 of these from the core team.


That's all for this time. See you next month!

Dougal


P.S. The format of this newsletter is still somewhat fluid. Feedback would
be very welcome. What do you find interesting or useful? What is missing?
__
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] [mistral] Skipping Office Hours on Monday

2018-05-04 Thread Dougal Matthews
Hey folks,

I forgot to say - I wont be around on Monday for office hours. Feel free to
carry on without me. It should be less formal than a meeting, so anyone can
chat - just send some messages to #openstack-mistral so folks know you are
around for it.

The ehterpad has a pinglist you can use to remind regulars.

https://etherpad.openstack.org/p/mistral-office-hours

Cheers,
Dougal
__
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] [mistral] Help with test run

2018-05-01 Thread András Kövi
Thanks Clark,

I’m pretty sure the UTs would conflict with each other so raising the 
concurrency is probably a big undertaking. Though it’s definitely worth looking 
into in the future. Shifting the job timeout a little bit maybe a the simplest 
solution.

Thanks again,
Andras

_
From: Clark Boylan <cboy...@sapwetik.org>
Sent: Tuesday, May 1, 2018 6:12 PM
Subject: Re: [openstack-dev] [mistral] Help with test run
To: <openstack-dev@lists.openstack.org>


On Fri, Apr 27, 2018, at 2:22 AM, András Kövi wrote:
> Hi,
>
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/

Reading the job log the job setup only took a few minutes. Then the unittests 
start and are running continuously until the timeout happens at 30 minutes. 
Chances are that the default 30 minute timeout is not sufficient for this job. 
Runtime may vary based on cloud region and presence of noisy neighbors.

As for making this more reliable you can increase the timeout in the job 
configuration for that job. Another approach would be to make the unittests run 
more quickly. I notice the job is hard coded to use concurrency=1 when invoking 
the test runner so you are only using ~1/8 of the available cpus. You might try 
increasing this value though will likely need to make sure the tests don't 
conflict with each other.

Clark

__
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 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] [mistral] Help with test run

2018-05-01 Thread András Kövi
Thanks Brad for the check. Yes it’s quite consistent.

_
From: Brad P. Crochet <b...@redhat.com>
Sent: Tuesday, May 1, 2018 5:13 PM
Subject: Re: [openstack-dev] [mistral] Help with test run
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>




On Fri, Apr 27, 2018 at 5:23 AM András Kövi 
<allp...@gmail.com<mailto:allp...@gmail.com>> wrote:
Hi,

Can someone please help me with why this build ended with TIMED_OUT?
http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/


I'm not seeing any particular reason for it. Is it happening consistently?

Thanks,
Andras

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385



__
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] [mistral] Help with test run

2018-05-01 Thread Clark Boylan
On Fri, Apr 27, 2018, at 2:22 AM, András Kövi wrote:
> Hi,
> 
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/

Reading the job log the job setup only took a few minutes. Then the unittests 
start and are running continuously until the timeout happens at 30 minutes. 
Chances are that the default 30 minute timeout is not sufficient for this job. 
Runtime may vary based on cloud region and presence of noisy neighbors.

As for making this more reliable you can increase the timeout in the job 
configuration for that job. Another approach would be to make the unittests run 
more quickly. I notice the job is hard coded to use concurrency=1 when invoking 
the test runner so you are only using ~1/8 of the available cpus. You might try 
increasing this value though will likely need to make sure the tests don't 
conflict with each other.

Clark

__
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] [mistral] Help with test run

2018-05-01 Thread Brad P. Crochet
On Fri, Apr 27, 2018 at 5:23 AM András Kövi  wrote:

> Hi,
>
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/
>
>
I'm not seeing any particular reason for it. Is it happening consistently?


> Thanks,
> Andras
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [mistral] Mistral Monthly May 2018

2018-05-01 Thread Dougal Matthews
Hey Folks!

Welcome to the first Mistral Monthly newsletter!

# Intro

I am going to try sending out a monthly newsletter summarising what is
going on in the world of Mistral. This is an experiment, so feedback would
be very welcome! If you have something you want me to share for next time,
please let me know (or if I missed something this round please reply here).
There is no fixed structure, but that may happen over time. I'll aim to
send it on the 1st of each month.


# Releases

There were quite a few releases in April. I expect there will be a bugfix
release for Queens and Pike this month.

- Rocky
  - Rocky-1 Milestone
https://docs.openstack.org/releasenotes/mistral/unreleased.html
  - mistral-lib 0.5.0 [We don't publish the release notes, we need to fix
that]
  - python-mistralclient 3.4.0
https://docs.openstack.org/releasenotes/python-mistralclient/unreleased.html
- Queens
  - Mistral 6.0.2
https://docs.openstack.org/releasenotes/mistral/queens.html
- Pike
  - Mistral 5.2.3 https://docs.openstack.org/releasenotes/mistral/pike.html

Rocky-2 is due to be released by June 8th.


# Office Hours - https://etherpad.openstack.org/p/mistral-office-hours

The Mistral office hours have been happening regularly on Mondays and
Fridays now. Participation has been good and it has seen a wider and more
varied attendance than the weekly Mistral meetings.

We usually chat about bugs and features that people are interested in. if
there is nothing specific we take the time to do some bug triage. Please
bring yourself and topics to discuss! If none of the current time slots
suit you, please propose an additional one.


# Notable changes and additions

- In Rocky we will have support for Swiftservice and Vitrage actions.
- Workflow executions can no longer be deleted while they are still running
unless the force parameter is provided. This is a backwards incompatible
change, but makes the default behaviour much safer.
- Support for py_mini_racer, a easier to install JavaScript implementation,
was added. Users now have the choice of pyv8, v8eval or py_mini_racer.

# Milestones, Reviews, Bugs and Blueprints

(This will be more interesting in the next edition, when we can see what
changes. Stackalytics is also down, so I can't grab all the stats I wanted)

- We currently have 109 open bugs
  - We now have zero untriaged bugs! This is largely due to the
collaboration during office hours.
  - Two bugs are "critical"
  - The number of open bugs reduced from around 180 a month ago
- 44 bugs are targeted towards Rocky-2 - that is ambitious to say the
least. During Rocky-1 we fixed 23 bugs
- 8 blueprints are targeted for Rocky-2 (3 were implemented in Rocky-1)


That's all for this time. See you next month!

Dougal

[If you get this far, please ping d0ugal on freenode and let me know. I am
just curious to know roughly how many folks are reading. Thanks!]
__
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] ​ [mistral] timeout and retry

2018-04-27 Thread Vitalii Solodilov
Thanks for confirmation.Ticket https://bugs.launchpad.net/mistral/+bug/1767352I will try to fix it. 27.04.2018, 12:02, "Renat Akhmerov" :Yep, agree that this is a bug. We need to fix that. Would you please create a ticket at LP?ThanksRenat Akhmerov@NokiaOn 27 Apr 2018, 12:53 +0700, Vitalii Solodilov , wrote:> No matter at what stage the task is, but if it’s still in RUNNING state or FAILED but we know that retry policy still didn’t use all attempts then the ‘timeout’ policy should force the task to fail.Ok, then we have a bug because timeout policy doesn't force the task to fail. It retries task. And after that, we have two running action parallel.https://github.com/openstack/mistral/blob/master/mistral/engine/policies.py#L537 27.04.2018, 07:50, "Renat Akhmerov" :Hi, I don’t clearly understand the problem you’re trying to point to. IMO, when using these two policies at the same time ‘timeout’ policy should have higher priority. No matter at what stage the task is, but if it’s still in RUNNING state or FAILED but we know that retry policy still didn’t use all attempts then the ‘timeout’ policy should force the task to fail. If it’s the second case when it’s FAILED but the retry policy is still in play then we need to leave some ‘force’ marker in the task state to make sure that there’s no need to retry it further.ThanksRenat Akhmerov@NokiaOn 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , wrote:Hi Renat, Can you explain me and Dougal how timeout policy should work with retry policy?I guess there is bug right now.The behaviour is something like this https://ibb.co/hhm0eHExample: https://review.openstack.org/#/c/563759/Logs: http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083Even we will fix this bug and after task timeout we will not retry task. I don't understand which problem is decided by this timeout and retry.Other problem. What about task retry? I mean using mistral api. The problem is that timeout delayed calls was not created.IMHO the combination of these policies should work like this https://ibb.co/fe5tzHIt is not a timeout per action because when task retry it move to some complete state and then back to RUNNING state. And it will work fine with with-items policy.The main advantage is executor and rabbitmq HA. I can specify small timeout if executor will die the task retried by timeout and create new action.The second is predictable behaviour. When I specify timeout: 10 and retry.count: 5 I know that will be create maximum 5 action before SUCCESS state and every action will be executes no longer than 10 seconds.-- Best regards,Vitalii Solodilov   -- Best regards, Vitalii Solodilov   -- Best regards, Vitalii Solodilov __
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] [mistral] Help with test run

2018-04-27 Thread András Kövi
Hi,

Can someone please help me with why this build ended with TIMED_OUT?
http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/

Thanks,
Andras

__
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] ​[openstack-dev] [mistral] timeout and retry

2018-04-27 Thread Renat Akhmerov
Yep, agree that this is a bug. We need to fix that. Would you please create a 
ticket at LP?

Thanks

Renat Akhmerov
@Nokia

On 27 Apr 2018, 12:53 +0700, Vitalii Solodilov , wrote:
> > No matter at what stage the task is, but if it’s still in RUNNING state or 
> > FAILED but we know that retry policy still didn’t use all attempts then the 
> > ‘timeout’ policy should force the task to fail.
> Ok, then we have a bug because timeout policy doesn't force the task to fail. 
> It retries task. And after that, we have two running action parallel.
> https://github.com/openstack/mistral/blob/master/mistral/engine/policies.py#L537
>
> 27.04.2018, 07:50, "Renat Akhmerov" :
> > Hi,
> >
> > I don’t clearly understand the problem you’re trying to point to.
> >
> > IMO, when using these two policies at the same time ‘timeout’ policy should 
> > have higher priority. No matter at what stage the task is, but if it’s 
> > still in RUNNING state or FAILED but we know that retry policy still didn’t 
> > use all attempts then the ‘timeout’ policy should force the task to fail. 
> > If it’s the second case when it’s FAILED but the retry policy is still in 
> > play then we need to leave some ‘force’ marker in the task state to make 
> > sure that there’s no need to retry it further.
> >
> > Thanks
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , wrote:
> > > Hi Renat, Can you explain me and Dougal how timeout policy should work 
> > > with retry policy?
> > >
> > > I guess there is bug right now.
> > > The behaviour is something like this https://ibb.co/hhm0eH
> > > Example: https://review.openstack.org/#/c/563759/
> > > Logs: 
> > > http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083
> > > Even we will fix this bug and after task timeout we will not retry task. 
> > > I don't understand which problem is decided by this timeout and retry.
> > > Other problem. What about task retry? I mean using mistral api. The 
> > > problem is that timeout delayed calls was not created.
> > >
> > > IMHO the combination of these policies should work like this 
> > > https://ibb.co/fe5tzH
> > > It is not a timeout per action because when task retry it move to some 
> > > complete state and then back to RUNNING state. And it will work fine with 
> > > with-items policy.
> > > The main advantage is executor and rabbitmq HA. I can specify small 
> > > timeout if executor will die the task retried by timeout and create new 
> > > action.
> > > The second is predictable behaviour. When I specify timeout: 10 and 
> > > retry.count: 5 I know that will be create maximum 5 action before SUCCESS 
> > > state and every action will be executes no longer than 10 seconds.
> > >
> > > --
> > > Best regards,
> > >
> > > Vitalii Solodilov
> > >
>
>
> --
> Best regards,
>
> Vitalii Solodilov
>
__
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] ​ [mistral] timeout and retry

2018-04-26 Thread Vitalii Solodilov
> No matter at what stage the task is, but if it’s still in RUNNING state or FAILED but we know that retry policy still didn’t use all attempts then the ‘timeout’ policy should force the task to fail.Ok, then we have a bug because timeout policy doesn't force the task to fail. It retries task. And after that, we have two running action parallel.https://github.com/openstack/mistral/blob/master/mistral/engine/policies.py#L537 27.04.2018, 07:50, "Renat Akhmerov" :Hi, I don’t clearly understand the problem you’re trying to point to. IMO, when using these two policies at the same time ‘timeout’ policy should have higher priority. No matter at what stage the task is, but if it’s still in RUNNING state or FAILED but we know that retry policy still didn’t use all attempts then the ‘timeout’ policy should force the task to fail. If it’s the second case when it’s FAILED but the retry policy is still in play then we need to leave some ‘force’ marker in the task state to make sure that there’s no need to retry it further.ThanksRenat Akhmerov@NokiaOn 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , wrote:Hi Renat, Can you explain me and Dougal how timeout policy should work with retry policy?I guess there is bug right now.The behaviour is something like this https://ibb.co/hhm0eHExample: https://review.openstack.org/#/c/563759/Logs: http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083Even we will fix this bug and after task timeout we will not retry task. I don't understand which problem is decided by this timeout and retry.Other problem. What about task retry? I mean using mistral api. The problem is that timeout delayed calls was not created.IMHO the combination of these policies should work like this https://ibb.co/fe5tzHIt is not a timeout per action because when task retry it move to some complete state and then back to RUNNING state. And it will work fine with with-items policy.The main advantage is executor and rabbitmq HA. I can specify small timeout if executor will die the task retried by timeout and create new action.The second is predictable behaviour. When I specify timeout: 10 and retry.count: 5 I know that will be create maximum 5 action before SUCCESS state and every action will be executes no longer than 10 seconds.-- Best regards,Vitalii Solodilov   -- Best regards, Vitalii Solodilov __
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] [mistral] A mechanism to close stuck running executions

2018-04-26 Thread András Kövi
Hi Vitalii,
thanks for reminding. I've almost forgotten about it.
I've updated with the stuff we have tested locally for months.
Looking forward to your comments!

Thanks,
Andras
Vitalii Solodilov  ezt írta (időpont: 2018. ápr. 27., P,
3:31):

> Hi, Jozsef and Andras.
> Do you plan to finish this patch? https://review.openstack.org/#/c/527085
> I think the stuck RUNNING executions is very a sensitive subject for
Mistral.

> --
> Best regards,

> Vitalii Solodilov


> __
> 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 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] ​[openstack-dev] [mistral] timeout and retry

2018-04-26 Thread Renat Akhmerov
Hi,

I don’t clearly understand the problem you’re trying to point to.

IMO, when using these two policies at the same time ‘timeout’ policy should 
have higher priority. No matter at what stage the task is, but if it’s still in 
RUNNING state or FAILED but we know that retry policy still didn’t use all 
attempts then the ‘timeout’ policy should force the task to fail. If it’s the 
second case when it’s FAILED but the retry policy is still in play then we need 
to leave some ‘force’ marker in the task state to make sure that there’s no 
need to retry it further.

Thanks

Renat Akhmerov
@Nokia

On 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , wrote:
> Hi Renat, Can you explain me and Dougal how timeout policy should work with 
> retry policy?
>
> I guess there is bug right now.
> The behaviour is something like this https://ibb.co/hhm0eH
> Example: https://review.openstack.org/#/c/563759/
> Logs: 
> http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083
> Even we will fix this bug and after task timeout we will not retry task. I 
> don't understand which problem is decided by this timeout and retry.
> Other problem. What about task retry? I mean using mistral api. The problem 
> is that timeout delayed calls was not created.
>
> IMHO the combination of these policies should work like this 
> https://ibb.co/fe5tzH
> It is not a timeout per action because when task retry it move to some 
> complete state and then back to RUNNING state. And it will work fine with 
> with-items policy.
> The main advantage is executor and rabbitmq HA. I can specify small timeout 
> if executor will die the task retried by timeout and create new action.
> The second is predictable behaviour. When I specify timeout: 10 and 
> retry.count: 5 I know that will be create maximum 5 action before SUCCESS 
> state and every action will be executes no longer than 10 seconds.
>
> --
> Best regards,
>
> Vitalii Solodilov
>
__
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] [mistral] A mechanism to close stuck running executions

2018-04-26 Thread Vitalii Solodilov
Hi, Jozsef and Andras.
Do you plan to finish this patch? https://review.openstack.org/#/c/527085
I think the stuck RUNNING executions is very a sensitive subject for Mistral. 

-- 
Best regards,

Vitalii Solodilov


__
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] [mistral] September PTG in Denver

2018-04-25 Thread Kendall Nelson
Hey Sean :)

The reason why we picked the May 2nd date was so that people would know if
they needed to register before the early bird pricing closes. If groups
feel like they need more time to decide that's fine. It would still be
helpful if those needing more time could fill the survey with the 'Maybe,
Still Deciding' answer so I can circle back later for a hard 'Yes,
Absolutely' or a 'No, Certainly Not' :)

-Kendall (diablo_rojo)

On Mon, Apr 23, 2018 at 12:58 PM Sean McGinnis 
wrote:

> On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> > Hey Dougal,
> >
> > I think I had said May 2nd in my initial email asking about attendance.
> If
> > you can get an answer out of your team by then I would greatly appreciate
> > it! If you need more time please let me know by then (May 2nd) instead.
> >
> > -Kendall (diablo_rojo)
> >
>
> Do we need to collect this data for September already by the beginning of
> May?
>
> Granted, the sooner we know details and can start planning, the better.
> But as
> I started looking over the survey, it just seems really early to predict
> where
> things will be 5 months from now. Especially considering we will have a
> different set of PTLs for many projects by then, and it is too early for
> some
> of those hand off discussions to have started yet.
>
> Sean
>
> __
> 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 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] [mistral] September PTG in Denver

2018-04-24 Thread András Kövi
Hi Dougal,

Very likely, I will join over the phone.

Thanks,
Andras


From: Renat Akhmerov <renat.akhme...@gmail.com>
Sent: Tuesday, April 24, 2018 2:46:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] September PTG in Denver

Dougal,

Most likely, I’ll go.

Thanks

Renat Akhmerov
@Nokia

24 апр. 2018 г., 17:05 +0700, Dougal Matthews <dou...@redhat.com>, писал:


On 23 April 2018 at 20:58, Sean McGinnis 
<sean.mcgin...@gmx.com<mailto:sean.mcgin...@gmx.com>> wrote:
On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> Hey Dougal,
>
> I think I had said May 2nd in my initial email asking about attendance. If
> you can get an answer out of your team by then I would greatly appreciate
> it! If you need more time please let me know by then (May 2nd) instead.

Whoops - thanks for the correction.

>
> -Kendall (diablo_rojo)
>

Do we need to collect this data for September already by the beginning of May?

Granted, the sooner we know details and can start planning, the better. But as
I started looking over the survey, it just seems really early to predict where
things will be 5 months from now. Especially considering we will have a
different set of PTLs for many projects by then, and it is too early for some
of those hand off discussions to have started yet.

Good question! I don't mean to ask people to commit 100% or not, I just want to 
know their intentions so I have more information when filling out the survey.


Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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 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] [mistral] September PTG in Denver

2018-04-24 Thread Renat Akhmerov
Dougal,

Most likely, I’ll go.

Thanks

Renat Akhmerov
@Nokia

24 апр. 2018 г., 17:05 +0700, Dougal Matthews , писал:
>
>
> > On 23 April 2018 at 20:58, Sean McGinnis  wrote:
> > > On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> > > > Hey Dougal,
> > > >
> > > > I think I had said May 2nd in my initial email asking about attendance. 
> > > > If
> > > > you can get an answer out of your team by then I would greatly 
> > > > appreciate
> > > > it! If you need more time please let me know by then (May 2nd) instead.
> >
> > Whoops - thanks for the correction.
> >
> > > >
> > > > -Kendall (diablo_rojo)
> > > >
> > >
> > > Do we need to collect this data for September already by the beginning of 
> > > May?
> > >
> > > Granted, the sooner we know details and can start planning, the better. 
> > > But as
> > > I started looking over the survey, it just seems really early to predict 
> > > where
> > > things will be 5 months from now. Especially considering we will have a
> > > different set of PTLs for many projects by then, and it is too early for 
> > > some
> > > of those hand off discussions to have started yet.
> >
> > Good question! I don't mean to ask people to commit 100% or not, I just 
> > want to know their intentions so I have more information when filling out 
> > the survey.
> >
> > >
> > > Sean
> > >
> > > __
> > > 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 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 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] [mistral] September PTG in Denver

2018-04-24 Thread Dougal Matthews
On 23 April 2018 at 20:58, Sean McGinnis  wrote:

> On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> > Hey Dougal,
> >
> > I think I had said May 2nd in my initial email asking about attendance.
> If
> > you can get an answer out of your team by then I would greatly appreciate
> > it! If you need more time please let me know by then (May 2nd) instead.
>

Whoops - thanks for the correction.


> >
> > -Kendall (diablo_rojo)
> >
>
> Do we need to collect this data for September already by the beginning of
> May?
>
> Granted, the sooner we know details and can start planning, the better.
> But as
> I started looking over the survey, it just seems really early to predict
> where
> things will be 5 months from now. Especially considering we will have a
> different set of PTLs for many projects by then, and it is too early for
> some
> of those hand off discussions to have started yet.
>

Good question! I don't mean to ask people to commit 100% or not, I just
want to know their intentions so I have more information when filling out
the survey.


>
> Sean
>
> __
> 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 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] ​ [mistral] timeout and retry

2018-04-23 Thread Vitalii Solodilov
Hi Renat, Can you explain me and Dougal how timeout policy should work with 
retry policy?

I guess there is bug right now.
The behaviour is something like this https://ibb.co/hhm0eH
Example: https://review.openstack.org/#/c/563759/ 
Logs: 
http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083
Even we will fix this bug and after task timeout we will not retry task. I 
don't understand which problem is decided by this timeout and retry.
Other problem. What about task retry? I mean using mistral api. The problem is 
that timeout delayed calls was not created.

IMHO the combination of these policies should work like this 
https://ibb.co/fe5tzH
It is not a timeout per action because when task retry it move to some complete 
state and then back to RUNNING state. And it will work fine with with-items 
policy.
The main advantage is executor and rabbitmq HA. I can specify small timeout if 
executor will die the task retried by timeout and create new action.
The second is predictable behaviour. When I specify timeout: 10 and 
retry.count: 5 I know that will be create maximum 5 action before SUCCESS state 
and every action will be executes no longer than 10 seconds.

-- 
Best regards,

Vitalii Solodilov


__
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] [mistral] September PTG in Denver

2018-04-23 Thread Sean McGinnis
On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> Hey Dougal,
> 
> I think I had said May 2nd in my initial email asking about attendance. If
> you can get an answer out of your team by then I would greatly appreciate
> it! If you need more time please let me know by then (May 2nd) instead.
> 
> -Kendall (diablo_rojo)
> 

Do we need to collect this data for September already by the beginning of May?

Granted, the sooner we know details and can start planning, the better. But as
I started looking over the survey, it just seems really early to predict where
things will be 5 months from now. Especially considering we will have a
different set of PTLs for many projects by then, and it is too early for some
of those hand off discussions to have started yet.

Sean

__
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] [mistral] September PTG in Denver

2018-04-23 Thread Kendall Nelson
Hey Dougal,

I think I had said May 2nd in my initial email asking about attendance. If
you can get an answer out of your team by then I would greatly appreciate
it! If you need more time please let me know by then (May 2nd) instead.

-Kendall (diablo_rojo)

On Fri, Apr 20, 2018 at 8:17 AM Dougal Matthews  wrote:

> Hey all,
>
> You may have seen the news already, but yesterday the next PTG location
> was announced [1]. It will be in Denver again.
>
> Can you let me know if you are planning to attend and go to Mistral
> sessions? I have been asked about numbers and need to reply by May 5th.
>
> Thanks,
> Dougal
>
>
> [1]:
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.html
> __
> 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 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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

2018-04-23 Thread Dougal Matthews
I spoke with Jaewook briefly in #openstack-mistral, for anyone interested
in following this work there is now a blueprint to track it.

https://blueprints.launchpad.net/mistral/+spec/mistral-vitrage-actions

Thanks all

On 23 April 2018 at 07:57, Jaewook Oh  wrote:

> Hello Renat,
>
> I'll join the IRC channel :)
>
> Thanks,
> Jaewook.
>
> 2018-04-23 15:45 GMT+09:00 Renat Akhmerov :
>
>> On 23 Apr 2018, 13:38 +0700, Jaewook Oh , wrote:
>>
>> Hello Mistral and Vitrage team,
>>
>> I've been testing vitrage with mistral workflow,
>> but it seems that there are no Vitrage actions in Mistral yet.
>>
>> I think Vitrage actions should be added to Mistral.
>> We can use the actions in mistral workflow to automate lots of repeated
>> tasks as it was originally intended.
>>
>> So, I'd like to add them to the Mistral Actions.
>> Can I do this work?
>>
>>
>> Hi, I see no reason why not. We’ll assist, if needed. I’d recommend to
>> join us at #openstack-mistral IRC channel for better communication.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> 
> *Jaewook Oh* (오재욱)
> IISTRC - Internet Infra System Technology Research Center
> 369 Sangdo-ro, Dongjak-gu,
> 06978, Seoul, Republic of Korea
>
> __
> 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 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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

2018-04-23 Thread Afek, Ifat (Nokia - IL/Kfar Sava)


From: Renat Akhmerov 
Date: Monday, 23 April 2018 at 9:45

On 23 Apr 2018, 13:38 +0700, Jaewook Oh , wrote:


Hello Mistral and Vitrage team,

I've been testing vitrage with mistral workflow,
but it seems that there are no Vitrage actions in Mistral yet.

I think Vitrage actions should be added to Mistral.
We can use the actions in mistral workflow to automate lots of repeated tasks 
as it was originally intended.

So, I'd like to add them to the Mistral Actions.
Can I do this work?

Hi, I see no reason why not. We’ll assist, if needed. I’d recommend to join us 
at #openstack-mistral IRC channel for better communication.

Thanks

Renat Akhmerov
@Nokia


Hi,

Sounds like a good idea, let us know if you need any help from Vitrage team.

Thanks,
Ifat

__
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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

2018-04-23 Thread Jaewook Oh
Hello Renat,

I'll join the IRC channel :)

Thanks,
Jaewook.

2018-04-23 15:45 GMT+09:00 Renat Akhmerov :

> On 23 Apr 2018, 13:38 +0700, Jaewook Oh , wrote:
>
> Hello Mistral and Vitrage team,
>
> I've been testing vitrage with mistral workflow,
> but it seems that there are no Vitrage actions in Mistral yet.
>
> I think Vitrage actions should be added to Mistral.
> We can use the actions in mistral workflow to automate lots of repeated
> tasks as it was originally intended.
>
> So, I'd like to add them to the Mistral Actions.
> Can I do this work?
>
>
> Hi, I see no reason why not. We’ll assist, if needed. I’d recommend to
> join us at #openstack-mistral IRC channel for better communication.
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> 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
>
>


-- 

*Jaewook Oh* (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea
__
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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

2018-04-23 Thread Renat Akhmerov
On 23 Apr 2018, 13:38 +0700, Jaewook Oh , wrote:

> Hello Mistral and Vitrage team,
>
> I've been testing vitrage with mistral workflow,
> but it seems that there are no Vitrage actions in Mistral yet.
>
> I think Vitrage actions should be added to Mistral.
> We can use the actions in mistral workflow to automate lots of repeated tasks 
> as it was originally intended.
>
> So, I'd like to add them to the Mistral Actions.
> Can I do this work?

Hi, I see no reason why not. We’ll assist, if needed. I’d recommend to join us 
at #openstack-mistral IRC channel for better communication.

Thanks

Renat Akhmerov
@Nokia
__
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] [mistral] [vitrage] Propose adding Vitrage's actions to Mistral Actions

2018-04-23 Thread Jaewook Oh
Hello Mistral and Vitrage team,

I've been testing vitrage with mistral workflow,
but it seems that there are no Vitrage actions in Mistral yet.

I think Vitrage actions should be added to Mistral.
We can use the actions in mistral workflow to automate lots of repeated
tasks as it was originally intended.

So, I'd like to add them to the Mistral Actions.
Can I do this work?

Best Regards,
Jaewook.
-- 

*Jaewook Oh* (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea
__
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] [mistral] September PTG in Denver

2018-04-20 Thread Dougal Matthews
Hey all,

You may have seen the news already, but yesterday the next PTG location was
announced [1]. It will be in Denver again.

Can you let me know if you are planning to attend and go to Mistral
sessions? I have been asked about numbers and need to reply by May 5th.

Thanks,
Dougal


[1]:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.html
__
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] [mistral] Rocky-1 Release and Rocky-2 Plans

2018-04-20 Thread Dougal Matthews
Hey all,

Mistral Rocky-1 [1] has been released and mistral-lib [2] and mistral
client [3] are on their way.

I have moved all of the open bugs and blueprints assigned to Rocky-1 to the
Rocky-2 cycle.

Can you please check the following:

- All the bugs and blueprints important to you are correctly assigned to
Rocky 2.
- That you still plan on working on bugs and blueprints that are assigned
to you.

In the coming weeks I plan on going through the bugs in Rocky-2 and trying
to determine what is realistic. At the moment I believe we have more than
we can finish. [4]

Thanks all,
Dougal

[1]: https://review.openstack.org/#/c/562734/
[2]: https://review.openstack.org/#/c/562742/
[3]: https://review.openstack.org/#/c/562743/
[4]: https://launchpad.net/mistral/+milestone/rocky-2
__
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] [Mistral]I think Mistral need K8S action

2018-04-16 Thread 홍선군
Thank you very much for your help.

 

I'm doing some tests now and I'll let you know if I start the K8S action.

 

Thanks again,

 

Xian Jun Hong

 

From: Dougal Matthews <dou...@redhat.com> 
Sent: Tuesday, April 17, 2018 6:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

 

 

On 16 April 2018 at 05:08, <xianjun...@dcn.ssu.ac.kr 
<mailto:xianjun...@dcn.ssu.ac.kr> > wrote:

Thanks for your reply.

 

I will refer to this Ansible action and developing  actions for K8S somewhere 
externally. 

 

Great. Do let us know when you start someting - I would be interested in giving 
feedback and testing or possibly helping out too.

 

 

Regards,

Xian Jun Hong

 

 

From: Dougal Matthews <dou...@redhat.com <mailto:dou...@redhat.com> > 
Sent: Saturday, April 14, 2018 1:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

 

 

On 13 April 2018 at 05:47, Renat Akhmerov <renat.akhme...@gmail.com 
<mailto:renat.akhme...@gmail.com> > wrote:

Hi, 

 

I completely agree with you that having such an action would be useful. 
However, I don’t think this kind of action should be provided by Mistral out of 
the box. Actions and triggers are integration pieces for Mistral and are 
natively external to Mistral code base. In other words, this action can be 
implemented anywhere and plugged into a concrete Mistral installation where 
needed.

 

As a home for this action I’d propose 'mistral-extra’ repo where we are 
planning to move OpenStack actions and some more.

Also, if you’d like to contribute you’re very welcome.

 

I would recommend developing actions for K8s somewhere externally, then when 
mistral-extra is ready we can move them over. This is the approach that I took 
for the Ansible actions[1] and they will likely be one of the first additions 
to mistral-extra.

[1]: https://github.com/d0ugal/mistral-ansible-actions


 

 


Thanks

Renat Akhmerov
@Nokia


On 13 Apr 2018, 09:18 +0700, < <mailto:xianjun...@dcn.ssu.ac.kr> 
xianjun...@dcn.ssu.ac.kr>, wrote:

Hello  Mistral team.

I'm doing some work on the K8S but I observed that there is only Docker's 
action in Mistral.

I would like to ask Mistral Team, why there is no K8S action in the mistral.

I think it would be useful in Mistral.

If you feel it's necessary, could I add K8S action to mistral?

 

Regards,

Xian Jun Hong

 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:  
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

__
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] [Mistral]I think Mistral need K8S action

2018-04-16 Thread Dougal Matthews
On 16 April 2018 at 05:08, 홍선군 <xianjun...@dcn.ssu.ac.kr> wrote:

> Thanks for your reply.
>
>
>
> I will refer to this Ansible action and developing  actions for K8S
> somewhere externally.
>

Great. Do let us know when you start someting - I would be interested in
giving feedback and testing or possibly helping out too.


>
>
> Regards,
>
> Xian Jun Hong
>
>
>
>
>
> *From:* Dougal Matthews <dou...@redhat.com>
> *Sent:* Saturday, April 14, 2018 1:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Mistral]I think Mistral need K8S action
>
>
>
>
>
>
>
> On 13 April 2018 at 05:47, Renat Akhmerov <renat.akhme...@gmail.com>
> wrote:
>
> Hi,
>
>
>
> I completely agree with you that having such an action would be useful.
> However, I don’t think this kind of action should be provided by Mistral
> out of the box. Actions and triggers are integration pieces for Mistral and
> are natively external to Mistral code base. In other words, this action can
> be implemented anywhere and plugged into a concrete Mistral installation
> where needed.
>
>
>
> As a home for this action I’d propose 'mistral-extra’ repo where we are
> planning to move OpenStack actions and some more.
>
> Also, if you’d like to contribute you’re very welcome.
>
>
>
> I would recommend developing actions for K8s somewhere externally, then
> when mistral-extra is ready we can move them over. This is the approach
> that I took for the Ansible actions[1] and they will likely be one of the
> first additions to mistral-extra.
>
> [1]: https://github.com/d0ugal/mistral-ansible-actions
>
>
>
>
>
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> On 13 Apr 2018, 09:18 +0700, <xianjun...@dcn.ssu.ac.kr>, wrote:
>
> Hello  Mistral team.
>
> I'm doing some work on the K8S but I observed that there is only Docker's
> action in Mistral.
>
> I would like to ask Mistral Team, why there is no K8S action in the
> mistral.
>
> I think it would be useful in Mistral.
>
> If you feel it's necessary, could I add K8S action to mistral?
>
>
>
> Regards,
>
> Xian Jun Hong
>
>
>
> __
> 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 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 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 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] [Mistral]I think Mistral need K8S action

2018-04-15 Thread 홍선군
Thanks for your reply.

 

I will refer to this Ansible action and developing  actions for K8S somewhere 
externally. 

 

Regards,

Xian Jun Hong

 

 

From: Dougal Matthews <dou...@redhat.com> 
Sent: Saturday, April 14, 2018 1:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

 

 

On 13 April 2018 at 05:47, Renat Akhmerov <renat.akhme...@gmail.com 
<mailto:renat.akhme...@gmail.com> > wrote:

Hi, 

 

I completely agree with you that having such an action would be useful. 
However, I don’t think this kind of action should be provided by Mistral out of 
the box. Actions and triggers are integration pieces for Mistral and are 
natively external to Mistral code base. In other words, this action can be 
implemented anywhere and plugged into a concrete Mistral installation where 
needed.

 

As a home for this action I’d propose 'mistral-extra’ repo where we are 
planning to move OpenStack actions and some more.

Also, if you’d like to contribute you’re very welcome.

 

I would recommend developing actions for K8s somewhere externally, then when 
mistral-extra is ready we can move them over. This is the approach that I took 
for the Ansible actions[1] and they will likely be one of the first additions 
to mistral-extra.

[1]: https://github.com/d0ugal/mistral-ansible-actions


 

 


Thanks

Renat Akhmerov
@Nokia


On 13 Apr 2018, 09:18 +0700, <xianjun...@dcn.ssu.ac.kr 
<mailto:xianjun...@dcn.ssu.ac.kr> >, wrote:

Hello  Mistral team.

I'm doing some work on the K8S but I observed that there is only Docker's 
action in Mistral.

I would like to ask Mistral Team, why there is no K8S action in the mistral.

I think it would be useful in Mistral.

If you feel it's necessary, could I add K8S action to mistral?

 

Regards,

Xian Jun Hong

 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

__
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] [Mistral]I think Mistral need K8S action

2018-04-15 Thread Renat Akhmerov

On 13 Apr 2018, 23:01 +0700, Dougal Matthews , wrote:
> > I would recommend developing actions for K8s somewhere externally, then 
> > when mistral-extra is ready we can move them over. This is the approach 
> > that I took for the Ansible actions[1] and they will likely be one of the 
> > first additions to mistral-extra.
> >
> > [1]: https://github.com/d0ugal/mistral-ansible-actions
> >


Yes, I agree.

Renat Akhmerov
@Nokia
__
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] [Mistral]I think Mistral need K8S action

2018-04-13 Thread Dougal Matthews
On 13 April 2018 at 05:47, Renat Akhmerov  wrote:

> Hi,
>
> I completely agree with you that having such an action would be useful.
> However, I don’t think this kind of action should be provided by Mistral
> out of the box. Actions and triggers are integration pieces for Mistral and
> are natively external to Mistral code base. In other words, this action can
> be implemented anywhere and plugged into a concrete Mistral installation
> where needed.
>
> As a home for this action I’d propose 'mistral-extra’ repo where we are
> planning to move OpenStack actions and some more.
> Also, if you’d like to contribute you’re very welcome.
>

I would recommend developing actions for K8s somewhere externally, then
when mistral-extra is ready we can move them over. This is the approach
that I took for the Ansible actions[1] and they will likely be one of the
first additions to mistral-extra.

[1]: https://github.com/d0ugal/mistral-ansible-actions



>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> On 13 Apr 2018, 09:18 +0700, 홍선군 , wrote:
>
> Hello  Mistral team.
>
> I'm doing some work on the K8S but I observed that there is only Docker's
> action in Mistral.
>
> I would like to ask Mistral Team, why there is no K8S action in the
> mistral.
>
> I think it would be useful in Mistral.
>
> If you feel it's necessary, could I add K8S action to mistral?
>
>
>
> Regards,
>
> Xian Jun Hong
>
>
> __
> 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 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 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] [Mistral]I think Mistral need K8S action

2018-04-12 Thread 홍선군
Thanks for your reply.

 

I will continue to pay attention.

 

Regards,

Xian Jun Hong

 

From: Renat Akhmerov <renat.akhme...@gmail.com> 
Sent: Friday, April 13, 2018 1:48 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral]I think Mistral need K8S action

 

Hi, 

 

I completely agree with you that having such an action would be useful. 
However, I don’t think this kind of action should be provided by Mistral out of 
the box. Actions and triggers are integration pieces for Mistral and are 
natively external to Mistral code base. In other words, this action can be 
implemented anywhere and plugged into a concrete Mistral installation where 
needed.

 

As a home for this action I’d propose 'mistral-extra’ repo where we are 
planning to move OpenStack actions and some more.   

  

Also, if you’d like to contribute you’re very welcome.

 


Thanks

Renat Akhmerov
@Nokia


On 13 Apr 2018, 09:18 +0700, <xianjun...@dcn.ssu.ac.kr 
<mailto:xianjun...@dcn.ssu.ac.kr> >, wrote:



Hello  Mistral team.

I'm doing some work on the K8S but I observed that there is only Docker's 
action in Mistral.

I would like to ask Mistral Team, why there is no K8S action in the mistral.

I think it would be useful in Mistral.

If you feel it's necessary, could I add K8S action to mistral?

 

Regards,

Xian Jun Hong

 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] [Mistral]I think Mistral need K8S action

2018-04-12 Thread Renat Akhmerov
Hi,

I completely agree with you that having such an action would be useful. 
However, I don’t think this kind of action should be provided by Mistral out of 
the box. Actions and triggers are integration pieces for Mistral and are 
natively external to Mistral code base. In other words, this action can be 
implemented anywhere and plugged into a concrete Mistral installation where 
needed.

As a home for this action I’d propose 'mistral-extra’ repo where we are 
planning to move OpenStack actions and some more.
Also, if you’d like to contribute you’re very welcome.


Thanks

Renat Akhmerov
@Nokia

On 13 Apr 2018, 09:18 +0700, 홍선군 , wrote:
> Hello  Mistral team.
> I'm doing some work on the K8S but I observed that there is only Docker's 
> action in Mistral.
> I would like to ask Mistral Team, why there is no K8S action in the mistral.
> I think it would be useful in Mistral.
> If you feel it's necessary, could I add K8S action to mistral?
>
> Regards,
> Xian Jun Hong
>
> __
> 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 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] [Mistral]I think Mistral need K8S action

2018-04-12 Thread 홍선군
Hello  Mistral team.

I'm doing some work on the K8S but I observed that there is only Docker's
action in Mistral.

I would like to ask Mistral Team, why there is no K8S action in the mistral.

I think it would be useful in Mistral.

If you feel it's necessary, could I add K8S action to mistral?

 

Regards,

Xian Jun Hong

 

__
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] [mistral] Bug Triage on Friday

2018-04-04 Thread Dougal Matthews
Hey all,

During the office hour on Friday, and maybe some time after it, I am going
to do some Mistral bug triage, planning and general tidying up on launchpad
and gerrit. If you are able and want to join, please do!

The slot is 8AM UTC - 9AM UTC. I'll be in #openstack-mistral

I hope to try and do these regularly at office hours, giving me time to do
some triage unless something else comes up to discuss.

For convenience I have created a calendar with the Mistral office hours, it
is just on my personal Google Calendar until I find a better place for it.
If you would find it useful, you can add it here:

iCal link:
https://calendar.google.com/calendar/ical/dougalmatthews.com_qmk1aiaao3b5ci30dp7t7e17es%40group.calendar.google.com/public/basic.ics
Google Link:
https://calendar.google.com/calendar?cid=ZG91Z2FsbWF0dGhld3MuY29tX3FtazFhaWFhbzNiNWNpMzBkcDd0N2UxN2VzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20
__
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] [mistral][tempest][congress] import or retain mistral tempest service client

2018-03-28 Thread Eric K
Thank you, Dougal and Ghanshyam for the responses!

What I can gather is: service client registration > import service client
> retaining copy.
So the best thing for Congress to do now is to import the service client.

On 3/17/18, 9:00 PM, "Ghanshyam Mann"  wrote:

>Hi All,
>
>Sorry for late response, i kept this mail unread but forgot to
>respond. reply inline.
>
>On Fri, Mar 16, 2018 at 8:08 PM, Dougal Matthews 
>wrote:
>>
>>
>> On 13 March 2018 at 18:51, Eric K  wrote:
>>>
>>> Hi Mistral folks and others,
>>>
>>> I'm working on Congress tempest tests [1] for integration with
>>>Mistral. In
>>> the tests, we use a Mistral service client to call Mistral APIs and
>>> compare results against those obtained by Mistral driver for Congress.
>>>
>>> Regarding the service client, Congress can either import directly from
>>> Mistral tempest plugin [2] or maintain its own copy within Congress
>>> tempest plugin.
>
>Maintaining own copy will leads to lot of issues and lot of duplicate
>code among many plugins.
>
>>I'm not sure whether Mistral team expects the service
>>> client to be internal use only, so I hope to hear folks' thoughts on
>>>which
>>> approach is preferred. Thanks very much!
>>
>>
>> I don't have a strong opinion here. I am happy for you to use the
>>Mistral
>> service client, but it will be hard to guarantee stability. It has been
>> stable (since it hasn't changed), but we have a temptest refactor
>>planned
>> (once we move the final tempest tests from mistraclient to
>> mistral-tempest-plugin). So there is a fair chance we will break the
>>API at
>> that point, however, I don't know when it will happen, as nobody is
>> currently working on it.
>
>From QA team, service clients are the main interface which can be used
>across tempest plugins. For example, congress need many other service
>clients from other Tempest Plugins liek Mistral. Tempest also declare
>all their in-tree service clients as library interface and we maintain
>them as per backward compatibility [3]. This way we make these service
>clients usable outside of Tempest also to avoid duplicate
>code/interface.
>
>For Service Clients defined in Tempest plugins (like Mistral service
>clients),  we suggest (strongly) the same process which is to declare
>plugins's service clients as stable interface which gives 2 advantage:
>1. By this you make sure that you are not allowing to change the API
>calling interface(service clietns) which indirectly means you are not
>allowing to change the APIs. Makes your tempest plugin testing more
>reliable.
>
>2. Your service clients can be used in other Tempest plugins to avoid
>duplicate code/interface. If any other plugins use you service clients
>means, they also test your project so it is good to help them by
>providing the required interface as stable.
>
>Initial idea of owning the service clients in their respective plugins
>was to share them among plugins for integrated testing of more then
>one openstack service.
>
>Now on usage of service clients, Tempest provide a better way to do so
>than importing them directly [4]. You can see the example for Manila's
>tempest plugin [5]. This gives an advantage of discovering your
>registered service clients in other Tempest plugins automatically.
>They do not need to import other plugins service clients. QA is hoping
>that each tempest plugins will move to new service client registration
>process.
>
>Overall, we recommend to have service clients as stable interface so
>that other plugins can use them and test your projects in more
>integrated way.
>
>>
>> I have cc'ed Chandan - hopefully he can provide some input. He has
>>advised
>> me and the Mistral team regarding tempest before.
>>
>>>
>>>
>>> Eric
>>>
>>> [1] https://review.openstack.org/#/c/538336/
>>> [2]
>>>
>>> 
>>>https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_
>>>tem
>>> pest_tests/services/v2/mistral_client.py
>>>
>>>
>
>..3 
>http://git.openstack.org/cgit/openstack/tempest/tree/tempest/lib/services
>..4 
>https://docs.openstack.org/tempest/latest/plugin.html#get_service_clients(
>)
>..5 https://review.openstack.org/#/c/334596/34
>
>-gmann
>
>>>
>>> 
>>>
>>>__
>>> 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 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 Development Mailing List (not for usage questions)
>Unsubscribe: 

[openstack-dev] [mistral] [ptl] PTL vacation from March 26 - March 30

2018-03-23 Thread Dougal Matthews
I'll be out for the dates in the subject, so all of next week.

Renat Akhmerov (rakhmerov on IRC) will be standing in for anything that
comes up.

Cheers,
Dougal
__
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] [mistral] Re: Mistral docker job

2018-03-20 Thread Vitalii Solodilov
Can we push a Mistral image to some registry?I think it is more convenient than zip for user. And we can add image to cache-from section. https://docs.docker.com/compose/compose-file/#cache_from  About mysql, sorry, i don't have experience. I added the latest version of mysql. As I know that It's RC. Maybe we change to 5.7? 20.03.2018, 17:28, "Kovi, Andras 1. (Nokia - HU/Budapest)" :Yeah, sorry. In the current code docker-compose is set up to build the mistral image. It is not going to use anything that's uploaded and I don't know how one can instruct docker-compose to pass the --cache-from parameter to the docker build if the uploaded image was imported. If someone decides to try the docker build, they should already be prepared to build stuff locally. Building the image does not take a long time (given v8eval is not installed) and they can use the current code at any time. This way we can prevent ourselves from comments regarding versions or anything. I just don't find it particularly useful. If there is real demand, let's keep it.  TL,DR;On the other hand, I've just stumbled upon an issue that mysql does not bind to the IPv4 address, only IPv6. This used to work and I don't know what changed.  mysql_1   | 2018-03-20T14:00:05.068149Z 0 [Note] Server hostname (bind-address): '*'; port: 3306mysql_1   | 2018-03-20T14:00:05.068213Z 0 [Note] IPv6 is available.mysql_1   | 2018-03-20T14:00:05.068233Z 0 [Note]   - '::' resolves to '::';mysql_1   | 2018-03-20T14:00:05.068296Z 0 [Note] Server socket created on IP: '::'. root@2e71797b8470 (this is mysql):/# ss -lntState  Recv-Q Send-Q    Local Address:Port  Peer Address:PortLISTEN 0  128  127.0.0.11:40374    *:*     LISTEN 0  128  :::3306    :::*      Mistral is not able to connect as it resolves the V4 address.  Cheers,A Feladó: Brad P. Crochet Elküldve: 2018. március 20., kedd 12:34Címzett: Kovi, Andras 1. (Nokia - HU/Budapest)Másolatot kap: Vitalii Solodilov; Akhmerov, Renat (Nokia - RU); dou...@redhat.comTárgy: Re: Mistral docker job I'm curious why you keep wanting to just delete the job rather than fixing it? It's not a gate job, and does not affect landing patches, but I do believe there are users that find it useful. On Tue, Mar 20, 2018 at 2:12 AM Kovi, Andras 1. (Nokia - HU/Budapest)  wrote:Hi Vitalii, thanks for the docker update. It's really good improvement from the previous version. But now the mistral docker job is failing.  http://zuul.openstack.org/builds.html?job_name=mistral-docker-buildimageI would be for deleting this job completely but could you please try to fix it first in some way? Thanks,Andras--Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDSPrincipal Software Engineer(c)  704.236.9385   -- Best regards, Vitalii Solodilov __
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] [mistral][tempest][congress] import or retain mistral tempest service client

2018-03-17 Thread Ghanshyam Mann
Hi All,

Sorry for late response, i kept this mail unread but forgot to
respond. reply inline.

On Fri, Mar 16, 2018 at 8:08 PM, Dougal Matthews  wrote:
>
>
> On 13 March 2018 at 18:51, Eric K  wrote:
>>
>> Hi Mistral folks and others,
>>
>> I'm working on Congress tempest tests [1] for integration with Mistral. In
>> the tests, we use a Mistral service client to call Mistral APIs and
>> compare results against those obtained by Mistral driver for Congress.
>>
>> Regarding the service client, Congress can either import directly from
>> Mistral tempest plugin [2] or maintain its own copy within Congress
>> tempest plugin.

Maintaining own copy will leads to lot of issues and lot of duplicate
code among many plugins.

>I'm not sure whether Mistral team expects the service
>> client to be internal use only, so I hope to hear folks' thoughts on which
>> approach is preferred. Thanks very much!
>
>
> I don't have a strong opinion here. I am happy for you to use the Mistral
> service client, but it will be hard to guarantee stability. It has been
> stable (since it hasn't changed), but we have a temptest refactor planned
> (once we move the final tempest tests from mistraclient to
> mistral-tempest-plugin). So there is a fair chance we will break the API at
> that point, however, I don't know when it will happen, as nobody is
> currently working on it.

From QA team, service clients are the main interface which can be used
across tempest plugins. For example, congress need many other service
clients from other Tempest Plugins liek Mistral. Tempest also declare
all their in-tree service clients as library interface and we maintain
them as per backward compatibility [3]. This way we make these service
clients usable outside of Tempest also to avoid duplicate
code/interface.

For Service Clients defined in Tempest plugins (like Mistral service
clients),  we suggest (strongly) the same process which is to declare
plugins's service clients as stable interface which gives 2 advantage:
1. By this you make sure that you are not allowing to change the API
calling interface(service clietns) which indirectly means you are not
allowing to change the APIs. Makes your tempest plugin testing more
reliable.

2. Your service clients can be used in other Tempest plugins to avoid
duplicate code/interface. If any other plugins use you service clients
means, they also test your project so it is good to help them by
providing the required interface as stable.

Initial idea of owning the service clients in their respective plugins
was to share them among plugins for integrated testing of more then
one openstack service.

Now on usage of service clients, Tempest provide a better way to do so
than importing them directly [4]. You can see the example for Manila's
tempest plugin [5]. This gives an advantage of discovering your
registered service clients in other Tempest plugins automatically.
They do not need to import other plugins service clients. QA is hoping
that each tempest plugins will move to new service client registration
process.

Overall, we recommend to have service clients as stable interface so
that other plugins can use them and test your projects in more
integrated way.

>
> I have cc'ed Chandan - hopefully he can provide some input. He has advised
> me and the Mistral team regarding tempest before.
>
>>
>>
>> Eric
>>
>> [1] https://review.openstack.org/#/c/538336/
>> [2]
>>
>> https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_tem
>> pest_tests/services/v2/mistral_client.py
>>
>>

..3 http://git.openstack.org/cgit/openstack/tempest/tree/tempest/lib/services
..4 https://docs.openstack.org/tempest/latest/plugin.html#get_service_clients()
..5 https://review.openstack.org/#/c/334596/34

-gmann

>>
>> __
>> 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 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 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] [mistral][tempest][congress] import or retain mistral tempest service client

2018-03-16 Thread Dougal Matthews
On 13 March 2018 at 18:51, Eric K  wrote:

> Hi Mistral folks and others,
>
> I'm working on Congress tempest tests [1] for integration with Mistral. In
> the tests, we use a Mistral service client to call Mistral APIs and
> compare results against those obtained by Mistral driver for Congress.
>
> Regarding the service client, Congress can either import directly from
> Mistral tempest plugin [2] or maintain its own copy within Congress
> tempest plugin. I'm not sure whether Mistral team expects the service
> client to be internal use only, so I hope to hear folks' thoughts on which
> approach is preferred. Thanks very much!
>

I don't have a strong opinion here. I am happy for you to use the Mistral
service client, but it will be hard to guarantee stability. It has been
stable (since it hasn't changed), but we have a temptest refactor planned
(once we move the final tempest tests from mistraclient to
mistral-tempest-plugin). So there is a fair chance we will break the API at
that point, however, I don't know when it will happen, as nobody is
currently working on it.

I have cc'ed Chandan - hopefully he can provide some input. He has advised
me and the Mistral team regarding tempest before.


>
> Eric
>
> [1] https://review.openstack.org/#/c/538336/
> [2]
> https://github.com/openstack/mistral-tempest-plugin/blob/
> master/mistral_tem
> pest_tests/services/v2/mistral_client.py
>
>
>
> __
> 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 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] [mistral][tempest][congress] import or retain mistral tempest service client

2018-03-13 Thread Eric K
Hi Mistral folks and others,

I'm working on Congress tempest tests [1] for integration with Mistral. In
the tests, we use a Mistral service client to call Mistral APIs and
compare results against those obtained by Mistral driver for Congress.

Regarding the service client, Congress can either import directly from
Mistral tempest plugin [2] or maintain its own copy within Congress
tempest plugin. I'm not sure whether Mistral team expects the service
client to be internal use only, so I hope to hear folks' thoughts on which
approach is preferred. Thanks very much!

Eric

[1] https://review.openstack.org/#/c/538336/
[2] 
https://github.com/openstack/mistral-tempest-plugin/blob/master/mistral_tem
pest_tests/services/v2/mistral_client.py



__
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] [mistral] PTG Summary

2018-03-11 Thread Renat Akhmerov

On 7 Mar 2018, 16:29 +0700, Dougal Matthews , wrote:
> Hey Mistralites (maybe?),
>
> I have been through the etherpad from the PTG and attempted to expand on the 
> topics with details that I remember. If I have missed anything or you have 
> any questions, please get in touch. I want to update it while the memory is 
> as fresh as possible.
>
> For each main topic I have added a "champion" and a "goal". These are not all 
> complete yet and can be adjusted. I did add names next to champion for people 
> that discussed that topic at the PTG. The goal should summarise what we need 
> to do.
>
> Note: "Champion" does not mean you need to do all the work - just you are 
> leading that effort and helping rally people around the issue. Essentially it 
> is a collaboration role, but you can still lead the implementation if that 
> makes sense. For example, I put myself as the Documentation champion. I do 
> not plan on writing all the documentation, rather I want to setup better 
> foundations and a better process for writing documentation. This will likely 
> be a team effort I need to coordinate.
>
> Etherpad:
> https://etherpad.openstack.org/p/mistral-ptg-rocky
>

Thanks Dougal, looks nice )

> It was unfortunate that the "Beast from the East" (the weather, not Renat!) 
> stopped things a bit early on Thursday.

Haha :) I probably wouldn’t be even offended if you meant me ;)

Renat Akhmerov
@Nokia

__
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] [mistral] PTG Summary

2018-03-07 Thread Dougal Matthews
On 7 March 2018 at 09:28, Dougal Matthews  wrote:

> Hey Mistralites (maybe?),
>
> I have been through the etherpad from the PTG and attempted to expand on
> the topics with details that I remember. If I have missed anything or you
> have any questions, please get in touch. I want to update it while the
> memory is as fresh as possible.
>
> For each main topic I have added a "champion" and a "goal". These are not
> all complete yet and can be adjusted. I did add names next to champion for
> people that discussed that topic at the PTG. The goal should summarise what
> we need to do.
>
> Note: "Champion" does not mean you need to do all the work - just you are
> leading that effort and helping rally people around the issue. Essentially
> it is a collaboration role, but you can still lead the implementation if
> that makes sense. For example, I put myself as the Documentation champion.
> I do not plan on writing all the documentation, rather I want to setup
> better foundations and a better process for writing documentation. This
> will likely be a team effort I need to coordinate.
>
> Etherpad:
> https://etherpad.openstack.org/p/mistral-ptg-rocky
>

I forgot to add, if you were unable to attend the PTG or have anything else
you want to add/discuss then please let us know.


>
>
> Thanks everyone for coming, I think it was a useful week. It was
> unfortunate that the "Beast from the East" (the weather, not Renat!)
> stopped things a bit early on Thursday. I hope all your homeward travels
> worked out in the end.
>
> Cheers,
> Dougal
>
__
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] [mistral] PTG Summary

2018-03-07 Thread Dougal Matthews
Hey Mistralites (maybe?),

I have been through the etherpad from the PTG and attempted to expand on
the topics with details that I remember. If I have missed anything or you
have any questions, please get in touch. I want to update it while the
memory is as fresh as possible.

For each main topic I have added a "champion" and a "goal". These are not
all complete yet and can be adjusted. I did add names next to champion for
people that discussed that topic at the PTG. The goal should summarise what
we need to do.

Note: "Champion" does not mean you need to do all the work - just you are
leading that effort and helping rally people around the issue. Essentially
it is a collaboration role, but you can still lead the implementation if
that makes sense. For example, I put myself as the Documentation champion.
I do not plan on writing all the documentation, rather I want to setup
better foundations and a better process for writing documentation. This
will likely be a team effort I need to coordinate.

Etherpad:
https://etherpad.openstack.org/p/mistral-ptg-rocky

Thanks everyone for coming, I think it was a useful week. It was
unfortunate that the "Beast from the East" (the weather, not Renat!)
stopped things a bit early on Thursday. I hope all your homeward travels
worked out in the end.

Cheers,
Dougal
__
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] [mistral] Retiring the Mistral Wiki pages

2018-03-06 Thread Renat Akhmerov
IMO, these sections should be moved to the official docs in some form:

• FAQ - https://wiki.openstack.org/w/index.php?title=Mistral=99745#FAQ
• Actions design - 
https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign
• Description of use cases:

• https://wiki.openstack.org/wiki/Mistral/Long_Running_Business_Process
• https://wiki.openstack.org/wiki/Mistral/Cloud_Cron_details



All of these pages are outdated to some degree (terms etc.) and need to be 
refreshed but I think they contain a lot of interesting info that could help 
people understand Mistral better.

There's also a page (very much outdated!) containing info about the Mistral 
team: https://wiki.openstack.org/wiki/Mistral/Team

Of course, it can't be reused but I think it would be nice to have something 
link in the official doc, may be pointing directly to a stackalytics relevant 
info.


Thanks

Renat Akhmerov
@Nokia

On 7 Mar 2018, 12:33 +0700, Renat Akhmerov , wrote:
> Thanks Dougal, I’ll also look at it to see what’s still relevant.
>
>
> Renat Akhmerov
> @Nokia
>
> On 6 Mar 2018, 21:24 +0700, Dougal Matthews , wrote:
> > Hey folks,
> >
> > Mistral has several Wiki pages that rank highly in Google searches. 
> > However, most of them have not been updated in months (or years in many 
> > cases). I am therefore starting to remove these and direct people to the 
> > Mistral documentation. Where possible I will link them to the relevant 
> > documentation pages.
> >
> > I have taken the plunge and removed the main wiki [0] page. The old content 
> > is still accessible [1], just click on "Page" at the top left and then go 
> > to history.
> >
> > Over the next week or so I am going to read through the old wiki pages and 
> > see if there is any information that is still relevant and move it to the 
> > Mistral documentation. If you are aware of anything that is in the wiki, 
> > but not in the docs (and should be) then please submit a patch or open a 
> > bug.
> >
> > After we consolidate all of the information into the Mistral docs I hope to 
> > coordinate an effort to improve the documentation.
> >
> > Cheers,
> > Dougal
> >
> > [0]: https://wiki.openstack.org/wiki/Mistral
> > [1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
> > __
> > 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 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] [mistral] Retiring the Mistral Wiki pages

2018-03-06 Thread Renat Akhmerov
Thanks Dougal, I’ll also look at it to see what’s still relevant.


Renat Akhmerov
@Nokia

On 6 Mar 2018, 21:24 +0700, Dougal Matthews , wrote:
> Hey folks,
>
> Mistral has several Wiki pages that rank highly in Google searches. However, 
> most of them have not been updated in months (or years in many cases). I am 
> therefore starting to remove these and direct people to the Mistral 
> documentation. Where possible I will link them to the relevant documentation 
> pages.
>
> I have taken the plunge and removed the main wiki [0] page. The old content 
> is still accessible [1], just click on "Page" at the top left and then go to 
> history.
>
> Over the next week or so I am going to read through the old wiki pages and 
> see if there is any information that is still relevant and move it to the 
> Mistral documentation. If you are aware of anything that is in the wiki, but 
> not in the docs (and should be) then please submit a patch or open a bug.
>
> After we consolidate all of the information into the Mistral docs I hope to 
> coordinate an effort to improve the documentation.
>
> Cheers,
> Dougal
>
> [0]: https://wiki.openstack.org/wiki/Mistral
> [1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
> __
> 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 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] [mistral] What's new in latest CloudFlow?

2018-03-06 Thread Dougal Matthews
I checked with one of the tripleo-ui developers. They are using redux
thunks to execute the API calls and they pointed me to this part of the
code.

https://github.com/openstack/tripleo-ui/blob/master/src/js/services/KeystoneApiService.js

Hopefully that is useful - it looks like the custom code required is fairly
small.

Cheers,
Dougal


On 1 March 2018 at 16:37, Shaanan, Guy (Nokia - IL/Kfar Sava) <
guy.shaa...@nokia.com> wrote:

> Hi Dougal,
>
> Yes, it probably does help.
>
> I haven’t found any proper Keystone JavaScript library (if anyone knows
> about one let me know).
>
>
>
> *From:* Dougal Matthews [mailto:dou...@redhat.com]
> *Sent:* Thursday, March 1, 2018 17:43
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [mistral] What's new in latest CloudFlow?
>
>
>
> Hey Guy,
>
> Thanks for sharing this update. I need to find time to try it out. The
> biggest issue for me is the lack of keystone support.
>
>
>
> I wonder if any of the code in tripleo-ui could be used to help with
> KeyStone support. It is a front-end JavaScript GUI.
> https://github.com/openstack/tripleo-ui
>
>
>
> Cheers,
>
> Dougal
>
>
>
> On 26 February 2018 at 09:10, Shaanan, Guy (Nokia - IL/Kfar Sava) <
> guy.shaa...@nokia.com> wrote:
>
> CloudFlow [1] is an open-source web-based GUI tool that helps visualize
> and debug Mistral workflows.
>
>
>
> With the latest release [2] of CloudFlow (v0.5.0) you can:
>
> * Visualize the flow of workflow executions
>
> * Identify the execution path of a single task in huge workflows
>
> * Search Mistral by any entity ID
>
> * Identify long-running tasks at a glance
>
> * Easily distinguish between simple task (an action) and a sub workflow
> execution
>
> * Follow tasks with a `retry` and/or `with-items`
>
> * 1-click to copy task's input/output/publish/params values
>
> * See complete workflow definition and per task definition YAML
>
> * And more...
>
>
>
> CloudFlow is easy to install and run (and even easier to upgrade), and we
> appreciate any feedback and contribution.
>
>
>
> CloudFlow currently supports unauthenticated Mistral or authentication
> with KeyCloak (openid-connect implementation). A support for Keystone will
> be added in the near future.
>
>
>
> You can try CloudFlow now on your Mistral Pike/Queens, or try it on the
> online demo [3].
>
>
>
> [1] https://github.com/nokia/CloudFlow
>
> [2] https://github.com/nokia/CloudFlow/releases/latest
>
> [3] http://yaqluator.com:8000
>
>
>
>
>
> Thanks,
>
> *-*
>
> *Guy Shaanan*
>
> Full Stack Web Developer, CI & Internal Tools
>
> CloudBand @ Nokia Software, Nokia, ISRAEL
>
> guy.shaa...@nokia.com
>
>
>
>
> __
> 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 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 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] [mistral] Retiring the Mistral Wiki pages

2018-03-06 Thread Dougal Matthews
Hey folks,

Mistral has several Wiki pages that rank highly in Google searches.
However, most of them have not been updated in months (or years in many
cases). I am therefore starting to remove these and direct people to the
Mistral documentation. Where possible I will link them to the relevant
documentation pages.

I have taken the plunge and removed the main wiki [0] page. The old content
is still accessible [1], just click on "Page" at the top left and then go
to history.

Over the next week or so I am going to read through the old wiki pages and
see if there is any information that is still relevant and move it to the
Mistral documentation. If you are aware of anything that is in the wiki,
but not in the docs (and should be) then please submit a patch or open a
bug.

After we consolidate all of the information into the Mistral docs I hope to
coordinate an effort to improve the documentation.

Cheers,
Dougal

[0]: https://wiki.openstack.org/wiki/Mistral
[1]: https://wiki.openstack.org/w/index.php?title=Mistral=152120
__
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] [mistral] What's new in latest CloudFlow?

2018-03-01 Thread Shaanan, Guy (Nokia - IL/Kfar Sava)
Hi Dougal,
Yes, it probably does help.
I haven’t found any proper Keystone JavaScript library (if anyone knows about 
one let me know).

From: Dougal Matthews [mailto:dou...@redhat.com]
Sent: Thursday, March 1, 2018 17:43
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [mistral] What's new in latest CloudFlow?

Hey Guy,
Thanks for sharing this update. I need to find time to try it out. The biggest 
issue for me is the lack of keystone support.

I wonder if any of the code in tripleo-ui could be used to help with KeyStone 
support. It is a front-end JavaScript GUI. 
https://github.com/openstack/tripleo-ui

Cheers,
Dougal

On 26 February 2018 at 09:10, Shaanan, Guy (Nokia - IL/Kfar Sava) 
<guy.shaa...@nokia.com<mailto:guy.shaa...@nokia.com>> wrote:
CloudFlow [1] is an open-source web-based GUI tool that helps visualize and 
debug Mistral workflows.

With the latest release [2] of CloudFlow (v0.5.0) you can:
* Visualize the flow of workflow executions
* Identify the execution path of a single task in huge workflows
* Search Mistral by any entity ID
* Identify long-running tasks at a glance
* Easily distinguish between simple task (an action) and a sub workflow 
execution
* Follow tasks with a `retry` and/or `with-items`
* 1-click to copy task's input/output/publish/params values
* See complete workflow definition and per task definition YAML
* And more...

CloudFlow is easy to install and run (and even easier to upgrade), and we 
appreciate any feedback and contribution.

CloudFlow currently supports unauthenticated Mistral or authentication with 
KeyCloak (openid-connect implementation). A support for Keystone will be added 
in the near future.

You can try CloudFlow now on your Mistral Pike/Queens, or try it on the online 
demo [3].

[1] https://github.com/nokia/CloudFlow
[2] https://github.com/nokia/CloudFlow/releases/latest
[3] http://yaqluator.com:8000


Thanks,
-
Guy Shaanan
Full Stack Web Developer, CI & Internal Tools
CloudBand @ Nokia Software, Nokia, ISRAEL
guy.shaa...@nokia.com<mailto:guy.shaa...@nokia.com>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] [mistral] What's new in latest CloudFlow?

2018-03-01 Thread Dougal Matthews
Hey Guy,

Thanks for sharing this update. I need to find time to try it out. The
biggest issue for me is the lack of keystone support.

I wonder if any of the code in tripleo-ui could be used to help with
KeyStone support. It is a front-end JavaScript GUI.
https://github.com/openstack/tripleo-ui

Cheers,
Dougal


On 26 February 2018 at 09:10, Shaanan, Guy (Nokia - IL/Kfar Sava) <
guy.shaa...@nokia.com> wrote:

> CloudFlow [1] is an open-source web-based GUI tool that helps visualize
> and debug Mistral workflows.
>
>
>
> With the latest release [2] of CloudFlow (v0.5.0) you can:
>
> * Visualize the flow of workflow executions
>
> * Identify the execution path of a single task in huge workflows
>
> * Search Mistral by any entity ID
>
> * Identify long-running tasks at a glance
>
> * Easily distinguish between simple task (an action) and a sub workflow
> execution
>
> * Follow tasks with a `retry` and/or `with-items`
>
> * 1-click to copy task's input/output/publish/params values
>
> * See complete workflow definition and per task definition YAML
>
> * And more...
>
>
>
> CloudFlow is easy to install and run (and even easier to upgrade), and we
> appreciate any feedback and contribution.
>
>
>
> CloudFlow currently supports unauthenticated Mistral or authentication
> with KeyCloak (openid-connect implementation). A support for Keystone will
> be added in the near future.
>
>
>
> You can try CloudFlow now on your Mistral Pike/Queens, or try it on the
> online demo [3].
>
>
>
> [1] https://github.com/nokia/CloudFlow
>
> [2] https://github.com/nokia/CloudFlow/releases/latest
>
> [3] http://yaqluator.com:8000
>
>
>
>
>
> Thanks,
>
> *-*
>
> *Guy Shaanan*
>
> Full Stack Web Developer, CI & Internal Tools
>
> CloudBand @ Nokia Software, Nokia, ISRAEL
>
> guy.shaa...@nokia.com
>
>
>
> __
> 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 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] [mistral] What's new in latest CloudFlow?

2018-02-26 Thread Shaanan, Guy (Nokia - IL/Kfar Sava)
CloudFlow [1] is an open-source web-based GUI tool that helps visualize and 
debug Mistral workflows.

With the latest release [2] of CloudFlow (v0.5.0) you can:
* Visualize the flow of workflow executions
* Identify the execution path of a single task in huge workflows
* Search Mistral by any entity ID
* Identify long-running tasks at a glance
* Easily distinguish between simple task (an action) and a sub workflow 
execution
* Follow tasks with a `retry` and/or `with-items`
* 1-click to copy task's input/output/publish/params values
* See complete workflow definition and per task definition YAML
* And more...

CloudFlow is easy to install and run (and even easier to upgrade), and we 
appreciate any feedback and contribution.

CloudFlow currently supports unauthenticated Mistral or authentication with 
KeyCloak (openid-connect implementation). A support for Keystone will be added 
in the near future.

You can try CloudFlow now on your Mistral Pike/Queens, or try it on the online 
demo [3].

[1] https://github.com/nokia/CloudFlow
[2] https://github.com/nokia/CloudFlow/releases/latest
[3] http://yaqluator.com:8000


Thanks,
-
Guy Shaanan
Full Stack Web Developer, CI & Internal Tools
CloudBand @ Nokia Software, Nokia, ISRAEL
guy.shaa...@nokia.com

__
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] [mistral][release][ffe] Requesting FFE for supporting source execution id in the Mistral client

2018-02-14 Thread Renat Akhmerov
Thanks!


Renat Akhmerov
@Nokia

On 14 Feb 2018, 22:55 +0700, Matthew Thode , wrote:
> On 18-02-14 17:03:10, Renat Akhmerov wrote:
> > Hi,
> >
> > We were asked to do a FFE request to be able to release a new version of 
> > Mistral client out of stable/queens branch.
> >
> > The backport patch: https://review.openstack.org/#/c/543393/
> > The release patch: https://review.openstack.org/#/c/543402
> >
> > The reason to do that after the feature freeze is that we didn’t backport 
> > (and release) this patch by mistake (simply missed it) whereas the 
> > corresponding functionality was already included on the server side and 
> > went to Queens-3 and subsequent releases.
> >
> > From my side I can assure that the change is backwards compatible and very 
> > much wanted in stable/queens by many users.
> >
> > Hence we’re kindly asking to approve the release patch.
> >
>
> FFE approved from the requirements side.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> 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 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] [mistral][release][ffe] Requesting FFE for supporting source execution id in the Mistral client

2018-02-14 Thread Matthew Thode
On 18-02-14 17:03:10, Renat Akhmerov wrote:
> Hi,
> 
> We were asked to do a FFE request to be able to release a new version of 
> Mistral client out of stable/queens branch.
> 
> The backport patch: https://review.openstack.org/#/c/543393/
> The release patch: https://review.openstack.org/#/c/543402
> 
> The reason to do that after the feature freeze is that we didn’t backport 
> (and release) this patch by mistake (simply missed it) whereas the 
> corresponding functionality was already included on the server side and went 
> to Queens-3 and subsequent releases.
> 
> From my side I can assure that the change is backwards compatible and very 
> much wanted in stable/queens by many users.
> 
> Hence we’re kindly asking to approve the release patch.
> 

FFE approved from the requirements side.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
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] [mistral][release][ffe] Requesting FFE for supporting source execution id in the Mistral client

2018-02-14 Thread Dougal Matthews
On 14 February 2018 at 10:03, Renat Akhmerov 
wrote:

> Hi,
>
> We were asked to do a FFE request to be able to release a new version of
> Mistral client out of stable/queens branch.
>
> The backport patch: https://review.openstack.org/#/c/543393/
> The release patch: https://review.openstack.org/#/c/543402
>
> The reason to do that after the feature freeze is that we didn’t backport
> (and release) this patch by mistake (simply missed it) whereas the
> corresponding functionality was already included on the server side and
> went to Queens-3 and subsequent releases.
>
> From my side I can assure that the change is backwards compatible and very
> much wanted in stable/queens by many users.
>

Thanks Renat, I agree. This should be safe from a compatibility point of
view and simple an oversight. Missing this was an error on our part, we
will try to be more organised for future releases.



Hence we’re kindly asking to approve the release patch.
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> 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 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


  1   2   3   4   5   6   7   8   9   10   >