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

[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

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

[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 
> > > > >  > > > > <mailto:renat.akhme...@gmail.com>> wrote:
> > > > >
> > > > > Hi Oslo Team,
> > > > >
> > > > > Can we retain “blocking” e

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

[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  > <mailto:renat.akhme...@gmail.com>> 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://ope

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

[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

[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

Re: [openstack-dev] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

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

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

[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

[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

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

[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

Re: [openstack-dev] [sqlalchemy][db][oslo.db][mistral] Is there a recommended MySQL driver for OpenStack projects?

[Renat Akhmerov]

>
> If you have a scaling issue that may be solved by eventlet, that's
> one thing, but please don't adopt eventlet just because a lot of
> other projects have. We've tried several times to minimize our
> reliance on eventlet because new releases tend to introduce bugs.
>
> Have you tried the 'threading' executor?

Yes, we’re trying to solve a scaling issue. Well, I tried “threading” executor 
also but there’s no visible performance boost.

Renat

__
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] [sqlalchemy][db][oslo.db][mistral] Is there a recommended MySQL driver for OpenStack projects?

[Renat Akhmerov]

Hi,

We’ve tried to address the bug [1] which is essentially caused by the fact that 
we saw that MySQLDb driver wasn’t compatible with eventlet’s green threads. In 
a nutshell, when we used the “eventlet” RPC executor (see [2]), the system 
would get stuck once in a while when dispatching green between green threads 
when it tried to hit Mysql, but since the driver wasn’t eventlet friendly it 
didn’t work. For that reason we had to use the “blocking” RPC executor so far 
for Mistral Engine that deals with DB transactions.

Now, I am back to experiment with all this and see if we can actually switch to 
“eventlet” like most other project do. So far, it seems like the problem is 
gone in case if I’m using Pymysql driver (didn’t yet try other drivers like 
mysqlclient and the official mysql connector from Oracle). Previously, at least 
in production we always used MySQLDb on Python 2.7.

So, I’m trying to understand if we have a “community recommended” (or may be 
even mandatory) Mysql driver to use and what consequences of the driver choice 
are. I’d appreciate any help with clarifying this (may be links to some 
previous discussions etc.)

Thanks

[1] https://bugs.launchpad.net/mistral/+bug/1696469
[2] https://docs.openstack.org/oslo.messaging/ocata/executors.html#eventlet

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

[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

Re: [openstack-dev] ​[openstack-dev] [mistral] timeout and retry

[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 <mc...@yandex.ru>, 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" <renat.akhme...@gmail.com>:
> > 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 <mc...@yandex.ru>, 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] ​[openstack-dev] [mistral] timeout and retry

[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 <mc...@yandex.ru>, 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

Re: [openstack-dev] [mistral] September PTG in Denver

[Renat Akhmerov]

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

[Renat Akhmerov]

On 23 Apr 2018, 13:38 +0700, Jaewook Oh <kyle.o...@gmail.com>, 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

Re: [openstack-dev] [Mistral]I think Mistral need K8S action

[Renat Akhmerov]

On 13 Apr 2018, 23:01 +0700, Dougal Matthews <dou...@redhat.com>, 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

[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, 홍선군 <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

Re: [openstack-dev] [requirements] Adding objgraph to global requirements

[Renat Akhmerov]

On 29 Mar 2018, 20:20 +0700, Doug Hellmann , wrote:

> What sorts of tools are you talking about building?

Well, some more high level functions to diagnose memory usage, especially aids 
to help find memory leaks. Or not even necessary memory leaks, we may also 
want/need to reduce the memory footprint. Although objgraph is very helpful on 
its own it is still pretty low level and, for example, if we want to inject 
some diagnostic message somewhere in the code (e.g. “top 5 object types whose 
total size increased memory consumption since the last call”) we’d have to 
directly invoke objgraph and remember what exact parameters to use to achieve 
that. I think it’d be more convenient to have some more high-level functions 
that already encapsulate all necessary logic related to using objgraph and 
achieve what’s needed. Also, I wouldn’t want to spread out uses of objgraph all 
of the code, I would better have one module that uses it. Just to reduce 
coupling with a 3rd party lib.

Sorry if that sounds too abstract now, I’ll try to come with concrete examples 
to demonstrate what I mean.

Renat
__
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] [requirements] Adding objgraph to global requirements

[Renat Akhmerov]

After some discussion in IRC on this topic there was an idea just to write and 
push upstream needed tools using objgraph w/o having it in the requirements.txt 
at all. We just need to make sure that those tools are never used during 
production runs and unit tests (CI will help to verify that). If needed, 
objgraph can be manually installed used when we need to investigate something.

If such practice is considered OK and doesn’t violate any OpenStack guidelines 
then I think this would work, at least in my case.

Thanks

Renat Akhmerov
@Nokia

On 29 Mar 2018, 15:00 +0700, Renat Akhmerov <renat.akhme...@gmail.com>, wrote:
> Hi,
>
> Can we consider to add objgraph [1] to OpenStack global requirements? I found 
> this library extremely useful for investigating memory leaks in Python 
> programs but unfortunately I can’t push upstream any code using it. It seems 
> to be pretty mature and supports all needed Python versions.
>
> Or maybe there’s some alternative already available in the OpenStack 
> requirements?
>
> [1] https://pypi.python.org/pypi/objgraph/3.4.0
>
>
> 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] [requirements] Adding objgraph to global requirements

[Renat Akhmerov]

Hi,

Can we consider to add objgraph [1] to OpenStack global requirements? I found 
this library extremely useful for investigating memory leaks in Python programs 
but unfortunately I can’t push upstream any code using it. It seems to be 
pretty mature and supports all needed Python versions.

Or maybe there’s some alternative already available in the OpenStack 
requirements?

[1] https://pypi.python.org/pypi/objgraph/3.4.0


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] PTG Summary

[Renat Akhmerov]

On 7 Mar 2018, 16:29 +0700, Dougal Matthews <dou...@redhat.com>, 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] Retiring the Mistral Wiki pages

[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 <renat.akhme...@gmail.com>, 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 <dou...@redhat.com>, 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

[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 <dou...@redhat.com>, 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][release][ffe] Requesting FFE for supporting source execution id in the Mistral client

[Renat Akhmerov]

Thanks!


Renat Akhmerov
@Nokia

On 14 Feb 2018, 22:55 +0700, Matthew Thode <prometheanf...@gentoo.org>, 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

[openstack-dev] [mistral][release][ffe] Requesting FFE for supporting source execution id in the Mistral client

[Renat Akhmerov]

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.

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] PTG planning on Friday “office hours” session

[Renat Akhmerov]

Hi,

This Friday at 8.00 UTC we’ll have our first “Office hours” session according 
to the time slots earlier proposed in this email thread. It will be devoted to 
the Dublin PTG planning so please join us at #openstack-mistral if you want to 
participate (bring your items, get to know things going on etc.)

And I’m still hoping that more people will give their feedback on the proposal 
itself.

Just to remind what the proposed time slots for office hours are:

1. Mon 16.00 UTC (it used to be our time of weekly meetings)
2. Wed 3.00 UTC
3. Fri 8.00 UTC


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] Proposing time slots for Mistral office hours

[Renat Akhmerov]

Hi,

Not so long ago we decided to stop holding weekly meetings in one of the 
general IRC channel (it was #openstack-meeting-3 for the last several months). 
The main reason was that we usually didn’t have a good representation of the 
team there because the team is distributed across the world. We tried to find a 
time slot several times that would work well for all the team members but 
failed to. Another reason is that we didn’t always have a clear reason to 
gather because everyone was just focused on their tasks and a discussion wasn’t 
much needed so a meeting was even a distraction.

However, despite all this we still would like channels to communicate, the team 
members and people who have user questions and/or would like to start 
contributing.

Similarly to other teams in OpenStack we’d like to try the “Office hours” 
concept. If we follow it we’re supposed to have team members, for whom the time 
slot is OK, available in our channel #openstack-mistral during certain hours. 
These hours can be used for discussing our development stuff between team 
members from different time zones and people outside the team would know when 
they can come and talk to us.

Just to start the discussion on what the office hours time slots could be I’m 
proposing the following time slots:

1. Mon 16.00 UTC (it used to be our time of weekly meetings)
2. Wed 3.00 UTC
3. Fri 8.00 UTC

Each slot is one hour.

Assumingly, #1 would be suitable for people in Europe and America. #2 for 
people in Asia and America. And #3 for people living in Europe and Asia. At 
least that was my thinking when I was wondering what the time slots should be.

Please share your thoughts on this. The idea itself and whether the time slots 
look ok.

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][ptl] PTL candidacy

[Renat Akhmerov]

Hi,

I'm Renat Akhmerov. I'm running for PTL of Mistral in Rocky.

Mistral is a workflow service developed within the OpenStack community from
the ground up.

In queens we mainly focused on bugfixing, improving performance and
documentation. Performance was again significantly improved (~100%)
by optimizing DB operations and data schema (mostly additional indexex)
and using caching technics. We also made Mistral more robust in various
failure situations. To achieve that we came up with a number of protection
mechanisms.

The two other noticeable features we added are:

* We can now start a Mistral workflow based on an existing workflow
  execution, no matter if it's still running or finished. Given an ID of
  an execution Mistral copies all needed parameters (input, env etc.) and
  creates a new execution.
* When creating a workflow execution, we can now pass an ID of the new
  execution. If an execution with this ID already exists the REST endpoint
  just returns details of this execution as if it was GET operation. If
  not, it create a execution with this ID. Thus creation of workflow
  execution can be idempotent.


For the next cycle I'd like to propose the following roadmap:

* Keep improving multi-node mode and HA
* Rearchitect Mistral Scheduler, make it more suitable for HA
* Optimize ‘join’ tasks
* Close all the gaps in the documentation and restructure it so it is more
  convenient to read and navigate
* Usability
  * New CLI/API (more consistent and human friendly interface)
  * Debugging workflows
  * Workflow failure analysis (error messages, navigate through nested
    workflows etc.)
* Refactor Actions subsystem
  * Actions testability
  * Move OpenStack actions into mistral-extra and with better test coverage
    and usability

Some of those items have now been in progress for a few months. We keep
working on them and I hope most of them will be completed in the next
cycle.

Should you have any ideas on these points we're always happy to discuss and
correct our plans.

We're always happy to get new contributors on the project and always ready
to help people interested in Mistral development get up to speed. The best
way to get in touch with us is IRC channel #openstack-mistral.


The corresponding patch to openstack/election:
https://review.openstack.org/#/c/540720/

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] [telemetry][heat][mistral][sdk][searchlight][senlin][tacker][tricircle][tripleo] Missing Queens releases

[Renat Akhmerov]

Sorry for the late reply. I just want to confirm that it’s ok from Mistral side.

Thanks

Renat Akhmerov
@Nokia

On 2 Feb 2018, 02:35 +0700, Sean McGinnis <sean.mcgin...@gmx.com>, wrote:
> Just confirming and closing things out. We did not receive any negative
> responses to the plan below, so a little earlier today I approved the 
> mentioned
> patch and we cut releases and branches for all libs.
>
> The next step if for these new versions to pass CI and get FFEs to raise the
> upper constraints for them past our requirements freeze. That official request
> will be coming shortly.
>
> Sean
>
> On Wed, Jan 31, 2018 at 03:03:44PM -0600, Sean McGinnis wrote:
> > While reviewing Queens release deliverables and preparing missing 
> > stable/queens
> > branches, we have identified several libraries that have not had any Queens
> > releases.
> >
> > In the past, we have stated we would force a release for any missing
> > deliverables in order to have a clear branching point. We considered tagging
> > the base of the stable/pike branch again and starting a new stable/queens
> > branch from there, but that doesn't work for several technical reasons the 
> > most
> > important of which is that the queens release would not include any changes
> > that had been backported to stable/pike, and we have quite a few of those. 
> > So,
> > we are left with 2 choices: do not release these libraries at all for 
> > queens,
> > or release from HEAD on master. Skipping the releases entirely will make it
> > difficult to provide bug fixes in these libraries over the life of the 
> > queens
> > release so, although it is potentially disruptive, we plan to release from 
> > HEAD
> > on master. We will rely on the constraints update mechanism to protect the 
> > gate
> > if the new releases introduce bugs and teams will be able to fix those 
> > problems
> > on the new stable/queens branch and then release a new version.
> >
> > See https://review.openstack.org/#/c/539657/ and the notes below for 
> > details of
> > what will be tagged.
> >
> > ceilometermiddleware
> > 
> >
> > Mostly doc and CI related changes, but the "Retrieve project id to ignore 
> > from
> > keystone" commit (e2bf485) looks like it may be important.
> >
> > Heat
> > 
> >
> > heat-translator
> > There are quite a few bug fixes and feature changes merged that have not 
> > been
> > released. It is currently marked with a type of "library", but we will 
> > change
> > this to "other" and require a release by the end of the cycle (see
> > https://review.openstack.org/#/c/539655/ for that change). Based on the 
> > README
> > description, this appears to be a command line and therefore should maybe 
> > have
> > a type of "client-library", but "other" would work as far as release process
> > goes. Since this is kind of a special command line, perhaps "other" would be
> > the correct type going forward, but we will need input from the Heat team on
> > that.
> >
> > python-heatclient
> > Only reno updates, so a new release on master should not be very disruptive.
> >
> > tosca-parser
> > Several unreleased bug fixes and feature changes. Consumed by 
> > heat-translator
> > and tacker, so there is some risk in releasing it this late.
> >
> >
> > Mistral
> > ---
> >
> > mistral-lib
> > Mostly packaging and build changes, with a couple of fixes. It is used by
> > mistral and tripleo-common.
> >
> > SDK
> > ---
> >
> > requestsexceptions
> > No changes this cycle. We will branch stable/queens from the same point as
> > stable/pike.
> >
> > Searchlight
> > ---
> >
> > python-searchlightclient
> > Only doc and g-r changes. Since the risk here is low, we are going to 
> > release
> > from master and branch from there.
> >
> > Senlin
> > --
> >
> > python-senlinclient
> > Just one bug fix. This is a dependency for heat, mistral, openstackclient,
> > python-openstackclient, rally, and senlin-dashboard. The one bug fix looks
> > fairly safe though, so we are going to release from master and branch from
> > there.
> >
> > Tacker
> > --
> >
> > python-tackerclient
> > Many feature changes and bug fixes. This impacts mistral and tacker.
> >
> > Tricircle
> > -
> >
> > python-tricircleclient
> > One f

Re: [openstack-dev] [mistral] Adding Adriano Petrich to the core team

[Renat Akhmerov]

Adriano, you now have +2 vote and can approve patches :) Welcome!

Thanks

Renat Akhmerov
@Nokia

On 16 Jan 2018, 05:03 +0700, Lingxian Kong <anlin.k...@gmail.com>, wrote:
> welcome to the team, Adriano!
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> > On Mon, Jan 15, 2018 at 10:11 PM, Renat Akhmerov <renat.akhme...@gmail.com> 
> > wrote:
> > > Hi,
> > >
> > > I’d like to promote Adriano Petrich to the Mistral core team. Adriano has 
> > > shown the good review rate and quality at least over the last two cycles 
> > > and implemented several important features (including new useful 
> > > YAQL/JINJA functions).
> > >
> > > Please vote whether you agree to add Adriano to the core team.
> > >
> > > Adriano’s statistics: 
> > > http://stackalytics.com/?module=mistral-group=queens_id=apetrich
> > >
> > > 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 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] Adding Adriano Petrich to the core team

[Renat Akhmerov]

Hi,

I’d like to promote Adriano Petrich to the Mistral core team. Adriano has shown 
the good review rate and quality at least over the last two cycles and 
implemented several important features (including new useful YAQL/JINJA 
functions).

Please vote whether you agree to add Adriano to the core team.

Adriano’s statistics: 
http://stackalytics.com/?module=mistral-group=queens_id=apetrich

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] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Renat Akhmerov]

We (Mistral) are ready to react too whenever the version is bumped. IMO, the 
sooner the better.

Thanks

Renat Akhmerov
@Nokia

On 9 Jan 2018, 04:00 +0700, Matthew Thode <prometheanf...@gentoo.org>, wrote:
> On 17-12-20 10:56:50, Matthew Thode wrote:
> > On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> > > Hi,
> > >
> > > There is an open bug in launchpad about the new release of Networkx 2.0, 
> > > that is backward incompatible with versions 1.x [1].
> > > Is there a plan to change the Networkx version in the global requirements 
> > > in Queens? We need to make some code refactoring in Vitrage, and I’m 
> > > trying to understand how urgent it is.
> > >
> > > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> > >
> >
> > Mistral, Vitrage, Octavia, Taskflow, Watcher
> >
> > Those are the projects using NetworkX that'd need to be updated.
> > http://codesearch.openstack.org/?q=networkx=nope=.*requirements.*=
> >
> > I'm open to uncapping networkx if these projects have buyin.
> >
>
> I've created https://review.openstack.org/531902 that your patches can
> depend upon.
>
> --
> 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] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Renat Akhmerov]

Ok, we’ll look at it in Queens.

Thanks

Renat Akhmerov
@Nokia

On 20 Dec 2017, 23:57 +0700, Matthew Thode <prometheanf...@gentoo.org>, wrote:
> On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> > Hi,
> >
> > There is an open bug in launchpad about the new release of Networkx 2.0, 
> > that is backward incompatible with versions 1.x [1].
> > Is there a plan to change the Networkx version in the global requirements 
> > in Queens? We need to make some code refactoring in Vitrage, and I’m trying 
> > to understand how urgent it is.
> >
> > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> >
>
> Mistral, Vitrage, Octavia, Taskflow, Watcher
>
> Those are the projects using NetworkX that'd need to be updated.
> http://codesearch.openstack.org/?q=networkx=nope=.*requirements.*=
>
> I'm open to uncapping networkx if these projects have buyin.
>
> --
> 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

[openstack-dev] [mistral][irc] Switching to office hours from weekly meetings

[Renat Akhmerov]

Hi,

At the previous weekly meeting we decided to learn about experience of other 
teams using office hours instead of having weekly meetings in IRC. The main 
reason is that it’s almost impossible to find a good time slot so that it works 
for everyone and most of our meetings have pretty few attendees. Or, our 
meetings end very quickly because people are just focused on their tasks and 
there’s not so much to discuss.

That said, there won’t be a weekly meeting today. We’ll try to propose time 
slots for office hours this week.

Until then, should you have anything to discuss just come to our IRC channel 
#openstack-mistral or write to this mailing list with tags 
"[openstack-dev][mistral]” in the subject.

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] [all] Switching to longer development cycles

[Renat Akhmerov]

On 14 Dec 2017, 17:04 +0700, wrote:

>
> Can you detail more how having a longer cycle will make people that
> spends 20% of their time on OpenStack "catch up" with the people that
> spends 80% of their time on OpenStack?
>
> I understand the problem but I don't see how the proposed solution
> solves it.

Yes, exactly.


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] [all] Switching to longer development cycles

[Renat Akhmerov]

Maybe not exactly on the topic but I’d like to express some more thoughts on 
OpenStack development rhythm being too harsh for newcomers and part time 
developers.

Although I partially agree with the initial Thierry’s point I think the key 
thing here itself is that they are part time developers. Too part time.. Based 
on my observations, it’s very very difficult to weave a new developer with 
normal average skills (there geniuses, of course, but they are exceptions) into 
the project development if he/she randomly spends several days a month to 
contribute upstream. If we adjust the speed of development to make these people 
happy then we’ll be moving forward like turtles.

I would rather work on encouraging companies to allocate full time developers 
explaining them all the benefits of such approach. I know, I know, it’s not 
easy but it seems to me that everyone is suffering from the situation when devs 
only work on their priorities w/o taking responsibility for the overall project 
quality, and then suddenly realize that the project is almost dead just because 
it’s not interesting to anyone else who want to use it for slightly different 
use cases but can’t because it’s not mature enough (and hold on with 
contributing for the same reason). I strongly believe this is a serious issue. 
It feels to me that it used to be different years ago, people weren’t afraid to 
be more responsible for their projects.

So I agree that this is a problem but I’m not sure that making development 
cycles longer will solve it.

Despite all I said, I’m still for 1 year cycles. The main reason for me is that 
it seems like we spend much time for inter cycle activities, including 
preparation to PTGs and summits, releasing, taking care of FFEs and emergency 
back ports etc. I as a developer get distracted seriously from solving 
technically challenging tasks. And then it’s often hard to tune back to a 
needed wave. But many tasks require focus during a significant period of time 
to be solved. Sounds a little bit fuzzy probably but it’s an issue personally 
for me. Maybe because I’m also trying to combine development with PTLship, but 
still..

Thanks

Renat Akhmerov
@Nokia

On 14 Dec 2017, 12:02 +0700, Ed Leafe <e...@leafe.com>, wrote:
> On Dec 13, 2017, at 5:44 PM, Clint Byrum <cl...@fewbar.com> wrote:
>
> > One thing I've always admired about Swift was how immune to the cadence 
> > Swift
> > appears to be.
>
> As I've pointed out before [0], Swift is a whole 'nother thing.
>
> It does not have API interdependencies with anything else in OpenStack. It is 
> free to do things its own way on its own schedule.
>
> The rest of OpenStack is what Nova originally was. It was split into many 
> different project because of the sheer complexity of the tasks it had to 
> perform. But splitting it up required that we occasionally have to make sure 
> that we're all still working together well.
>
> [0] https://blog.leafe.com/on_swift/
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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][ptl] PTL is on vacation from Nov 23 till Dec 4

[Renat Akhmerov]

Ooh, my apologies for the typo!

Thanks Dougal )

Renat Akhmerov
@Nokia

On 20 Nov 2017, 18:42 +0700, Dougal Matthews <dou...@redhat.com>, wrote:
>
>
> > On 20 November 2017 at 08:56, Renat Akhmerov <renat.akhme...@gmail.com> 
> > wrote:
> > > Hi,
> > >
> > > I’ll be on vacation from Nov 23 till Dec 4, inclusive. Dougal Matthews 
> > > (d0gal) will be replacing me during this period.
> >
> > It doesn't matter too much, but it is d0ugal if anyone is looking for me on 
> > IRC :-)
> >
> > >
> > > 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 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 is on vacation from Nov 23 till Dec 4

[Renat Akhmerov]

Hi,

I’ll be on vacation from Nov 23 till Dec 4, inclusive. Dougal Matthews (d0gal) 
will be replacing me during this period.

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] No team meeting today - 11/13/2017

[Renat Akhmerov]

Hi, we’re cancelling the team meeting today because a number of key members 
won’t attend.

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] [oslo][mistral] Mistral expressions package

[Renat Akhmerov]

Ok, thanks for your input.

I’d personally say it’s not really worth it but if Bob wants to do it that’s ok.

Thanks

Renat Akhmerov
@Nokia

On 19 Oct 2017, 12:46 +0700, ChangBo Guo <glongw...@gmail.com>, wrote:
> The dependencies of  mistral expressions package make it hard to be adopted 
> as a module of oslo library,  we need oslo library keep simple.
> we have a adopt process [1]  which is not merged to help guide the adoption 
> process if we agree.  agree with Dough, we can discuss in the Oslo weekly 
> meeting.[2]
>
>
> [1] https://review.openstack.org/312233
> [2] http://eavesdrop.openstack.org/#Oslo_Team_Meeting
>
> > 2017-10-18 12:46 GMT+08:00 Renat Akhmerov <renat.akhme...@gmail.com>:
> > > Hi,
> > >
> > > I’m not too happy about the idea of creating one more subproject within 
> > > Mistral. I don’t even see now what else this new library project managed 
> > > by Mistral team will contain besides this expression utils module. I’m 
> > > also not sure about its name. We already have mistral-lib which was 
> > > created for a different purpose (public APIs for making Mistral 
> > > extensions like actions and YAQL/Jinja functions).
> > >
> > > Just to clarify: the code we’re talking about is really small and stable 
> > > (we haven’t touched it for a while, it just works), and it’s generic so 
> > > it can be reused in many situations by many projects. That’s why we had 
> > > an idea to find a place within one of the Oslo libraries, just to make 
> > > one more package (or even module), for example, in oslo.utils. As far as 
> > > maintaining this code, we could still do that. But anyway, if that’s not 
> > > OK, I’d just suggest we leave it as it is. If this code needs to be 
> > > reused somewhere else outside OpenStack space (like in Bob’s case) may be 
> > > it’s just simpler to create a project on github?
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > >
> > > On 10 Oct 2017, 22:11 +0700, Doug Hellmann <d...@doughellmann.com>, wrote:
> > > > Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 
> > > > 19:41:58 -0500:
> > > > > On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > > > > > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> > > > > > > Hello Oslo team:
> > > > > > >
> > > > > > > The Mistral project has an expressions package [0] that is used to
> > > > > > > evaluate inline expressions using a context. It has a pluggable
> > > > > > > architecture that presently supports Jinja and YAQL expression
> > > > > > > evaluation. It also allows custom functions[1] to provide Python
> > > > > > > implementations of functionality that is then made available to 
> > > > > > > the
> > > > > > > expression evaluation engines.
> > > > > > >
> > > > > > > This functionality was originally developed to support dynamic
> > > > > > > processing within Mistral workflows, but is also very useful in 
> > > > > > > other
> > > > > > > applications that use templates which require runtime evaluation 
> > > > > > > of
> > > > > > > expressions.
> > > > > > >
> > > > > > > I'd like to explore extracting this functionality from mistral to 
> > > > > > > make
> > > > > > > it more widely available with minimal dependencies.
> > > > > > >
> > > > > > > The expressions dependencies are pretty limited:
> > > > > > >
> > > > > > > Jinja2
> > > > > > > oslo.utils
> > > > > > > oslo.log
> > > > > > > stevedore
> > > > > > > yaql
> > > > > > >
> > > > > > > and since 60% are already oslo-maintained packages, it seemed 
> > > > > > > like a
> > > > > > > logical place to start.
> > > > > > >
> > > > > > > I'd appreciate feedback on the topic. There is no real OpenStack
> > > > > > > dependency in the functionality, so maybe a standalone package on 
> > > > > > > pypi
> > > > > > > makes sense.
> > > > > > >
> > > > > > > Thanks for you

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

[Renat Akhmerov]

Hi,

I’m not too happy about the idea of creating one more subproject within 
Mistral. I don’t even see now what else this new library project managed by 
Mistral team will contain besides this expression utils module. I’m also not 
sure about its name. We already have mistral-lib which was created for a 
different purpose (public APIs for making Mistral extensions like actions and 
YAQL/Jinja functions).

Just to clarify: the code we’re talking about is really small and stable (we 
haven’t touched it for a while, it just works), and it’s generic so it can be 
reused in many situations by many projects. That’s why we had an idea to find a 
place within one of the Oslo libraries, just to make one more package (or even 
module), for example, in oslo.utils. As far as maintaining this code, we could 
still do that. But anyway, if that’s not OK, I’d just suggest we leave it as it 
is. If this code needs to be reused somewhere else outside OpenStack space 
(like in Bob’s case) may be it’s just simpler to create a project on github?

Thanks

Renat Akhmerov
@Nokia

On 10 Oct 2017, 22:11 +0700, Doug Hellmann <d...@doughellmann.com>, wrote:
> Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58 
> -0500:
> > On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> > > > Hello Oslo team:
> > > >
> > > > The Mistral project has an expressions package [0] that is used to
> > > > evaluate inline expressions using a context. It has a pluggable
> > > > architecture that presently supports Jinja and YAQL expression
> > > > evaluation. It also allows custom functions[1] to provide Python
> > > > implementations of functionality that is then made available to the
> > > > expression evaluation engines.
> > > >
> > > > This functionality was originally developed to support dynamic
> > > > processing within Mistral workflows, but is also very useful in other
> > > > applications that use templates which require runtime evaluation of
> > > > expressions.
> > > >
> > > > I'd like to explore extracting this functionality from mistral to make
> > > > it more widely available with minimal dependencies.
> > > >
> > > > The expressions dependencies are pretty limited:
> > > >
> > > > Jinja2
> > > > oslo.utils
> > > > oslo.log
> > > > stevedore
> > > > yaql
> > > >
> > > > and since 60% are already oslo-maintained packages, it seemed like a
> > > > logical place to start.
> > > >
> > > > I'd appreciate feedback on the topic. There is no real OpenStack
> > > > dependency in the functionality, so maybe a standalone package on pypi
> > > > makes sense.
> > > >
> > > > Thanks for your help,
> > > >
> > > > Bob Haddleton
> > > >
> > > >
> > > > [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> > > > [1]
> > > > https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> > > >
> > > Oslo is a good place for things like this that have no other obvious
> > > home, but if the Mistral team is already managing the code is there any
> > > reason they couldn't also manage the library after you pull it out of
> > > the service? It's much easier for any project team to manage a library
> > > now, and we have several other examples of that pattern already.
> > >
> > > Doug
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > Hi Doug:
> >
> > That's probably fine, we're just not sure what the process should be and
> > where the library would land?  Do you have an example that we could use
> > as a pattern?
> >
> > Thanks
> >
> > Bob
>
> The first step is to create the repository with the library code. Then
> you would add that repository to the list managed by the mistral team by
> modifying the project list file in the governance repository.
>
> Any of the project client libraries would work as an example of how to
> set up the CI, governance, and release configuration. I think most of
> the steps are covered in
> https://do

Re: [openstack-dev] [stable][mistral] Asking for stable branch policy exception

[Renat Akhmerov]

Dougal,

I forgot to mention that explicitly but, yes, #1 is needed only not to break 
the sequence of migrations. We can manually fix the migration number in #2 just 
for stable/pike but I somewhat don’t like the idea of having different 
migration numbers in different branches.

It’s a good news that we’re not going to break TripleO.

Thanks

Renat Akhmerov
@Nokia

On 17 Oct 2017, 20:21 +0700, Dougal Matthews <dou...@redhat.com>, wrote:
>
>
> > On 17 October 2017 at 09:19, Renat Akhmerov <renat.akhme...@gmail.com> 
> > wrote:
> > > Hi,
> > >
> > > We have two patches in Mistral that we need to back port to stable/pike. 
> > > However, they are against of stable branch management policy because they 
> > > slightly change the DB schema. The patches are the following:
> > >
> > > 1. https://review.openstack.org/#/c/512528/
> > > 2. https://review.openstack.org/#/c/512256/
> > >
> > >
> > > #2 is a critically important fix that fixes a problem of decreasing 
> > > Mistral performance when DB becomes heavy (has lots of execution 
> > > objects). This is a blocker issue for us (Nokia) preventing us using 
> > > Mistral in production. It also seriously optimizes performance in general.
> > >
> > > So hereby I'm asking your advice on what we can do in this situation. Can 
> > > we merge these patches if we make sure that we don't break anyone in the 
> > > community? For example, TripleO.
> >
> > As far as I am aware, this wont be a problem for TripleO. These patches are 
> > both additive (new db column and new db index).
> >
> > The first patch (512528) is only a candidate for backport to avoid breaking 
> > the migration history order, it isn't otherwise needed in Pike. How is this 
> > normally handled in other projects? i.e. we need to backport migration 24 
> > to Pike, but 23 is in master only. I assume this problem has came up before 
> > and been solved, but I can't find any examples.
> >
> >
> > >
> > > 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 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] [stable][mistral] Asking for stable branch policy exception

[Renat Akhmerov]

Hi,

We have two patches in Mistral that we need to back port to stable/pike. 
However, they are against of stable branch management policy because they 
slightly change the DB schema. The patches are the following:

1. https://review.openstack.org/#/c/512528/
2. https://review.openstack.org/#/c/512256/


#2 is a critically important fix that fixes a problem of decreasing Mistral 
performance when DB becomes heavy (has lots of execution objects). This is a 
blocker issue for us (Nokia) preventing us using Mistral in production. It also 
seriously optimizes performance in general.

So hereby I'm asking your advice on what we can do in this situation. Can we 
merge these patches if we make sure that we don't break anyone in the 
community? For example, TripleO.

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] [all] Update on Zuul v3 Migration - and what to do about issues

[Renat Akhmerov]

On 2 Oct 2017, 21:02 +0700, wrote:

>
> * Zuul Stalls
>
> If you say to yourself "zuul doesn't seem to be doing anything, did I do
> something wrong?", we're having an issue that jeblair and Shrews are
> currently tracking down with intermittent connection issues in the
> backend plumbing.

Hi Monty, does it make sense to recheck patches in this case?

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] [oslo][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Ok, thanks Josh. We switched to tenacity and it works very well for us )

Renat Akhmerov
@Nokia

On 23 Sep 2017, 11:51 +0700, Joshua Harlow <harlo...@fastmail.com>, wrote:
> Hi Renat,
>
> I was more just saying that depending on your situation it might be
> better to switch to using tenacity (not that the retry decorator is
> deprecated, though I wouldn't personally use it).
>
> As you mentioned in
> https://bugs.launchpad.net/oslo.service/+bug/1718635/comments/1 this
> class and decorator is not thread safe so if that is a concern for you
> then that is also better in tenacity.
>
> I think a lot of usage of that decorator though is like the following:
>
> def main_func():
>
> @loopingcall.RetryDecorator
> def inner_func():
> 
>  inner_func()
> 
> So likely thread-safety was never a concern, though I can't quite say...
> I think (but I might be wrong) when that class/code was being proposed I
> recommended just using 'retrying' (the precursor to tenacity) but
> bygones be bygones...
>
> Renat Akhmerov wrote:
> > Thanks Josh,
> >
> > I’m not sure I fully understand your point though. You mean it’s a
> > legacy (deprecated?) code that we should never use in our code? Should
> > it be considered a private class of oslo_service?
> >
> > In our global requirements tenacity is configured as "tenacity>=3.2.1”,
> > should we bump it to 4.4.0?
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 21 Sep 2017, 22:42 +0700, Joshua Harlow <harlo...@fastmail.com>, wrote:
> > > It does look like is sort of a bug,
> > >
> > > Though in all honesty I wouldn't be using oslo.service or that looping
> > > code in the future for doing retrying...
> > >
> > > https://pypi.python.org/pypi/tenacity is a much better library with more
> > > `natural` syntax and works more as one would expect (even under threaded
> > > situations).
> > >
> > > If I could of I would of never let 'loopingcall.py' become a file that
> > > exists, but the past is the past, ha.
> > >
> > > Renat Akhmerov wrote:
> > > > Hi Oslo team,
> > > >
> > > > Can you please check the bug [1]?
> > > >
> > > > There may be a problem with how looping.RetryDecorator works. Just
> > > > stumbled on it in Mistral. Not sure if it’s really a bug or made by
> > > > design. If it’s by design then maybe we need to have more accurate
> > > > documentation for it.
> > > >
> > > > FYI: We use this decorator in Mistral and it’s also used in Nova, [2].
> > > >
> > > > [1] https://bugs.launchpad.net/oslo.service/+bug/1718635
> > > > [2]
> > > > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py
> > > >
> > > > 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 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] Garbage patches for simple typo fixes

[Renat Akhmerov]

+1000

Thanks for bringing this up, I fully agree that we need to do something about 
it.

Some time ago I even had an idea of creating a case when we intentionally 
exclude a person from a team for constantly doing things like this and ignoring 
our comments. Although I understand it slightly conflicts with our openness 
principle.. It’s just really tempting quite often.

Renat Akhmerov
@Nokia

On 22 Sep 2017, 09:26 +0700, Zhipeng Huang <zhipengh...@gmail.com>, wrote:
> Let's not forget the epic fail earlier on the "contribution.rst fix" that 
> almost melt down the community CI system.
>
> For any companies that are doing what Matt mentioned, please be aware that 
> the dev community of the country you belong to is getting hurt by your stupid 
> activity.
>
> Stop patch trolling and doing something meaningful.
>
> > On Fri, Sep 22, 2017 at 10:21 AM, Matt Riedemann <mriede...@gmail.com> 
> > wrote:
> > > I just wanted to highlight to people that there seems to be a series of 
> > > garbage patches in various projects [1] which are basically doing things 
> > > like fixing a single typo in a code comment, or very narrowly changing 
> > > http to https in links within docs.
> > >
> > > Also +1ing ones own changes.
> > >
> > > I've been trying to snuff these out in nova, but I see it's basically a 
> > > pattern widespread across several projects.
> > >
> > > This is the boilerplate comment I give with my -1, feel free to employ it 
> > > yourself.
> > >
> > > "Sorry but this isn't really a useful change. Fixing typos in code 
> > > comments when the context is still clear doesn't really help us, and 
> > > mostly seems like looking for padding stats on stackalytics. It's also a 
> > > drain on our CI environment.
> > >
> > > If you fixed all of the typos in a single module, or in user-facing 
> > > documentation, or error messages, or something in the logs, or something 
> > > that actually doesn't make sense in code comments, then maybe, but this 
> > > isn't one of those things."
> > >
> > > I'm not trying to be a jerk here, but this is annoying to the point I 
> > > felt the need to say something publicly.
> > >
> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > >
> > > --
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > __
> > > 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
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> __
> 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] [oslo][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Thanks Josh,

I’m not sure I fully understand your point though. You mean it’s a legacy 
(deprecated?) code that we should never use in our code? Should it be 
considered a private class of oslo_service?

In our global requirements tenacity is configured as "tenacity>=3.2.1”, should 
we bump it to 4.4.0?

Renat Akhmerov
@Nokia

On 21 Sep 2017, 22:42 +0700, Joshua Harlow <harlo...@fastmail.com>, wrote:
> It does look like is sort of a bug,
>
> Though in all honesty I wouldn't be using oslo.service or that looping
> code in the future for doing retrying...
>
> https://pypi.python.org/pypi/tenacity is a much better library with more
> `natural` syntax and works more as one would expect (even under threaded
> situations).
>
> If I could of I would of never let 'loopingcall.py' become a file that
> exists, but the past is the past, ha.
>
> Renat Akhmerov wrote:
> > Hi Oslo team,
> >
> > Can you please check the bug [1]?
> >
> > There may be a problem with how looping.RetryDecorator works. Just
> > stumbled on it in Mistral. Not sure if it’s really a bug or made by
> > design. If it’s by design then maybe we need to have more accurate
> > documentation for it.
> >
> > FYI: We use this decorator in Mistral and it’s also used in Nova, [2].
> >
> > [1] https://bugs.launchpad.net/oslo.service/+bug/1718635
> > [2]
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py
> >
> > 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Hi Oslo team,

Can you please check the bug [1]?

There may be a problem with how looping.RetryDecorator works. Just stumbled on 
it in Mistral. Not sure if it’s really a bug or made by design. If it’s by 
design then maybe we need to have more accurate documentation for it.

FYI: We use this decorator in Mistral and it’s also used in Nova, [2].

[1]  https://bugs.launchpad.net/oslo.service/+bug/1718635
[2] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py

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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Renat Akhmerov]

I confirm that you can delete mistral versions with “2015”.

Thanks

Renat Akhmerov
@Nokia

On 15 Sep 2017, 23:58 +0700, Rong Zhu <aaronzhu1...@gmail.com>, wrote:
> +1 for murano-dashboard and murano-agent
>
> On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez <thie...@openstack.org> wrote:
> > Claudiu Belu wrote:
> > > So, I believe the general consensus is that the easiest thing to do is to 
> > > unpublish the 2015.1.0 version from pypi, with which I also agree.
> > > [...]
> >
> > Yes, for a first batch I propose we clean up the following:
> >
> > python-congressclient 2015.1.0
> > python-congressclient 2015.1.0rc1
> > python-designateclient 2013.1.a8.g3a2a320
> > networking-hyperv 2015.1.0
> >
> > For the remaining (official) ones (mistral-extra, networking-odl,
> > murano-dashboard, networking-hyperv, networking-midonet,
> > sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
> > sahara-dashboard) let's wait until we can get PTL signoff.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > 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] Cancelling team meeting - 09/18/2017

[Renat Akhmerov]

Hi,

There won’t be a team today. Let’s meet next week and discuss the PTG summary 
and the current activities.

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][ptg] Mistral PTG etherpad and schedule

[Renat Akhmerov]

Welcome to the Queens PTG!

Just reminding that the Mistral PTG is at [1] and it includes the approximate 
schedule. I’m saying “approximate” because, if needed, we can change it a 
little bit if some important topics will be raised unexpectedly.  So I’d 
suggest we quickly review the entire schedule once we start our design sessions 
on Wed.

Looking forward to seeing all the team members who came! Also, not only Mistral 
team members are welcome to join. If you have something to discuss with us 
please come to our room or ping us in IRC.

[1] https://etherpad.openstack.org/p/mistral-ptg-queens

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] No team meeting today

[Renat Akhmerov]

Hi,

We’re cancelling the team meeting today in IRC since our US team members have 
Labor Day.

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][ptl] PTL is on vacation on Aug 14-28

[Renat Akhmerov]

Hi,

I’ll be on vacation between Aug 14th and 28th.

Dougal Matthews (d0ugal in IRC) kindly agreed to replace me while I’m off. 
Please contact him, if needed.

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][core] Proposing Andras Kovi to the Mistral core team

[Renat Akhmerov]

Hi,

I’d like to propose Andras Kovi to the Mistral core team.

The current statistics of Andras can be seen at [1].
Andras has been contributing for about 1.5 years and in Pike he increased his 
activity significantly, primarily reviewing. His reviews are always thorough 
and insightful. He cares about code quality. He knows both OpenStack ecosystem 
and Mistral architecture and codebase well. Adding Andras to the core team 
would be also very useful for us because he is a very active user of Mistral, 
he implemented or participated in implementation of lots of Nokia CBAM use 
cases based on Mistral.
Andras also gave an excellent presentation about Mistral performance in Boston, 
[2]. I’d really recommend to watch it if you work with Mistral as a contributor 
or as a user.
Speaking less formally, Andras is a very good guy, deep thinker with a great 
experience in software programming. Every time I have a chance to meet him 
personally it’s a lot of fun to talk to him and learn from him.

So I’m asking you to support me in this promotion. I really believe that Andras 
will be an invaluable addition to our team.

[1] http://stackalytics.com/?module=mistral-group_id=akovi
[2] https://www.openstack.org/videos/boston-2017/mistral-performance-in-numbers

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] [requirements][mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Renat Akhmerov]

Thanks!


Renat Akhmerov
@Nokia

On 8 Aug 2017, 23:23 +0700, Matthew Thode <prometheanf...@gentoo.org>, wrote:
> On 17-08-08 08:03:42, Matthew Thode wrote:
> > On 17-08-08 16:11:53, Renat Akhmerov wrote:
> > > Hi,
> > >
> > > We recently sent a patch [1] to release the version 3.1.2 of 
> > > python-mistralclient out of Pike branch. It was done after the date of 
> > > final client library releases so we’d like to discuss if we can allow 
> > > such an exception. All the projects mentioned in the subject may be 
> > > affected so please share if the change is acceptable for you or not. 
> > > Details are below.
> > >
> > > When using Mistral CLI in real deployments we found that some of the list 
> > > commands may be extremely heavy (mostly memory footprint) when called w/o 
> > > the “limit” parameter that constrains the result set by the specified 
> > > value. For example, “mistral execution-list”, “mistral task-list” and 
> > > “mistral action-execution-list”. We saw a number of times that machines 
> > > went out of memory after running such a command, sometimes it was done by 
> > > mistake by operators. So we decided to set a default value for this 
> > > parameter, which is currently 100, to prevent from unintentional 
> > > execution of such heavy commands. The corresponding patch [2] was sent on 
> > > July 11 and was included in the release 3.1.1. For 
> > > “action-execution-list”, before this patch “limit" parameter didn’t exist 
> > > at all so we added it too. However, the change wasn’t made properly so 
> > > that “limit” parameter was just ignored at all times. We fixed that in 
> > > [3] and decided to release 3.1.2.
> > >
> > > So long story short, this change will affect your project only if you use 
> > > “mistral action-execution-list” CLI command because now this command will 
> > > be returning by default only 100 entries (to return all “--limit=-1” 
> > > needs to be passed).
> > >
> > > We at Nokia need this fix released in Pike because we need to trigger 
> > > updates of RDO packages used in our system.
> > >
> > >
> > > The question: can we afford to make this release now?
> > >
> > > More details on requirements updates etc. you can see in the discussion 
> > > in [1].
> > >
> > > [1] https://review.openstack.org/#/c/491269
> > > [2] https://review.openstack.org/#/c/476110/
> > > [3] https://review.openstack.org/#/c/489217/
> > >
> > > 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
> >
> > It sounds like you will need a requirements update as well, both UC and
> > maybe GR. GR would suck at this VERY late point. The current minimum
> > is 3.1.0 will that not work just like 3.1.1 doesn't work?
> >
> > --
> > Matthew Thode (prometheanfire)
>
> ok, after discussing in irc...
>
> 3.1.2 has a user interface only change fixing a regression in 3.1.1 that 
> doesn't
> not exist in 3.1.0, so no GR bump is needed.
>
> I'm fine with requirements doing a UC only bump here.
>
> FFE allowed for requirements for UC only (my vote)
>
> --
> 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][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Renat Akhmerov]

On 8 Aug 2017, 17:45 +0700, Thierry Carrez <thie...@openstack.org>, wrote:

> Renat Akhmerov wrote:
> > [...]
> > So long story short, this change will affect your project only if you
> > use “mistral action-execution-list” CLI command because now this command
> > will be returning by default only 100 entries (to return all
> > “--limit=-1” needs to be passed).
>
> A number of projects depend on python-mistralclient:
>
> openstack/python-tripleoclient [cycle-trailing]
> openstack/python-troveclient [cycle-with-intermediary]
> openstack/heat [cycle-with-milestones]
> openstack/mistral [cycle-with-milestones]
> openstack/murano [cycle-with-milestones]
> openstack/solum [cycle-with-intermediary]
> openstack/tacker [cycle-with-intermediary]
> openstack/instack-undercloud [cycle-with-intermediary]
> openstack/mistral-dashboard [None]
> openstack/openstackclient [None]
> openstack/python-openstackclient [cycle-with-intermediary]
> openstack/tripleo-common [cycle-trailing]
>
> However, I suspect none of those go through the CLI, so they likely
> won't be affected by the proposed change and could still depend on
> > =3.1.1 (therefore avoiding re-releases). Could you have a quick look at
> those and confirm that ?

Thierry, I checked quickly and didn’t find any uses of Mistral CLI in the 
mentioned repos so I think we’re safe.

Renat

__
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][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Renat Akhmerov]

Hi,

We recently sent a patch [1] to release the version 3.1.2 of 
python-mistralclient out of Pike branch. It was done after the date of final 
client library releases so we’d like to discuss if we can allow such an 
exception. All the projects mentioned in the subject may be affected so please 
share if the change is acceptable for you or not. Details are below.

When using Mistral CLI in real deployments we found that some of the list 
commands may be extremely heavy (mostly memory footprint) when called w/o the 
“limit” parameter that constrains the result set by the specified value. For 
example, “mistral execution-list”, “mistral task-list” and “mistral 
action-execution-list”. We saw a number of times that machines went out of 
memory after running such a command, sometimes it was done by mistake by 
operators. So we decided to set a default value for this parameter, which is 
currently 100, to prevent from unintentional execution of such heavy commands. 
The corresponding patch [2] was sent on July 11 and was included in the release 
3.1.1. For “action-execution-list”, before this patch “limit" parameter didn’t 
exist at all so we added it too. However, the change wasn’t made properly so 
that “limit” parameter was just ignored at all times. We fixed that in [3] and 
decided to release 3.1.2.

So long story short, this change will affect your project only if you use 
“mistral action-execution-list” CLI command because now this command will be 
returning by default only 100 entries (to return all “--limit=-1” needs to be 
passed).

We at Nokia need this fix released in Pike because we need to trigger updates 
of RDO packages used in our system.


The question: can we afford to make this release now?

More details on requirements updates etc. you can see in the discussion in [1].

[1] https://review.openstack.org/#/c/491269
[2] https://review.openstack.org/#/c/476110/
[3] https://review.openstack.org/#/c/489217/

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] [ptl][election][mistral] PTL candidacy for Queens

[Renat Akhmerov]

Hi,

I’d like to continue to be the PTL of Mistral project and submitted my 
candidacy.

[1] https://review.openstack.org/#/c/491686/

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] No meeting today - 08/7/2017

[Renat Akhmerov]

Hi,

We decided to cancel today’s Mistral meeting.

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][summit] Mistral sessions submitted for the Sydney summit

[Renat Akhmerov]

Hi,

Here’s the list of talks related to Mistral that we submitted for the summit in 
Sydney:

• What makes Mistral an OpenStack super-star? Right, CloudFlow! - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19109
• Test your Mistral workflows - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19196
• Advanced Fault Management with Vitrage and Mistral - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19508

All of them should be very cool so don’t hesitate to vote for them :)

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] CloudFlow demo available online

[Renat Akhmerov]

Thanks Guy! Great work )

Renat Akhmerov
@Nokia

On 11 Jul 2017, 16:53 +0700, Dougal Matthews <dou...@redhat.com>, wrote:
> Thanks for this - it is really useful to be able to click around and play 
> with the UI - gives me a much better feel for it.
>
>
> > On 11 July 2017 at 08:26, Shaanan, Guy (Nokia - IL/Kfar Sava) 
> > <guy.shaa...@nokia.com> wrote:
> > > CloudFlow (the Mistral Workflow Visualization Tool) demo is now available 
> > > online[1] using a real Mistral Pike instance.
> > >
> > > You can evaluate the tool by selecting one of the pre-existing 
> > > executions, and:
> > >
> > > • See it’s YAML definition,
> > > • Watch the execution information,
> > > • Select a task and watch its properties, results and published values,
> > > • Select a task and see the execution path of that task,
> > > • Delve into a sub-workflow execution,
> > > • and many more…
> > >
> > >
> > > You can download the latest version from our github repo[2] and also 
> > > report bugs and ask for features.
> > >
> > > [1] http://rawgit.com/nokia/CloudFlow/master/docs/index.html
> > > [2] https://github.com/nokia/CloudFlow
> > >
> > > -
> > > Guy Shaanan
> > > CI & Internal Tools
> > > Application & Analytics, Nokia
> > > 16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
> > > T: +972 9 793 3013
> > > M: +972 52 536 2986
> > > 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

Re: [openstack-dev] [heat][ironic][telemetry][dragonflow][freezer][kuryr][manila][mistral][monasca][neutron][ansible][congress][rally][senlin][storlets][zun][docs] repos without signs of migration sta

[Renat Akhmerov]

On 11 Jul 2017, 00:27 +0700, wrote:

> openstack/mistral-dashboard
> openstack/mistral-extra

These two are not supposed to have docs at all. We should probably just remove 
the “doc” folder and corresponding CI jobs.

>  openstack/mistral-lib

This should be taken care of soon.

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] External GUI for Mistral is now at github

[Renat Akhmerov]

Lingxian, good idea. Most likely, we’ll record it and share publicly.

Thanks

Renat Akhmerov
@Nokia

On 4 Jul 2017, 19:21 +0700, Lingxian Kong <anlin.k...@gmail.com>, wrote:
> That's awesome! It'd be better if there is a demo for introduction :-)
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> > On Tue, Jul 4, 2017 at 9:48 PM, Shaanan, Guy (Nokia - IL/Kfar Sava) 
> > <guy.shaa...@nokia.com> wrote:
> > > Hi all,
> > >
> > > We are happy to announce “CloudFlow”- a Mistral Workflow Execution 
> > > Visualization tool, to help you debug and monitor in real time the 
> > > progress of executions.
> > >
> > > CloudFlow offers web based GUI and relies on Mistral REST API.
> > >
> > > CloudFlow source code is publicly available on github[1].
> > >
> > > With this move we can now leverage the project management options in 
> > > Github, like:
> > > * Projects[2] - managing the backlog, todos and in-progress tasks.
> > > * Issues[3] - for opening bugs and feature requests.
> > >
> > > Contributions should be made via a PR and code review, after an 
> > > appropriate task has been added to Projects or a bug has been opened.
> > >
> > > Currently the building and publishing of new versions is done manually 
> > > and will be automated in the future.
> > >
> > >
> > > [1] https://github.com/nokia/CloudFlow
> > > [2] https://github.com/nokia/CloudFlow/projects/1
> > > [3] https://github.com/nokia/CloudFlow/issues
> > >
> > > Thanks,
> > >
> > > -
> > > Guy Shaanan
> > > CI & Internal Tools
> > > Application & Analytics, Nokia
> > > 16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
> > > T: +972 9 793 3013
> > > M: +972 52 536 2986
> > > 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

Re: [openstack-dev] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

Cool, thanks Dougal!

Renat Akhmerov
@Nokia

On 28 Jun 2017, 15:21 +0700, Dougal Matthews <dou...@redhat.com>, wrote:
> > On 23 June 2017 at 12:52, Thierry Carrez <thie...@openstack.org> wrote:
> > > Dougal Matthews wrote:
> > > >>     We have been trying to break the requirement on mistral (from
> > > >>     tripleo-common) but it is proving to be harder than expected. We 
> > > >>are
> > > >>     really doing some nasty things, but I wont go into details here :-)
> > > >>     If anyone is interested, feel free to reach out.
> > > >
> > > > After sending that we did make some solid progress. We are two patches
> > > > away from breaking the link AFAICT.
> > > >
> > > > 1. https://review.openstack.org/#/c/454719/
> > > > 2. https://review.openstack.org/#/c/476866/
> > > >
> > > > Both have some errors that need to be resolved but it is looking much
> > > > closer now.
> > >
> > > That's definitely the best way to handle the situation, so if you are
> > > confident that we can complete the transition to depending on
> > > mistral-lib before the non-client lib freeze (~ July 20), we should try
> > > that.
> >
> > Almost there. All the changes we need have landed in tripleo-common. 
> > Mistral is no longer imported (only mistral-lib is).
> >
> > I have proposed a tripleo-common release [1] and a patch to remove Mistral 
> > from the global requirements [2].
> >
> >
> > [1]: https://review.openstack.org/#/c/478426/
> > [2]: https://review.openstack.org/#/c/477450/
> >
> >
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> > > __
> > > 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] [heat][mistral][deployment] how to add deployment roles

[Renat Akhmerov]

Hi,

Just a small addition. “mistral action-update” applies only to so-called ad-hoc 
actions which are essentially wrappers written in YAML. You can’t update a 
regular action written in Python and plugged in Mistral with stevedore using 
this command.

Renat Akhmerov
@Nokia

On 28 Jun 2017, 08:03 +0700, wrote:
>
> hone
__
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] [ptls][all][tc][docs] Documentation migration spec

[Renat Akhmerov]

I can say for Mistral . We only planned to add Mistral docs to the central repo 
but didn’t do it yet. So, as far as I understand, we don’t need to move 
anything. We’ll review the spec and adjust the folder structure according to 
the proposed.

Thanks

Renat Akhmerov
@Nokia

23 июня 2017 г., 3:32 +0700, Doug Hellmann <d...@doughellmann.com>, писал:
> Excerpts from Alexandra Settle's message of 2017-06-08 15:17:34 +:
> > Hi everyone,
> >
> > Doug and I have written up a spec following on from the conversation [0] 
> > that we had regarding the documentation publishing future.
> >
> > Please take the time out of your day to review the spec as this affects 
> > *everyone*.
> >
> > See: https://review.openstack.org/#/c/472275/
> >
> > I will be PTO from the 9th – 19th of June. If you have any pressing 
> > concerns, please email me and I will get back to you as soon as I can, or, 
> > email Doug Hellmann and hopefully he will be able to assist you.
> >
> > Thanks,
> >
> > Alex
> >
> > [0] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117162.html
>
> Andreas pointed out that the new documentation job will behave a
> little differently from the old setup, and thought I should mention
> it so that people aren't surprised.
>
> The new job is configured to update the docs for all repos every
> time a patch is merged, not just when we tag releases. The server
> projects have been working that way, but this is different for some
> of the libraries, especially the clients.
>
> I will be going back and adding a step to build the docs when we
> tag releases after the move actually starts, so that we can link
> to docs for specific versions of projects. That change will be
> transparent to everyone else, so I have it on the list for after
> the migration is under way.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

We'll do that.

Thanks

Renat Akhmerov
@Nokia

23 июня 2017 г., 18:54 +0700, Thierry Carrez <thie...@openstack.org>, писал:
> Dougal Matthews wrote:
> > > We have been trying to break the requirement on mistral (from
> > > tripleo-common) but it is proving to be harder than expected. We are
> > > really doing some nasty things, but I wont go into details here :-)
> > > If anyone is interested, feel free to reach out.
> >
> > After sending that we did make some solid progress. We are two patches
> > away from breaking the link AFAICT.
> >
> > 1. https://review.openstack.org/#/c/454719/
> > 2. https://review.openstack.org/#/c/476866/
> >
> > Both have some errors that need to be resolved but it is looking much
> > closer now.
>
> That's definitely the best way to handle the situation, so if you are
> confident that we can complete the transition to depending on
> mistral-lib before the non-client lib freeze (~ July 20), we should try
> that.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [oslo.messaging][mistral] For how long is blocking executor deprecated?

[Renat Akhmerov]

Ok, I think I already got my question answered: 
https://docs.openstack.org/releasenotes/oslo.messaging/unreleased.html#deprecation-notes

Thanks

Renat Akhmerov
@Nokia

On 13 Jun 2017, 13:59 +0700, Renat Akhmerov <renat.akhme...@gmail.com>, wrote:
> Hi Oslo team,
>
> Can you please clarify for how long you plan to keep ‘blocking executor’ 
> deprecated before complete removal?
>
> We have to use it in Mistral for the time being. We plan to move away from 
> using it but the transition may take significant time, not this cycle for 
> sure. So we got worried when we heard the news that it’s now been deprecated.
>
>
> 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] [oslo.messaging][mistral] For how long is blocking executor deprecated?

[Renat Akhmerov]

Hi Oslo team,

Can you please clarify for how long you plan to keep ‘blocking executor’ 
deprecated before complete removal?

We have to use it in Mistral for the time being. We plan to move away from 
using it but the transition may take significant time, not this cycle for sure. 
So we got worried when we heard the news that it’s now been deprecated.


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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

We have a weekly meeting next Monday, will it be too late?

Renat Akhmerov
@Nokia

On 1 Jun 2017, 20:10 +0700, Thierry Carrez <thie...@openstack.org>, wrote:
> Note that it's technically too late to change the release model
> (milestone-1 is the deadline), but since that kills two birds with one
> stone, I'd be willing to grant mistral an exception (as long as it's
> done before milestone-2, which is next week).
>
> Renat Akhmerov wrote:
> > Thanks Thierry.
> >
> > To me it sounds like even a better release model for us. We can discuss
> > it with a team at the next team meeting and make a decision.
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 1 Jun 2017, 17:06 +0700, Thierry Carrez <thie...@openstack.org>, wrote:
> > > Renat Akhmerov wrote:
> > > > On 31 May 2017, 15:08 +0700, Thierry Carrez <thie...@openstack.org>,
> > > > wrote:
> > > > > > [mistral]
> > > > > > mistral - blocking sqlalchemy - milestones
> > > > >
> > > > > I wonder why mistral is in requirements. Looks like tripleo-common is
> > > > > depending on it ? Could someone shine some light on this ? It might 
> > > > > just
> > > > > mean mistral-lib is missing a few functions, and switching the release
> > > > > model of mistral itself might be overkill ?
> > > >
> > > > This dependency is currently needed to create custom Mistral actions. It
> > > > was originally not the best architecture and one of the reasons to
> > > > create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
> > > > moving all that’s needed for creating actions into a lib (plus something
> > > > else). The thing is that the transition is not over and APIs that we put
> > > > into ‘mistral-lib’ are still experimental. The plan is to complete this
> > > > initiative, including docs and needed refactoring, till the end of Pike.
> > > >
> > > > What possible negative consequences may we have if we switch release
> > > > model to "cycle-with-intermediary”?
> > >
> > > There are no "negative" consequences. There are just consequences in
> > > choosing a new release model, so I don't want mistral to switch to that
> > > model *only* because it didn't complete moving some code out of mistral
> > > proper into a more consumable mistral-lib. It feels like we wouldn't be
> > > having that discussion if the code was more adequately split :)
> > >
> > > First, the cycle-with-intermediary model means that every tag is a
> > > "release", which is expected to be consumed by users. You have to be
> > > pretty sure that it works -- there won't be any release candidates to
> > > protect you. This means your automated testing coverage needs to be
> > > pretty good.
> > >
> > > Second, the cycle-with-intermediary model is less "driven" by the
> > > release team -- you won't have as many reminders (like milestones), or
> > > best-practice deadlines (like feature freeze) to help you. Your team is
> > > basically doing release management internally, deciding when to release,
> > > when to slow down, etc.
> > >
> > > As such, this model appeals either to very young projects (which need a
> > > lot of flexibility and need to put things out fast), and very mature
> > > projects (where automated testing coverage is pretty complete, release
> > > liaisons take up much of the release management, and things don't change
> > > that often). Projects in the middle usually prefer the
> > > cycle-with-milestones model.
> > >
> > > > Practically, all our releases, even
> > > > those made after milestones, are considered stable and I don’t see
> > > > issues if we’ll be producing full releases every time.
> > >
> > > Yes, it sounds like you could switch to that model without too much pain.
> > >
> > > > Btw, how does
> > > > stable branch maintenance work in this case? I guess it should be the
> > > > same, one stable branch per cycle. I’d appreciate if you could
> > > > clarify this.
> > >
> > > There is no change in terms of stable releases, you still maintain only
> > > one branch per cycle. The last intermediary release in a given cycle is
> > > where the stable branch for the cycle is cut.
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> > > ___

Re: [openstack-dev] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

Thanks Thierry.

To me it sounds like even a better release model for us. We can discuss it with 
a team at the next team meeting and make a decision.

Renat Akhmerov
@Nokia

On 1 Jun 2017, 17:06 +0700, Thierry Carrez <thie...@openstack.org>, wrote:
> Renat Akhmerov wrote:
> > On 31 May 2017, 15:08 +0700, Thierry Carrez <thie...@openstack.org>, wrote:
> > > > [mistral]
> > > > mistral - blocking sqlalchemy - milestones
> > >
> > > I wonder why mistral is in requirements. Looks like tripleo-common is
> > > depending on it ? Could someone shine some light on this ? It might just
> > > mean mistral-lib is missing a few functions, and switching the release
> > > model of mistral itself might be overkill ?
> >
> > This dependency is currently needed to create custom Mistral actions. It
> > was originally not the best architecture and one of the reasons to
> > create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
> > moving all that’s needed for creating actions into a lib (plus something
> > else). The thing is that the transition is not over and APIs that we put
> > into ‘mistral-lib’ are still experimental. The plan is to complete this
> > initiative, including docs and needed refactoring, till the end of Pike.
> >
> > What possible negative consequences may we have if we switch release
> > model to "cycle-with-intermediary”?
>
> There are no "negative" consequences. There are just consequences in
> choosing a new release model, so I don't want mistral to switch to that
> model *only* because it didn't complete moving some code out of mistral
> proper into a more consumable mistral-lib. It feels like we wouldn't be
> having that discussion if the code was more adequately split :)
>
> First, the cycle-with-intermediary model means that every tag is a
> "release", which is expected to be consumed by users. You have to be
> pretty sure that it works -- there won't be any release candidates to
> protect you. This means your automated testing coverage needs to be
> pretty good.
>
> Second, the cycle-with-intermediary model is less "driven" by the
> release team -- you won't have as many reminders (like milestones), or
> best-practice deadlines (like feature freeze) to help you. Your team is
> basically doing release management internally, deciding when to release,
> when to slow down, etc.
>
> As such, this model appeals either to very young projects (which need a
> lot of flexibility and need to put things out fast), and very mature
> projects (where automated testing coverage is pretty complete, release
> liaisons take up much of the release management, and things don't change
> that often). Projects in the middle usually prefer the
> cycle-with-milestones model.
>
> > Practically, all our releases, even
> > those made after milestones, are considered stable and I don’t see
> > issues if we’ll be producing full releases every time.
>
> Yes, it sounds like you could switch to that model without too much pain.
>
> > Btw, how does
> > stable branch maintenance work in this case? I guess it should be the
> > same, one stable branch per cycle. I’d appreciate if you could clarify this.
>
> There is no change in terms of stable releases, you still maintain only
> one branch per cycle. The last intermediary release in a given cycle is
> where the stable branch for the cycle is cut.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Renat Akhmerov]

On 31 May 2017, 15:08 +0700, Thierry Carrez <thie...@openstack.org>, wrote:
>
> > This has hit us with the mistral and tripleo projects particularly
> > (tagged in the title). They disallow pbr-3.0.0 and in the case of
> > mistral sqlalchemy updates.
> >
> > [mistral]
> > mistral - blocking sqlalchemy - milestones
>
> I wonder why mistral is in requirements. Looks like tripleo-common is
> depending on it ? Could someone shine some light on this ? It might just
> mean mistral-lib is missing a few functions, and switching the release
> model of mistral itself might be overkill ?

This dependency is currently needed to create custom Mistral actions. It was 
originally not the best architecture and one of the reasons to create 
'mistral-lib' was in getting rid of dependency on ‘mistral’ by moving all 
that’s needed for creating actions into a lib (plus something else). The thing 
is that the transition is not over and APIs that we put into ‘mistral-lib’ are 
still experimental. The plan is to complete this initiative, including docs and 
needed refactoring, till the end of Pike.

What possible negative consequences may we have if we switch release model to 
"cycle-with-intermediary”? Practically, all our releases, even those made after 
milestones, are considered stable and I don’t see issues if we’ll be producing 
full releases every time. Btw, how does stable branch maintenance work in this 
case? I guess it should be the same, one stable branch per cycle. I’d 
appreciate if you could clarify this.

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][freezer] adopting oslo.context for logging debugging and tracing

[Renat Akhmerov]

Ok, thanks Tuan.

Renat Akhmerov
@Nokia

On 29 May 2017, 17:38 +0700, lương hữu tuấn <tuantulu...@gmail.com>, wrote:
> Hi Renat,
>
> Kong is going to move on with this patch and then i will continue with the 
> main problem of trust token in Mistral.
>
> Br,
>
> Tuan/Nokia
>
> > On Mon, May 29, 2017 at 9:20 AM, Renat Akhmerov <renat.akhme...@gmail.com> 
> > wrote:
> > > Tuan,
> > >
> > > It’s ok, not always people have cycles to finish something upstream. No 
> > > need to explain that. All I’m worried about is getting this thing done. 
> > > So if you don’t have capacity please help transfer this work to someone 
> > > else.
> > >
> > > Thanks
> > >
> > > Renat
> > >
> > > On 29 May 2017, 13:36 +0700, lương hữu tuấn <tuantulu...@gmail.com>, 
> > > wrote:
> > > > Hi Doug and Renat,
> > > >
> > > > I totally agree with what Doug mentioned in the previous mail. In fact, 
> > > > my patch is only the used for the purpose of "implementing trust 
> > > > token", not for full refactoring mistral context. Since i do not have 
> > > > my capacity for contributing to Mistral, my commit now is for the need 
> > > > of Nokia in using token when it is expired.
> > > >
> > > > From very beginning, i would like to refactor mistral context to fully 
> > > > use oslo-context. But if i wanted to refactor the whole mistral 
> > > > context, i would spend my whole capacity for upstream work which is not 
> > > > available for me. By the way, thanks Doug to review it, i know all the 
> > > > issues in your comments but as i said, it was hard for me for upstream 
> > > > work. But i will re-arrange my schedule to finish as Doug commented in 
> > > > the patch as well as switching to oslo-context
> > > >
> > > > @Renat: I will try to refactor the whole mistral context therefore 
> > > > there will not be any roadblocks.
> > > >
> > > > Br,
> > > >
> > > > Tuan
> > > >
> > > > > On Sat, May 27, 2017 at 2:08 AM, Vitaliy Nogin <vno...@mirantis.com> 
> > > > > wrote:
> > > > > > Hi Doug,
> > > > > >
> > > > > > Anyway, thank for the notification. We are really appreciated.
> > > > > >
> > > > > > Regards,
> > > > > > Vitaliy
> > > > > >
> > > > > > > 26 мая 2017 г., в 20:54, Doug Hellmann <d...@doughellmann.com> 
> > > > > > > написал(а):
> > > > > > >
> > > > > > > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100:
> > > > > > >> Hi Doug,
> > > > > > >>
> > > > > > >> Thanks for your review. Actually freezer has a separate repo for 
> > > > > > >> the api,
> > > > > > >> it can be found here [1]. Freezer is using oslo.context since 
> > > > > > >> newton. If
> > > > > > >> you have the time you can take a look at it and let us know if 
> > > > > > >> you have any
> > > > > > >> comments.
> > > > > > >
> > > > > > > Ah, that explains why I couldn't find it in the freezer repo. :-)
> > > > > > >
> > > > > > > Doug
> > > > > > >
> > > > > > >>
> > > > > > >> Thanks for your help
> > > > > > >>
> > > > > > >> [1] https://github.com/openstack/freezer-api
> > > > > > >>
> > > > > > >> Best Regards,
> > > > > > >> Saad!
> > > > > > >>
> > > > > > >> On Fri, May 26, 2017 at 5:45 AM, Renat Akhmerov 
> > > > > > >> <renat.akhme...@gmail.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Thanks Doug. We’ll look into this.
> > > > > > >>>
> > > > > > >>> @Tuan, is there any roadblocks with the patch you’re working 
> > > > > > >>> on? [1]
> > > > > > >>>
> > > > > > >>> [1] https://review.openstac

Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

[Renat Akhmerov]

Tuan,

It’s ok, not always people have cycles to finish something upstream. No need to 
explain that. All I’m worried about is getting this thing done. So if you don’t 
have capacity please help transfer this work to someone else.

Thanks

Renat

On 29 May 2017, 13:36 +0700, lương hữu tuấn <tuantulu...@gmail.com>, wrote:
> Hi Doug and Renat,
>
> I totally agree with what Doug mentioned in the previous mail. In fact, my 
> patch is only the used for the purpose of "implementing trust token", not for 
> full refactoring mistral context. Since i do not have my capacity for 
> contributing to Mistral, my commit now is for the need of Nokia in using 
> token when it is expired.
>
> From very beginning, i would like to refactor mistral context to fully use 
> oslo-context. But if i wanted to refactor the whole mistral context, i would 
> spend my whole capacity for upstream work which is not available for me. By 
> the way, thanks Doug to review it, i know all the issues in your comments but 
> as i said, it was hard for me for upstream work. But i will re-arrange my 
> schedule to finish as Doug commented in the patch as well as switching to 
> oslo-context
>
> @Renat: I will try to refactor the whole mistral context therefore there will 
> not be any roadblocks.
>
> Br,
>
> Tuan
>
> > On Sat, May 27, 2017 at 2:08 AM, Vitaliy Nogin <vno...@mirantis.com> wrote:
> > > Hi Doug,
> > >
> > > Anyway, thank for the notification. We are really appreciated.
> > >
> > > Regards,
> > > Vitaliy
> > >
> > > > 26 мая 2017 г., в 20:54, Doug Hellmann <d...@doughellmann.com> 
> > > > написал(а):
> > > >
> > > > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100:
> > > >> Hi Doug,
> > > >>
> > > >> Thanks for your review. Actually freezer has a separate repo for the 
> > > >> api,
> > > >> it can be found here [1]. Freezer is using oslo.context since newton. 
> > > >> If
> > > >> you have the time you can take a look at it and let us know if you 
> > > >> have any
> > > >> comments.
> > > >
> > > > Ah, that explains why I couldn't find it in the freezer repo. :-)
> > > >
> > > > Doug
> > > >
> > > >>
> > > >> Thanks for your help
> > > >>
> > > >> [1] https://github.com/openstack/freezer-api
> > > >>
> > > >> Best Regards,
> > > >> Saad!
> > > >>
> > > >> On Fri, May 26, 2017 at 5:45 AM, Renat Akhmerov 
> > > >> <renat.akhme...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Thanks Doug. We’ll look into this.
> > > >>>
> > > >>> @Tuan, is there any roadblocks with the patch you’re working on? [1]
> > > >>>
> > > >>> [1] https://review.openstack.org/#/c/455407/
> > > >>>
> > > >>>
> > > >>> Renat
> > > >>>
> > > >>> On 26 May 2017, 01:54 +0700, Doug Hellmann <d...@doughellmann.com>, 
> > > >>> wrote:
> > > >>>
> > > >>> The new work to add the exception information and request ID tracing
> > > >>> depends on using both oslo.context and oslo.log to have all of the
> > > >>> relevant pieces of information available as log messages are emitted.
> > > >>>
> > > >>> In the course of reviewing the "done" status for those initiatives,
> > > >>> I noticed that although mistral and freezer are using oslo.log,
> > > >>> neither uses oslo.context. That means neither project will get the
> > > >>> extra debugging information, and neither project will see the global
> > > >>> request ID in logs.
> > > >>>
> > > >>> I started looking at updating mistral's context to use oslo.context
> > > >>> as a base class, but ran into some issues because of some extensions
> > > >>> made to the existing class. I wasn't able to find where freezer is
> > > >>> doing anything at all with an API request context.
> > > >>>
> > > >>> I'm available to help, if someone else wants to pick up the work.
> > > >>>
> > > >>> Doug
> > > >>>
> > > >>> ___

[openstack-dev] [mistral] No team meeting today - 05/29/2017

[Renat Akhmerov]

Hi,

We’re cancelling today’s meeting since most of the key members can’t attend due 
to holidays in UK and US.

Team, please keep in mind that next week we will release Pike-2. Try to wrap up 
your most important work this week.

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][freezer] adopting oslo.context for logging debugging and tracing

[Renat Akhmerov]

Thanks Doug. We’ll look into this.

@Tuan, is there any roadblocks with the patch you’re working on? [1]

[1] https://review.openstack.org/#/c/455407/


Renat

On 26 May 2017, 01:54 +0700, Doug Hellmann , wrote:
> The new work to add the exception information and request ID tracing
> depends on using both oslo.context and oslo.log to have all of the
> relevant pieces of information available as log messages are emitted.
>
> In the course of reviewing the "done" status for those initiatives,
> I noticed that although mistral and freezer are using oslo.log,
> neither uses oslo.context. That means neither project will get the
> extra debugging information, and neither project will see the global
> request ID in logs.
>
> I started looking at updating mistral's context to use oslo.context
> as a base class, but ran into some issues because of some extensions
> made to the existing class. I wasn't able to find where freezer is
> doing anything at all with an API request context.
>
> I'm available to help, if someone else wants to pick up the work.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack 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][Mistral]A simple tool to discover and manage custom actions

[Renat Akhmerov]

Hi,

I’m joining Lingxian to say thank you for addressing this.

In addition I’d like to say that we have huge plans to rework the entire 
actions subsystem till the end of this year so that implementing and managing 
actions become really easy and enjoying. We’ll definitely look closer at your 
code.

We’d be happy if you joined us at #openstack-mistral IRC channel to discuss 
this and other things.

Thanks

Renat

On 2 May 2017, 19:35 +0700, Lingxian Kong , wrote:
> Hi, int32bit,
>
> First, thanks very much for your work and share with us for what you did.
>
> You are right about the lack of flexibility of current mistral action 
> registration process, in addition to your work, here are some of my 
> suggestions:
>
> - I recommend you work with mistral team to figure out a way to improve 
> current tools/sync_db.py script, add the capability to manipulate actions 
> without reinstall mistral. I believe there are other people who are also very 
> interested in the enhancement.
> - We (mistral team) are working on mistral-lib, a new library that will 
> define a base action class that all 3-rd party customized actions could 
> inherit, which aims to make action developer's life easier.
>
> Thanks again for the email, feel free to jump in #openstack-mistral irc 
> channel for any further discussion.
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> > On Tue, May 2, 2017 at 8:54 PM, int32bit  wrote:
> > > Hi, All,
> > >
> > > As we know, Mistral allow developer  write a new custom action, but must 
> > > reinstall Mistral service if it was installed in our system[1]. I think 
> > > it's hardly acceptable for production environment.
> > >
> > > So I write a CLI tool used for automatically discovering & registering 
> > > custom actions and no need modify any configuration and reinstall any 
> > > service. In fact, it's completely independent with Mistral project.
> > >
> > > In addition, this project provide a CLI to manage custom actions, we can 
> > > list all registered actions, and unregister any action if it doesn't need 
> > > any more.
> > >
> > > For more detail, please see mistral-actions.
> > >
> > > It work well on our environment but not sure if there is any potential 
> > > risk. Thanks for any suggest and comment.
> > >
> > >
> > > [1] 
> > > https://docs.openstack.org/developer/mistral/developer/creating_custom_action.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
__
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] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Renat Akhmerov]

This looks like a simple and elegant way to solve the issue. 100% supported by 
me (and hopefully others).

Thanks for addressing it.

Renat

On 29 Apr 2017, 06:19 +0700, Monty Taylor , wrote:
> On 04/28/2017 06:07 PM, Adrian Turjak wrote:
> >
> > This sounds like a fantastic​ path forward as the version in the service
> > ​ type is a source​ of frustration in some ways. I personally love the
> > version​less discoverability of Keystone as an API model.
>
> ++ ... I'll follow up on Monday with an email about consumption of
> version discovery.
>
> > I'm also assuming this is related to this repo here:
> > https://github.com/openstack/service-types-authority
> >
> > Are there plans to actually fill that repo out and start building the
> > full 'official' catalog of service types? Because right now that repo is
> > missing many services but appears to actually be a good place to list
> > what all the various service types are already in use.
>
> Yes, absolutely. If we can get this particular party moving I'd like to
> use that as a little motivation to chug through and get that repo
> completed. (It's not super hard - but without an answer to what to do
> about the old names, the conversations stall out a bit)
>
> > I know that trying to choose a good new service type for a project is
> > hard because finding a list for the ones already in use isn't that easy.
> > I was sad to find that repo, although ideal, was lacking.
>
> ++ totally agree.
>
> >
> > On 29 Apr. 2017 10:26 am, Monty Taylor  wrote:
> >
> > Hey everybody!
> >
> > Yay! (I'm sure you're all saying this, given the topic. I'll let you
> > collect yourself from your exuberant celebration)
> >
> > == Background ==
> >
> > As I'm sure you all know, we've been trying to make some hearway for a
> > while on getting service-types that are registered in the keystone
> > service catalog to be consistent. The reason for this is so that API
> > Consumers can know how to request a service from the catalog. That
> > might
> > sound like a really easy task - but uh-hoh, you'd be so so wrong. :)
> >
> > The problem is that we have some services that went down the path of
> > suggesting people register a new service in the catalog with a version
> > appended. This pattern was actually started by nova for the v3 api but
> > which we walked back from - with "computev3". The pattern was picked up
> > by at least cinder (volumev2, volumev3) and mistral (workflowv2) that I
> > am aware of. We're also suggesting in the service-types-authority that
> > manila go by "shared-file-system" instead of "share".
> >
> > (Incidentally, this is related to a much larger topic of version
> > discovery, which I will not bore you with in this email, but about
> > which
> > I have a giant pile of words just waiting for you in a little bit. Get
> > excited about that!)
> >
> > == Proposed Solution ==
> >
> > As a follow up to the consuming version discovery spec, which you
> > should
> > absolutely run away from and never read, I wrote these:
> >
> > https://review.openstack.org/#/c/460654/ (Consuming historical aliases)
> > and
> > https://review.openstack.org/#/c/460539/ (Listing historical aliases)
> >
> > It's not a particularly clever proposal - but it breaks down like this:
> >
> > * Make a list of the known historical aliases we're aware of - in a
> > place that isn't just in one of our python libraries (460539)
> > * Write down a process for using them as part of finding a service from
> > the catalog so that there is a clear method that can be implemented by
> > anyone doing libraries or REST interactions. (460654)
> > * Get agreement on that process as the "recommended" way to look up
> > services by service-type in the catalog.
> > * Implement it in the base libraries OpenStack ships.
> > * Contact the authors of as many OpenStack API libraries that we can
> > find.
> > * Add tempest tests to verify the mappings in both directions.
> > * Change things in devstack/deployer guides.
> >
> > The process as described is backwards compatible. That is, once
> > implemented it means that a user can request "volumev2" or
> > "block-storage" with version=2 - and both will return the endpoint the
> > user expects. It also means that we're NOT asking existing clouds to
> > run
> > out and break their users. New cloud deployments can do the new thing -
> > but the old values are handled in both directions.
> >
> > There is a hole, which is that people who are not using the base libs
> > OpenStack ships may find themselves with a new cloud that has a
> > different service-type in the catalog than they have used before. It's
> > not idea, to be sure. BUT - hopefully active outreach to the community
> > libraries coupled with documentation will keep the issues to a minimum.
> >
> > If we can agree on the matching and fallback model, I am
> > volunteering to
> > do the work to implement in every client library in which it needs
> > to be
> > 

Re: [openstack-dev] [Release-job-failures][mistral] Release of openstack/python-mistralclient failed

[Renat Akhmerov]

Ok, thanks Doug.

Renat

On 24 Apr 2017, 22:16 +0700, Doug Hellmann , wrote:
> A recent patch in python-mistralclient added a release note that was
> poorly formatted, so it broke announcement job for the 3.1.0 release.
>
> I've proposed a fix for the note file in
> https://review.openstack.org/459341 and I've proposed the project-config
> changes to add the jobs to avoid allowing similar failures in the future
> in https://review.openstack.org/459343
>
> I also regenerated the announcement email by hand.
>
> Doug
>
> Excerpts from jenkins's message of 2017-04-24 13:41:24 +:
> > Build failed.
> >
> > - python-mistralclient-tarball 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-mistralclient-tarball/e2b9206/
> >  : SUCCESS in 4m 08s
> > - python-mistralclient-tarball-signing 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-mistralclient-tarball-signing/2a5465a/
> >  : SUCCESS in 52s
> > - python-mistralclient-pypi-both-upload 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-mistralclient-pypi-both-upload/551cc60/
> >  : SUCCESS in 26s
> > - python-mistralclient-announce-release 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-mistralclient-announce-release/a578383/
> >  : FAILURE in 3m 12s
> > - propose-python-mistralclient-update-constraints 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/propose-python-mistralclient-update-constraints/d356cb1/
> >  : SUCCESS in 1m 01s
> > - python-mistralclient-docs-tags-only 
> > http://logs.openstack.org/88/888ad722abbd8308da91b15360a2e8d2fb582d65/release/python-mistralclient-docs-tags-only/141c4cb/
> >  : SUCCESS in 4m 04s
> >
>
> __
> 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][tripleo] mistralclient release needed

[Renat Akhmerov]

Hi, it was released as 3.1.0 recently.

Renat

On 24 Apr 2017, 20:14 +0700, Juan Antonio Osorio , wrote:
> Hey,
>
> We're trying to migrate the undercloud to use keystone v3. But we're 
> currently blocked by having an older version of mistralclient available. We 
> would really use a release to move forward.
>
> For reference, this is the commit we need to use in mistralclient 
> https://github.com/openstack/python-mistralclient/commit/83b3d0d39cb8072682fac74f6a40877030e91c18
>
> And this is the commit that's attempting to migrate to keystone v3 in 
> tripleo: https://review.openstack.org/#/c/446752/
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@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] New CI Job definitions

[Renat Akhmerov]

On 19 Apr 2017, 21:37 +0700, Brad P. Crochet <b...@redhat.com>, wrote:

> > On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров <renat.akhme...@gmail.com> 
> > wrote:
> > > Thanks Brad!
> > >
> > > So kombu gate is now non-apache, right?
> > >
> >
> > No. It would be running under mod_wsgi. We can make it non-apache if you 
> > like. Would be pretty easy to do so.

No, that’s fine. Let’s leave it with mod_wsgi as it’s closer to most real 
production environments.

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] Using mistral to start a not-to-die task

[Renat Akhmerov]

Another option:

1. Run a workflow with a loop (i.e. task calls itself), in order to have a 
delay between task executions you can use either wait-before/wait-after task 
policies
2.a The workflow can be stopped via Mistral API by a 3rd party, if needed.
2.b The workflow can have a special task that checks if it still needs to be 
running (i.e. making a request to a 3rd party), it can be done using 
conditional transitions


Renat Akhmerov
@Nokia

> On 23 Mar 2017, at 09:40, Lingxian Kong <anlin.k...@gmail.com> wrote:
> 
> Yeah, as Bob said, cron-trigger is what you are looking for.
> 
> As our discussion on IRC, currently, Mistral doesn't support to execute shell 
> command directly, my suggestion is, you could consider using http action 
> (which is supproted by Mistral out of the box) or providing a host (physical 
> or virtual) to run 'ping' command and use ssh action in Mistral.
> 
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> On Thu, Mar 23, 2017 at 1:16 PM, gongys2017 <gongys2...@aliyun.com 
> <mailto:gongys2...@aliyun.com>> wrote:
> Hi mistral stackers,
> 
> Tacker is using the mistral as its part of system. Now we have a requirement:
> 
> tacker server registers an openstack as its NFVI, and needs to ping http-ping) the openstack's management IP,
> for example the keystone URL until tacker updates or delete the openstack 
> NFVI.
> 
> Can the mistral be asked to start a workflow which  contains  just such a 
> kind of task:
> for ever running until extenal tells him to stop.
> 
> 
> Thanks
> 
> __
> 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 
> <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] Mistral Custom Actions API Design

[Renat Akhmerov]

> On 15 Mar 2017, at 15:32, Adriano Petrich <apetr...@redhat.com> wrote:
> 
>I was talking to some friends that have more (and more recent) experience 
> with standalone zope.interfaces inside other projects (last time I used it 
> was inside zope and 10 years ago) and I think it might be just overcomplexity 
> for our task at hand.

Yes, that’s what I thought too when I read your message. :)

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] Mistral Custom Actions API Design

[Renat Akhmerov]

Well, zope is a cool thing I believe. We can consider to use it. I just don’t 
see what real advantage it’ll give us now.
Essentially, what we’re trying to do now is pretty simple. We’re just defining 
one base class for all actions w/o talking
about various modifications of this class yet.

So if you see a concrete idea about using zope interfaces please share. I’m 
interested in that.

Renat Akhmerov
@Nokia

> On 14 Mar 2017, at 22:14, Adriano Petrich <apetr...@redhat.com> wrote:
> 
> Sorry if I'm missing the point here, and for being late on the discussion. 
> But what about zope interfaces?
> 
> Would not that be clearer?
> 
>  
> 
> On Tue, Mar 14, 2017 at 11:39 AM, Dougal Matthews <dou...@redhat.com 
> <mailto:dou...@redhat.com>> wrote:
> 
> 
> On 14 March 2017 at 11:14, Renat Akhmerov <renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com>> wrote:
> Yeah, I finally understood too what Thomas meant.
> 
> Just to clarify, I think mixed two different discussions here:
> Base framework for all actions residing in mistral-lib (what I was trying to 
> discuss)
> The new design for OpenStack actions
> 
> On #2 I agree with you that NovaAction.get_client(context) should work. No 
> problem with that.
> And I believe that it doesn’t make sense to use multiple inheritance in this 
> particular case, it’s
> simply not worth it.
> 
> Getting back to #1.. Of course, using mixins can be problematic (method and 
> state conflicts etc.).
> I think mixins is just one of the options that’s possible to use if we want 
> to. Regular class inheritance
> is also an option I think. At this point if we just agree on action base 
> class I think nothing prevents
> us from choosing how to evolve in the future. So just agreeing on the base 
> class design seems
> to be sufficient for now. It’s just a base contract that a runner needs to be 
> aware of (sorry for
> repeating this thought but I think it’s important). The rest is related with 
> action developer
> convenience.
> 
>> I think the outstanding questions are;
>> 
>> - should the context be a mixin or should run() always accept context? 
> 
> I’m for run() having “context” argument. Not sure why mixin is needed here. 
> If an action doesn’t
> need context it can be ignored.
> 
>> - should async be a mixin or should we continue with the is_sync() method 
>> and overwriting that in the sublcass?
> 
> I’m for is_sync() method as it is now. It’s more flexible and less confusing 
> (imagine an action inheriting
> AsyncAction but having is_async() returning False).
> 
>> - should the openstack actions in mistral-extra be mixins?
> 
> 
> No, not at all. They don’t have to be. This is a different discussion I 
> think. We need to collect what’s bad about
> the current OpenStack actions and think how to rewrite them (extract the 
> common infrastructure they use,
> make them more extensible, etc.)
> 
> +1 to all of the above, I think we are in complete agreement and this will 
> give us both a flexible interface and one that is easy to use and understand.
> 
>  
> 
> 
> Renat Akhmerov
> @Nokia
> 
> 
> __
> 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 
> <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 
> <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][irc] Mistral team meeting time/channel change

[Renat Akhmerov]

Hi all,The Mistral meeting is now going to be 1 hour earlier at 15:00 UTC on Monday.It will move to #openstack-meeting-3 due to a conflict in the current channel.

This move has been made to make it easier for people after daylight savings kicks in.You can also find a calendar invite in the attachments for your convenience.Thanks!BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
X-WR-CALNAME:Mistral team meeting
METHOD:PUBLISH
PRODID:-//Apple Inc.//Mac OS X 10.12.3//EN
BEGIN:VTIMEZONE
TZID:Asia/Krasnoyarsk
BEGIN:DAYLIGHT
TZOFFSETFROM:+0700
RRULE:FREQ=YEARLY;UNTIL=20100327T19Z;BYMONTH=3;BYDAY=-1SU
DTSTART:19920329T02
TZNAME:GMT+7
TZOFFSETTO:+0800
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0800
DTSTART:20141026T02
TZNAME:GMT+7
TZOFFSETTO:+0700
RDATE:20141026T02
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
TRANSP:OPAQUE
DTEND;TZID=Asia/Krasnoyarsk:20170313T23
LAST-MODIFIED:20170314T112007Z
UID:FC21A357-4BCF-4A91-9AC4-049A1DA887C2
DTSTAMP:20170314T112007Z
LOCATION:#openstack-meeting-3
DESCRIPTION:Weekly IRC meeting to discuss the current Mistral activities
 .
STATUS:CONFIRMED
SEQUENCE:0
SUMMARY:Mistral team meeting
DTSTART;TZID=Asia/Krasnoyarsk:20170313T22
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
CREATED:20160404T151943Z
RRULE:FREQ=WEEKLY;UNTIL=20170505T175959Z
BEGIN:VALARM
X-WR-ALARMUID:5D89139C-4888-42BC-9393-4121A6FAE4C7
UID:5D89139C-4888-42BC-9393-4121A6FAE4C7
TRIGGER:-PT5M
DESCRIPTION:This is an event reminder
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

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] Mistral Custom Actions API Design

[Renat Akhmerov]

Yeah, I finally understood too what Thomas meant.

Just to clarify, I think mixed two different discussions here:
Base framework for all actions residing in mistral-lib (what I was trying to 
discuss)
The new design for OpenStack actions

On #2 I agree with you that NovaAction.get_client(context) should work. No 
problem with that.
And I believe that it doesn’t make sense to use multiple inheritance in this 
particular case, it’s
simply not worth it.

Getting back to #1.. Of course, using mixins can be problematic (method and 
state conflicts etc.).
I think mixins is just one of the options that’s possible to use if we want to. 
Regular class inheritance
is also an option I think. At this point if we just agree on action base class 
I think nothing prevents
us from choosing how to evolve in the future. So just agreeing on the base 
class design seems
to be sufficient for now. It’s just a base contract that a runner needs to be 
aware of (sorry for
repeating this thought but I think it’s important). The rest is related with 
action developer
convenience.

> I think the outstanding questions are;
> 
> - should the context be a mixin or should run() always accept context? 

I’m for run() having “context” argument. Not sure why mixin is needed here. If 
an action doesn’t
need context it can be ignored.

> - should async be a mixin or should we continue with the is_sync() method and 
> overwriting that in the sublcass?

I’m for is_sync() method as it is now. It’s more flexible and less confusing 
(imagine an action inheriting
AsyncAction but having is_async() returning False).

> - should the openstack actions in mistral-extra be mixins?


No, not at all. They don’t have to be. This is a different discussion I think. 
We need to collect what’s bad about
the current OpenStack actions and think how to rewrite them (extract the common 
infrastructure they use,
make them more extensible, etc.)


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] Mistral Custom Actions API Design

[Renat Akhmerov]

So again, I’m for simplicity but that kind of simplicity that also allows 
flexibility in the future.

There’s one principle that I usually follow in programming that says:

“Space around code (absence of code) has more potential than the code itself.”

That means that it’s better to get rid of any stuff that’s not currently needed 
and add things
as requirements change. However, that doesn’t always work well in framework 
development
because the cost of initial inflexibility may become too high in future, that 
comes from the
need to stay backwards compatible. What I’m trying to say is that IMO it’s ok 
just to keep
it as simple as just a base class with method run() for now and think how we 
can add more
things in the future, if we need to, using mixin approach. So seems like it’s 
going to be:

class Action(object):

  def run(ctx):
…


class Mixin1(object):
  
  def method11():
…

  def method12():
…


class Mixin2(object):
  
  def method21():
…

  def method22():
…


Then my concrete action could use a combination of Action and any of the mixin:

class MyAction(Action, Mixin1):
  …


class MyAction(Action, Mixin2):
  …

or just


class MyAction(Action):
  …

Is this flexible enough or does it have any potential issues?

IMO, base class is still needed to define the contract that all actions should 
follow. So that
a runner knew what’s possible to do with actions.

Renat Akhmerov
@Nokia

> On 13 Mar 2017, at 16:49, lương hữu tuấn <tuantulu...@gmail.com> wrote:
> 
> 
> 
> On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve <the...@redhat.com 
> <mailto:the...@redhat.com>> wrote:
> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady <rbr...@redhat.com 
> <mailto:rbr...@redhat.com>> wrote:
> >
> > One of the pain points for me as an action developer is the OpenStack
> > actions[1].  Since they all use the same method name to retrieve the
> > underlying client, you cannot simply inherit from more than one so you are
> > forced to rewrite the client access methods.  We saw this in creating
> > actions for TripleO[2].  In the base action in TripleO, we have actions that
> > make calls to more than one OpenStack client and so we end up re-writing and
> > maintaining code.  IMO the idea of using multiple inheritance there would be
> > helpful.  It may not require the mixin approach here, but rather a design
> > change in the generator to ensure the method names don't match.
> 
> Is there any reason why those methods aren't functions? AFAICT they
> don't use the instance, they could live top level in the action module
> and be accessible by all actions. If you can avoid multiple
> inheritance (or inheritance!) you'll simplify the design. You could
> also do client = NovaAction().get_client() in your own action (if
> get_client was a public method).
> 
> --
> Thomas
> 
> If you want to do that, you need to change the whole structure of base action 
> and the whole way of creating an action
> as you have described and IMHO, i myself do not like this idea:
> 
> 1. Mistral is working well (at the standpoint of creating action) and 
> changing it is not a short term work.
> 2. Using base class to create base action is actually a good idea in order to 
> control and make easy to action developers. 
> The base class will define the whole mechanism to execute an action, 
> developers do not need to take care of it, just only
> providing OpenStack clients (the _create_client() method).
> 3. From the #2 point of view, the alternative to NovaAction().get_client() 
> does not make sense since the problem here is subclass mechanism,
> not the way to call get_client().
> 
> @Renat: I myself not against to multiple inheritance too, the only thing is 
> if we want to make it multiple inheritance, we should think about it more 
> thoroughly for the hierarchy of inheritance, what each inheritance layer 
> does, etc. These work will make the multiple inheritance easy to understand 
> and for action developers as well easy to develop. So, IMHO, i vote for make 
> it simple, easy to understand first (if you continue with mistral-lib) and 
> then do the next thing later.
> 
> Br,
> 
> Tuan/Nokia
> __
> 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 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> U

Re: [openstack-dev] [mistral] Mistral Custom Actions API Design

[Renat Akhmerov]

> One of the pain points for me as an action developer is the OpenStack 
> actions[1].  Since they all use the same method name to retrieve the 
> underlying client, you cannot simply inherit from more than one so you are 
> forced to rewrite the client access methods.  We saw this in creating actions 
> for TripleO[2].  In the base action in TripleO, we have actions that make 
> calls to more than one OpenStack client and so we end up re-writing and 
> maintaining code.  IMO the idea of using multiple inheritance there would be 
> helpful.  It may not require the mixin approach here, but rather a design 
> change in the generator to ensure the method names don't match.
> 
> [1] 
> https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/actions.py
>  
> <https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/actions.py>
> [2] 
> https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L27
>  
> <https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L27>

I think I’m ok with multiple inheritance if we have a good reason. The question 
is: do we need to have some multiple inheritance in base classes? What you’re 
saying about OpenStack actions just looks like a slightly different discussion 
because they’ve never meant to be base classes, they were not designed with 
this goal in mind. Now, when we’re refactoring the whole subsystem and also 
OpenStack actions we need to revisit their design and think how to make it more 
flexible.

My suggestion here is to move iteratively. I am personally not going to be too 
opinionated about different ideas you’re suggesting. I’d rather merge the one 
that seems the best then reevaluate, change it etc. While mistral-lib is 
considered experimental we can try different options.

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] Mistral Custom Actions API Design

[Renat Akhmerov]

> On 10 Mar 2017, at 15:09, Dougal Matthews <dou...@redhat.com> wrote:
> 
> On 10 March 2017 at 04:22, Renat Akhmerov <renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com>> wrote:
> Hi,
> 
> I probably like the base class approach better too.
> 
> However, I’m trying to understand if we need this variety of classes.
> Do we need a separate class for asynchronous actions? IMO, since is_sync() is 
> just an instance method that can potentially return both True and False based 
> on the instance state shouldn’t be introduced by a special class. Otherwise 
> it’s confusing that a classes declared as AsyncAction can actually be 
> synchronous (if its is_sync() returns True). So maybe we should just leave 
> this method in the base class.
> I”m also wondering if we should just always pass “context” into run() method. 
> Those action implementations that don’t need it could just ignore it. Not 
> sure though.
> This is a good point. I had originally thought it would be backwards 
> incompatible to make this change - however, users will need to update their 
> actions to inherit from mistral-lib so they will need to opt in. Then in 
> mistral we can do something like...
> 
> if isinstance(action, mistral_lib.Action):
> action.run(ctx)
> else:
> # deprecation warning about action now inheriting from mistral_lib and 
> taking a context etc.
> action.run()

Yes, right.

> As far as mixin approach, I’d say I’d be ok with having mixing for 
> context-based actions. Although, like Dougal said, it may be a little harder 
> to read, this approach gives a huge flexibility for long term. Imagine if we 
> want to have a class of actions that some different kind of information. Just 
> making it up… For example, some of my actions need to be aware of some 
> policies (Congress-like) or information about metrics of the current 
> operating system (this is probably a bad example because it’s easy to use 
> standard Python modules but I’m just trying to illustrate the idea). In this 
> case we could have PolicyMixin and OperatingSystemMixin that would set 
> required info into the instance state or provide with handle interfaces for 
> more advanced uses.
> 
> I like the idea of mixins if we can see a future with many small components 
> that can be included in an action class. However, like you I didn't manage to 
> think of any real examples.
> 
> It should be possible to migrate to a mixin approach later if we have the 
> need.


Well, I didn’t manage to find real use cases probably because I don’t develop 
lots of actions :) Although the example with policies seems almost real to me. 
This is something that was raised several times during design sessions in the 
past. Anyway, I agree with you that seems like we can add mixins later if we 
want to. I don’t see any reasons now why not.


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][ptg] Following up on Pike PTG sessions

[Renat Akhmerov]

Hi,

Below is the list of blueprints and bugs updated after the PTG discussions. The 
etherpad containing all sessions’ info and notes is at [1].

Scalability, Fault Tolerance and HA
https://blueprints.launchpad.net/mistral/+spec/mistral-ha-gate 
<https://blueprints.launchpad.net/mistral/+spec/mistral-ha-gate>
https://blueprints.launchpad.net/mistral/+spec/mistral-multinode-tests 
<https://blueprints.launchpad.net/mistral/+spec/mistral-multinode-tests>
https://blueprints.launchpad.net/mistral/+spec/mistral-fault-tolerance 
<https://blueprints.launchpad.net/mistral/+spec/mistral-fault-tolerance>
Running actions by engine
https://blueprints.launchpad.net/mistral/+spec/mistral-actions-run-by-engine 
<https://blueprints.launchpad.net/mistral/+spec/mistral-actions-run-by-engine> 
Actions API
https://blueprints.launchpad.net/mistral/+spec/mistral-custom-actions-api 
<https://blueprints.launchpad.net/mistral/+spec/mistral-custom-actions-api>
Workflow error analysis
https://blueprints.launchpad.net/mistral/+spec/mistral-error-analysis 
<https://blueprints.launchpad.net/mistral/+spec/mistral-error-analysis>
Mistral/Glare integration
https://blueprints.launchpad.net/mistral/+spec/mistral-glare-actions 
<https://blueprints.launchpad.net/mistral/+spec/mistral-glare-actions>
https://blueprints.launchpad.net/mistral/+spec/mistral-glare-resources 
<https://blueprints.launchpad.net/mistral/+spec/mistral-glare-resources>
Working with sensitive data
https://bugs.launchpad.net/mistral/+bug/1337268 
<https://bugs.launchpad.net/mistral/+bug/1337268>
Dynamic actions
https://blueprints.launchpad.net/mistral/+spec/mistral-dynamic-actions 
<https://blueprints.launchpad.net/mistral/+spec/mistral-dynamic-actions>
Task explicit parameters
https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters 
<https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters>


I’d like to ask the team to review these LP tickets, at least those you’re 
interested in.
At the next weekly meeting we’ll go over these items and 
prioritize/scope/assign them.
I would also like to reevaluate priorities of other tasks that are now formally 
scoped for
Pike cycle. The expected result is to build a roadmap for Pike next week.


[1]  https://etherpad.openstack.org/p/mistral-ptg-pike 
<https://etherpad.openstack.org/p/mistral-ptg-pike>

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] [tc][appcat] The future of the App Catalog

[Renat Akhmerov]

> On 10 Mar 2017, at 06:02, Zane Bitter <zbit...@redhat.com> wrote:
> 
> On 08/03/17 11:23, David Moreau Simard wrote:
>> The App Catalog, to me, sounds sort of like a weird message that
>> OpenStack somehow requires applications to be
>> packaged/installed/deployed differently.
>> If anything, perhaps we should spend more effort on advertising that
>> OpenStack provides bare metal or virtual compute resources and that
>> apps will work just like any other places.
> 
> Look, it's true that legacy apps from the 90s will run on any VM you can give 
> them. But the rest of the world has spent the last 15 years moving on from 
> that. Applications of the future, and increasingly the present, span multiple 
> VMs/containers, make use of services provided by the cloud, and interact with 
> their own infrastructure. And users absolutely will need ways of packaging 
> and deploying them that work with the underlying infrastructure. Even those 
> apps from the 90s should be taking advantage of things like e.g. Neutron 
> security groups, configuration of which is and will always be out of scope 
> for Docker Hub images.
> 
> So no, we should NOT spend more effort on advertising that we aim to become 
> to cloud what Subversion is to version control. We've done far too much of 
> that already IMHO.

100% agree with that.

And this whole discussion is taking me to the question: is there really any 
officially accepted strategy for OpenStack for 1, 3, 5 years? Is there any 
ultimate community goal we’re moving to regardless of underlying technologies 
(containers, virtualization etc.)? I know we’re now considering various 
community goals like transition to Python 3.5 etc. but these goals don’t tell 
anything about our future as an IT ecosystem from user perspective. I may 
assume that I’m just not aware of it. I’d be glad if it was true. I’m eager to 
know the answers for these questions. Overall, to me it feels like every 
company in the community just tries to pursue its own short-term (in the best 
case mid-term) goals without really caring about long-term common goals. So if 
we say OpenStack is a car then it seems like the wheels of this car are moving 
in different directions. Again, I’d be glad if it wasn’t true. So maybe some 
governance needed around setting and achieving ultimate goals of OpenStack? Or 
if they already exist we need to better explain them and advertise publicly? 
That in turn IMO could attract more businesses and contributors.

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] Mistral Custom Actions API Design

[Renat Akhmerov]

Hi,

I probably like the base class approach better too.

However, I’m trying to understand if we need this variety of classes.
Do we need a separate class for asynchronous actions? IMO, since is_sync() is 
just an instance method that can potentially return both True and False based 
on the instance state shouldn’t be introduced by a special class. Otherwise 
it’s confusing that a classes declared as AsyncAction can actually be 
synchronous (if its is_sync() returns True). So maybe we should just leave this 
method in the base class.
I”m also wondering if we should just always pass “context” into run() method. 
Those action implementations that don’t need it could just ignore it. Not sure 
though.

As far as mixin approach, I’d say I’d be ok with having mixing for 
context-based actions. Although, like Dougal said, it may be a little harder to 
read, this approach gives a huge flexibility for long term. Imagine if we want 
to have a class of actions that some different kind of information. Just making 
it up… For example, some of my actions need to be aware of some policies 
(Congress-like) or information about metrics of the current operating system 
(this is probably a bad example because it’s easy to use standard Python 
modules but I’m just trying to illustrate the idea). In this case we could have 
PolicyMixin and OperatingSystemMixin that would set required info into the 
instance state or provide with handle interfaces for more advanced uses.

What do you think?

Renat Akhmerov
@Nokia

> On 9 Mar 2017, at 11:35, Ryan Brady <rbr...@redhat.com> wrote:
> 
> At the PTG and previous discussions in IRC, I mentioned there were two 
> different design ideas I had for the developer experience for custom action 
> development in mistral-lib.  The purpose and intent behind the patch[1] was 
> discussed in person at the PTG and that was helpful for me wrt to scope.  I 
> feel it would be helpful to discuss and decide together the final piece of 
> this patch.  I'd like to get any feedback on either of these two ideas as 
> they will shape how developers integrate with Mistral in the future, impact 
> our OpenStack integration efforts in mistral-extra.  Nothing stops a 
> developer from adopting either style in their custom action libraries, but 
> most will likely want to remain consistent with style present in the upstream 
> code.
> 
> I have created separate declaration and usage examples in hopes of 
> illustrating some of the similarities and differences.  To me it seems the 
> base class example is more declarative/explicit, but the mixin example is 
> more extensible and dry.  Both examples reflect on backwards compatibility 
> and possible changes to how mistral checks for sync/async actions and how to 
> pass the context (as needed by actions that integrate with OpenStack).
> 
> 
> base classes declaration: 
> https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09 
> <https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09>
> 
> base class usage: 
> https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6 
> <https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6>
> 
> mixins declaration: 
> https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678 
> <https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678>
> 
> mixins usage: https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e 
> <https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e>
> 
> 
> Thanks,
> 
> Ryan
> 
> -- 
> Ryan Brady
> Cloud Engineering
> rbr...@redhat.com <mailto:rbr...@redhat.com> 
> 919.890.8925
> 
> 
> [1] https://review.openstack.org/#/c/411412/ 
> <https://review.openstack.org/#/c/411412/>
> __
> 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][cinder][keystone] Fixing Mistral & Cinder service type in the catalog

[Renat Akhmerov]

Hi,

There was a patch recently merged ([1]) that works around a bad decision that 
Cinder and Mistral team
(possible someone else too) to include api version in the name of service type 
in the catalog. For
example, for Mistral it was initially “workflow” when we were working on a POC 
of the project but once
we realized that we created a stable API we called it “v2” and changed service 
type to “workflowv2”.
Now we see it was a bad thing to do (see details in the patch).

I wonder if we can do something to get this fixed in long term. Ideally, i’d 
like to make it just “workflow”
again but that seems to be not easy now.

Would appreciate your input.

[1] https://review.openstack.org/#/c/434344/ 
<https://review.openstack.org/#/c/434344/>


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] Proposing Michal Gershenzon to the core team

[Renat Akhmerov]

Thank you guys!

Michal, you’re now included to the core team.

Renat Akhmerov
@Nokia

> On 2 Mar 2017, at 03:50, Lingxian Kong <anlin.k...@gmail.com> wrote:
> 
> +1, she indeed has been doing great contribution to Mistral, welcome, Michal 
> :-)
> 
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> On Thu, Mar 2, 2017 at 5:47 AM, Renat Akhmerov <renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com>> wrote:
> Hi,
> 
> Based on the stats of Michal Gershenzon in Ocata cycle I’d like to promote 
> her to the core team.
> Michal works at Nokia CloudBand and being a CloudBand engineer she knows 
> Mistral very well
> as a user and behind the scenes helped find a lot of bugs and make countless 
> number of
> improvements, especially in performance.
> 
> Overall, she is a deep thinker, cares about details, always has an unusual 
> angle of view on any
> technical problem. She is one of a few people that I’m aware of who I could 
> call a Mistral expert.
> She also participates in almost every community meeting in IRC.
> 
> In Ocata she improved her statistics pretty significantly (e.g. ~60 reviews 
> although the cycle was
> very short) and is keeping up the good pace now. Also, Michal is officially 
> planning to allocate
> more time for upstream development in Pike
> 
> I believe Michal would be a great addition for the Mistral core team.
> 
> Please let me know if you agree with that.
> 
> Thanks
> 
> [1] 
> http://stackalytics.com/?module=mistral-group=ocata_id=michal-gershenzon
>  
> <http://stackalytics.com/?module=mistral-group=ocata_id=michal-gershenzon>
> 
> Renat Akhmerov
> @Nokia
> 
> 
> __
> 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 
> <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] Proposing Michal Gershenzon to the core team

[Renat Akhmerov]

Hi,

Based on the stats of Michal Gershenzon in Ocata cycle I’d like to promote her 
to the core team.
Michal works at Nokia CloudBand and being a CloudBand engineer she knows 
Mistral very well
as a user and behind the scenes helped find a lot of bugs and make countless 
number of
improvements, especially in performance.

Overall, she is a deep thinker, cares about details, always has an unusual 
angle of view on any
technical problem. She is one of a few people that I’m aware of who I could 
call a Mistral expert.
She also participates in almost every community meeting in IRC.

In Ocata she improved her statistics pretty significantly (e.g. ~60 reviews 
although the cycle was
very short) and is keeping up the good pace now. Also, Michal is officially 
planning to allocate
more time for upstream development in Pike

I believe Michal would be a great addition for the Mistral core team.

Please let me know if you agree with that.

Thanks

[1] 
http://stackalytics.com/?module=mistral-group=ocata_id=michal-gershenzon
 
<http://stackalytics.com/?module=mistral-group=ocata_id=michal-gershenzon>

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][ptg] Mistral sessions started in Atlanta 4; Level 1

[Renat Akhmerov]

Hi,

We just started our Mistral sessions, everybody is welcome to participate!

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] [heat][tripleo][mistral][all]PTG: Cross-Project: OpenStack Orchestration Integration

[Renat Akhmerov]

Ok, thanks.

Renat Akhmerov
@Nokia

> On 21 Feb 2017, at 09:17, Rico Lin <rico.lin.gua...@gmail.com> wrote:
> 
> Dear all
> Just reminding the Cross-Project session: OpenStack Orchestration Integration
> Will take place at 11:00 on Thursday in `Macon` room.
> 
> 2017-02-14 21:49 GMT+08:00 John Fulton <ful...@redhat.com 
> <mailto:ful...@redhat.com>>:
> Thanks Rico and Renat. This applies to two specs [1][2] I'm involved in so 
> I'll be sure to be there. --John
> 
> [1] https://review.openstack.org/#/c/387631/ 
> <https://review.openstack.org/#/c/387631/>
> [2] https://review.openstack.org/#/c/423304/ 
> <https://review.openstack.org/#/c/423304/>
> 
> 
> - Original Message -
> From: "Renat Akhmerov" <renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com>>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Sent: Tuesday, February 14, 2017 12:59:09 AM
> Subject: [openstack-dev] [heat][tripleo][mistral][all]PTG: Cross-Project: 
> OpenStack Orchestration Integration
> 
> Ok, thanks Rico. Keep us updated on the schedule changes. I’m currently 
> finalizing the schedule for Mistral, for now I’ll leave Thursday 11.00-12.00 
> blank.
> 
> Renat Akhmerov
> @Nokia
> 
> 
> 
> 
> On 14 Feb 2017, at 10:49, Rico Lin < rico.lin.gua...@gmail.com 
> <mailto:rico.lin.gua...@gmail.com> > wrote:
> 
> Let's move the schedule toThursday morning 11:00 am to 12:00 pm in the same 
> room. Hope that schedule work for all:)
> 
> Also, I will ask if Mon - Tue is available or not, but there might be more 
> cross-project sessions we have to not to conflict with them.
> 
> 2017-02-14 10:02 GMT+08:00 Renat Akhmerov < renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com> > :
> 
> 
> 
> 
> 
> 
> On 13 Feb 2017, at 19:30, Emilien Macchi < emil...@redhat.com 
> <mailto:emil...@redhat.com> > wrote:
> 
> 
> 
> On Mon, Feb 13, 2017 at 4:48 AM, Rico Lin < rico.lin.gua...@gmail.com 
> <mailto:rico.lin.gua...@gmail.com> > wrote:
> 
> 
> 
> Dear all
> 
> PTG is approaching, we have few ideas around TripleO team ([1] and [2]) about 
> use case like using Mistral through Heat. It seems some great OpenStacker 
> already start thing about how the Orchestration services (Heat, Mistral, and 
> some other projects) could use together for a better developer or operator 
> experiences. First, of curse,
> we will arrange a fishbowl design session on Wednesday morning.
> Let's settle with 10:00 am to 10:50 am at Macon (on level2) for now.
> Could teams kindly help to make sure they can attend this cross project 
> session or need it reschedule?
> 
> Can we reschedule it? It seems like the only slot where we have sessions 
> organized is on Wednesday morning, for our container work:
> https://etherpad.openstack.org/p/tripleo-ptg-pike 
> <https://etherpad.openstack.org/p/tripleo-ptg-pike>
> 
> Wednesday 9:00 Cross-Teams talk about containers and networking
> Wednesday 10:00: TripleO Containers status update and path forward
> 
> So I suggest Wednesday afternoon or Thursday or Friday morning. At your 
> convenience.
> 
> Thursday morning would work for me.
> 
> Renat Akhmerov
> @Nokia
> 
> 
> __
> 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 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> --
> May The Force of Open Stack Be With You,
> Rico Lin
> irc: ricolin
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> <mailto: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.or