Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core team
+1 from my side! On Tue, Nov 8, 2016 at 11:34 AM, Gershenzon, Michal (Nokia - IL) < michal.gershen...@nokia.com> wrote: > +1 > > J > > > > Michal Gershenzon > Software Engineer, CloudBand > Application & Analytics , Nokia > Contact number: +972 9 793 3163 > > > > *From:* Deja, Dawid [mailto:dawid.d...@intel.com] > *Sent:* Tuesday, November 08, 2016 10:21 AM > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the > core team > > > > +1 > > > > It's good to have you on board Dougal! > > > > Dawid Deja > > > > On Tue, 2016-11-08 at 19:46 +1300, Lingxian Kong wrote: > > +1 of course! > > > > Cheers, > Lingxian Kong (Larry) > > > > On Tue, Nov 8, 2016 at 6:09 PM, Renat Akhmerov <renat.akhme...@gmail.com> > wrote: > > Hi, > > > > I’d like to promote Dougal Matthews to the Mistral core team. [1] shows > Dougal’s Mistral contribution summary for Newton cycle. > > > > Here are the reasons why I would like to see Dougal in the core team: > >- He reviews a lot and provides valuable comments, especially when it >comes to discussing design of the new features >- He sent 18 patches in Newton cycle which may not be a big number but >it was his first full cycle in Mistral and I believe he can do more >- He is one of the most active team members in general and in IRC >specifically, always open for communication and easy to talk to >- He is an active user of Mistral which is very important for me since >he’s capable of providing valuable practical feedback on design, usability, >reliability etc. >- He seems to be very excited about working on Mistral > > > > Besides that I believe Dougal makes a good friendly atmosphere in our > development team daily in our IRC channel and our weekly IRC meetings. > > > > Team, I would ask you to support me in this promotion. > > > > Thanks > > > > [1] http://stackalytics.com/?module=mistral-group_id= > d0ugal=newton=marks > > > > 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 > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] [mistal] Mistral logo ideas?
I like the idea with octopus. Creature with lots of leg is associated with graph for me, thus I would like to propose one more idea for mascot, it is a spider with a web (something like this) <http://www.clipartbest.com/cliparts/KTj/ozx/KTjozxggc.png>. What do you think? On Fri, Jul 29, 2016 at 12:21 PM, Elisha, Moshe (Nokia - IL) < moshe.eli...@nokia.com> wrote: > Octopus sounds good to me. > For me it somehow relates to Mistral as well – like concurrent tasks… > > From: Renat Akhmerov <renat.akhme...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, 19 July 2016 at 07:36 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [mistal] Mistral logo ideas? > > > > On 18 Jul 2016, at 19:54, Ryan Brady <rbr...@redhat.com> wrote: > > On Mon, Jul 18, 2016 at 12:44 AM, Renat Akhmerov <renat.akhme...@gmail.com > > wrote: > >> On choosing a mascot for Mistral. Let’s choose one till next Monday. >> >> To start this discussion I’d like to propose a couple of ideas: >> >> >>- *Octopus* (kind of symbolic to me). How do you like this beauty? >>http://nashaplaneta.su/_bl/158/78285238.jpg >> >> > +1. Intelligence, dexterity, tool-use - many good qualitites to > associate with. > > > Yep :) > > > 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 > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Promoting Dawid Deja to core reviewers
Renat, I fully support Dawid's promotion! Here is my +1 for Dawid. Dawid, I will be glad to see you in the Mistral core team. On Fri, Jul 29, 2016 at 2:39 PM, Renat Akhmerov <renat.akhme...@gmail.com> wrote: > Hi, > > I’d like to promote Dawid Deja working at Intel (ddeja in IRC) to Mistral > core reviewers. > > The reasons why I want to see Dawid in the core team is that he provides > amazing, very thorough reviews. > Just by looking at a few of them I was able to make a conclusion that he > knows the system architecture very well > although he started contributing actively not so long ago. He always sees > things deeply, can examine a problem > from different angles, demonstrates solid technical background in general. > He is in top 5 reviewers now by a number > of reviews and the only one who still doesn’t have core status. He also > implemented several very important changes > during Newton cycle. Some of them were in progress for more than a year > (flexible RPC) but Dawid helped to knock > them down elegantly. > > Besides purely professional skills that I just mentioned I also want to > say that it’s a great pleasure to work with > Dawid. He’s a bright cheerful guy and a good team player. > > Dawid’s statistics is here: > http://stackalytics.com/?module=mistral-group=commits_id=dawid-deja-0 > > > I’m hoping for your support in making this promotion. > > 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 > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Promoting Hardik Parekh to core reviewers
I fully support this idea! It is my +1 for Hardik . On Tue, May 10, 2016 at 11:49 AM, Renat Akhmerov <renat.akhme...@gmail.com> wrote: > I’d like to promote Hardik Parekh to Mistral core reviewers. > > He was #1 by number of commits and #3 by number of reviews in Mitaka cycle > and I think he deserved it. His statistics for Mitaka is at [1]. > > Please vote. > > [1] > http://stackalytics.com/?release=mitaka=mistral-group=marks_id=hardik-parekh047 > > 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 > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers
Thanks ! I will do my best for further development of the project and will try to bring more quality in Mistral. On Tue, Feb 2, 2016 at 8:13 AM, Renat Akhmerov <rakhme...@mirantis.com> wrote: > Alright, I think we all agree on that. Anastasia, welcome to the core team! > > Renat Akhmerov > @ Mirantis Inc. > > > > On 01 Feb 2016, at 14:50, Hardik Parekh <hardik.parekh...@gmail.com> > wrote: > > I'm not a core reviewer, but if I was, I'd definitely vote with +1. > > Great job, Anastasia! > > On Mon, Feb 1, 2016 at 4:45 PM, Nikolay Makhotkin <nmakhot...@mirantis.com > > wrote: > >> Hi, great work, Anastasia! >> >> +1 for you! >> >> On Fri, Jan 29, 2016 at 11:27 AM, Lingxian Kong <anlin.k...@gmail.com> >> wrote: >> >>> +1 from me, welcome Anastasia! >>> >>> On Fri, Jan 29, 2016 at 9:00 PM, Igor Marnat <imar...@mirantis.com> >>> wrote: >>> >>>> Folks, >>>> I'm not a core reviewer, but if I was, I'd definitely vote with +1. >>>> >>>> Good job, Anastasia! Keep going! >>>> >>>> Regards, >>>> Igor Marnat >>>> >>>> On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) < >>>> moshe.eli...@nokia.com> wrote: >>>> >>>>> A very big +1 >>>>> ____ >>>>> From: Renat Akhmerov [rakhme...@mirantis.com] >>>>> Sent: Friday, January 29, 2016 8:13 AM >>>>> To: OpenStack Development Mailing List (not for usage questions) >>>>> Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to >>>>> core reviewers >>>>> >>>>> Team, >>>>> >>>>> I’d like to promote Anastasia Kuznetsova to the core team. What she’s >>>>> been doing for 2 years is hard to overestimate. She’s done a huge amount >>>>> of >>>>> work reviewing code, bugfixing and participating in public discussions >>>>> including our IRC channel #openstack-mistral. She is very reliable, >>>>> diligent and consistent about her work. >>>>> >>>>> Please vote. >>>>> >>>>> Renat Akhmerov >>>>> @ Mirantis Inc. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> __ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> __ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> >>>> >>>> __ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> *Regards!* >>> *---* >>> *Lingxian Kong* >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> Best Regards, >> Nikolay >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Team meeting minutes/log - 02/01/2016
Thanks everyone for very productive meeting. We formed scope for M-3, link to the list of bps: https://launchpad.net/mistral/+milestone/mitaka-3 Meeting minutes and log: - http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-02-01-16.06.html - http://eavesdrop.openstack.org/meetings/mistral/2016/mistral.2016-02-01-16.06.log.html -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Improving Mistral pep8 rules files to match Mistral guidelines
Renat, Yes, I have created blueprint, here is a link [1] . In this bp you can find link to the etherpad where I described a couple of rules that came to my mind. [1] https://blueprints.launchpad.net/mistral/+spec/add-custom-code-style-checks On Thu, Dec 24, 2015 at 10:59 AM, Renat Akhmerov <rakhme...@mirantis.com> wrote: > I’m the one who has been enforcing those style things from the beginning > so let me take this and describe these rules in details. > > Anastasia, have you already created a BP? > > Renat Akhmerov > @ Mirantis Inc. > > > > On 10 Dec 2015, at 20:05, Anastasia Kuznetsova <akuznets...@mirantis.com> > wrote: > > Moshe, > > I will create blueprint for that and will attach link to etherpad, so we > can form list of the rules all together. > After that it will be possible to publish all our 'rules' to docs and > start their implementation. > > On Thu, Dec 10, 2015 at 11:23 AM, ELISHA, Moshe (Moshe) < > moshe.eli...@alcatel-lucent.com> wrote: > >> Thanks, Anastasia! >> >> >> >> Who can take start documenting the rules? I remember only a few rules and >> I don’t know all the nuances. >> >> For example, if the return statement is the only statement of a function >> – do you still need a blank line before it? >> >> >> >> Once the rules doc will be available I can work on adding these rules to >> our pep8. >> >> >> >> >> >> *From:* Anastasia Kuznetsova [mailto:akuznets...@mirantis.com] >> *Sent:* Wednesday, December 09, 2015 1:13 PM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [mistral] Improving Mistral pep8 rules >> files to match Mistral guidelines >> >> >> >> Hi Moshe, >> >> >> >> Great idea! >> >> >> >> It is possible to prepare some additional code checks, for example you >> can take a look how it was done in Rally project [1]. >> Before starting such work in Mistral, I guess that we can describe our >> addition code style rules in our official docs (somewhere in "Developer >> Guide" section [2]). >> >> >> >> [1] https://github.com/openstack/rally/tree/master/tests/hacking >> >> [2] http://docs.openstack.org/developer/mistral/#developer-guide >> >> >> >> On Wed, Dec 9, 2015 at 11:21 AM, ELISHA, Moshe (Moshe) < >> moshe.eli...@alcatel-lucent.com> wrote: >> >> Hi all, >> >> >> >> Is it possible to add all / some of the special guidelines of Mistral >> (like blank line before return, period at end of comment, …) to our pep8 >> rules file? >> >> >> >> This can save a lot of time for both committers and reviewers. >> >> >> >> 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 >> >> >> >> >> >> -- >> >> Best regards, >> >> Anastasia Kuznetsova >> >> __ >> 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 >> >> > > > -- > Best regards, > Anastasia Kuznetsova > __ > OpenStack Development Mailing 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 > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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 HA and multi-regional support" meeting minutes
Moshe, thanks for sharing these meeting minutes. I am happy to help with gate and new functional tests (probably some destructive scenarios) which will help us to test Mistral HA. On Wed, Dec 16, 2015 at 8:01 PM, ELISHA, Moshe (Moshe) < moshe.eli...@alcatel-lucent.com> wrote: > Hi all, > > > > Renat and I had an action item to think about "Mistral HA and > multi-regional support". > > No big surprises. These are the meeting minutes: > > > > Mistral Multi-Region: > > * A blueprint already exists [1] > > * Most topics were already discussed in Mitaka OpenStack summit and are > described in the blueprint. > > > > Mistral HA > > * Add a gate that runs Mistral in HA mode (Ask akuznetsova > for more info as she looked into this once). > > * Add more functional tests that are focused on HA tests > > * Put together a list of known HA issues that are currently not handled > (For example, if an executor dies immediately after dequeuing a task) and > think of solutions. > > * Expose Mistral load metrics to allow some external system to decide if > it needs to scale Mistral components in / out. > > > > [1] > https://blueprints.launchpad.net/mistral/+spec/mistral-multi-region-support > > > > Thanks. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Improving Mistral pep8 rules files to match Mistral guidelines
Moshe, I will create blueprint for that and will attach link to etherpad, so we can form list of the rules all together. After that it will be possible to publish all our 'rules' to docs and start their implementation. On Thu, Dec 10, 2015 at 11:23 AM, ELISHA, Moshe (Moshe) < moshe.eli...@alcatel-lucent.com> wrote: > Thanks, Anastasia! > > > > Who can take start documenting the rules? I remember only a few rules and > I don’t know all the nuances. > > For example, if the return statement is the only statement of a function – > do you still need a blank line before it? > > > > Once the rules doc will be available I can work on adding these rules to > our pep8. > > > > > > *From:* Anastasia Kuznetsova [mailto:akuznets...@mirantis.com] > *Sent:* Wednesday, December 09, 2015 1:13 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [mistral] Improving Mistral pep8 rules > files to match Mistral guidelines > > > > Hi Moshe, > > > > Great idea! > > > > It is possible to prepare some additional code checks, for example you can > take a look how it was done in Rally project [1]. > Before starting such work in Mistral, I guess that we can describe our > addition code style rules in our official docs (somewhere in "Developer > Guide" section [2]). > > > > [1] https://github.com/openstack/rally/tree/master/tests/hacking > > [2] http://docs.openstack.org/developer/mistral/#developer-guide > > > > On Wed, Dec 9, 2015 at 11:21 AM, ELISHA, Moshe (Moshe) < > moshe.eli...@alcatel-lucent.com> wrote: > > Hi all, > > > > Is it possible to add all / some of the special guidelines of Mistral > (like blank line before return, period at end of comment, …) to our pep8 > rules file? > > > > This can save a lot of time for both committers and reviewers. > > > > Thanks! > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > Best regards, > > Anastasia Kuznetsova > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Improving Mistral pep8 rules files to match Mistral guidelines
Hi Moshe, Great idea! It is possible to prepare some additional code checks, for example you can take a look how it was done in Rally project [1]. Before starting such work in Mistral, I guess that we can describe our addition code style rules in our official docs (somewhere in "Developer Guide" section [2]). [1] https://github.com/openstack/rally/tree/master/tests/hacking [2] http://docs.openstack.org/developer/mistral/#developer-guide On Wed, Dec 9, 2015 at 11:21 AM, ELISHA, Moshe (Moshe) < moshe.eli...@alcatel-lucent.com> wrote: > Hi all, > > > > Is it possible to add all / some of the special guidelines of Mistral > (like blank line before return, period at end of comment, …) to our pep8 > rules file? > > > > This can save a lot of time for both committers and reviewers. > > > > Thanks! > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Team meeting minutes - 11/30/2015
Thanks everyone for joining us! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-30-16.01.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-30-16.01.log.html -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] [murano] Is it possible to use Murano RESTful API to create and deploy an application
Hi Tony, We have already implemented commands which allow user to configure and deploy environments via CLI. Please, take a look to this article: http://docs.openstack.org/developer/murano/draft/enduser-guide/deploying_using_cli.html On Thu, Nov 26, 2015 at 9:18 AM, WANG, Ming Hao (Tony T) < tony.a.w...@alcatel-lucent.com> wrote: > Dear Murano developers and testers, > > > > I want to use Murano RESTful API to create and deploy an application. > > Based on my current understanding, I want to use muranoclient cli as > following: > > 1. “environment-create” to create Murano environment; > > 2. “environment-session-create” to create session for the > environment; > > 3. “environment-apps-create” to create application for the session. > > This command hasn’t been implemented yet, thus I implement it by studying “ > do_environment_apps_edit” to send POST request to “services” object. > > > > Could you please help to check if my thought is right? > > > > If it is right, I meet the following issue: > > When an environment includes several applications, I need to generate an > uuid for each application, and use the uuid to let one application > reference to another application. > > It is a little strange to let user provide this kind of information, and I > doubt if I’m using Murano in a wrong way, and Murano isn’t designed for > this. > > > > Could you please help to check? Is Murano designed to be able to expose > RESTful to do all the works(including application creation/deployment) that > user can do from UI? > > > > Please advice, > > Thanks, > > Tony > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Team meeting minutes - 11/23/2015
Thanks everyone for very productive meeting! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-23-16.04.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-11-23-16.04.log.html -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Notifier about changes in the dsvm gates structure
Hello Everyone, This is a notifier about the fact that Mistral team is on the way of refactoring of current Jenkins dsvm gates infrastructure. The final goal is to have voting dsvm gates which will run on every commit to mistral and mistralclient repositories. What we have now: - mistral repository: gate-mistral-devstack-dsvm job that installs mistral from commit and python-mistralclient from master, it runs both suite of tests on every commit: API tests from mistral repository and CLI tests from python-mistralclient repository; - mistralclient repository: gate-mistral-devstack-dsvm job that installs python-mistralclient from commit and mistral from master, it runs suite of CLI tests from python-mistralclient repository. As you can see, there is only job template for both repositories. What we will have (or what other projects have now): - mistral repository: gate-mistral-devstack-dsvm job that will install mistral from commit and latest released python-mistralclient (version will be taken according requirements), it will run only API tests from mistral repository. - mistralclient repository: gate-mistralclient-devstack-dsvm job that will install python-mistralclient from commit and mistral from master, it will run suite of CLI tests from python-mistralclient repository. As a result, we will have two separate job templates, in each of them we will run its own suite of tests. I've created appropriate blueprint for these changes mistral-making-dsvm-gates-voting <https://blueprints.launchpad.net/mistral/+spec/mistral-making-dsvm-gates-voting> and I am going to start work on its implementation. -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] sort dir of executions, asc or desc?
Hi Lingxian, I am agree with you that from user's point of view it is more convenient to show execution in the descending order (latest created execution on the top), but all other get_all methods (for tasks, workflows, etc) return list of objects in the ascending order. I prefer to have consistent behavior for all items, so if it is better to have descending order, than let's have it for all lists, not just for one. On Wed, Oct 28, 2015 at 4:14 AM, Lingxian Kong <anlin.k...@gmail.com> wrote: > Hi, guys, > > I found this bug[1] this morning which was fixed just now, and I have > to say, it is my intention that to make the query executions result in > descending order when I implemented the query pagination blueprint, > which is different with workflows list result behavior. Because in > user's perspective, I think it's more convinient to show the lasted > execution first, right? maybe the most commonly used scenario of > 'execution-list' is, user creates some executions first, then he/she > just wants to see what's the status of them, it‘s inconvenience for > the users to scroll down the page to find their executions in > ascending order, executions are more time sensitive than workflows. > > [1]: https://bugs.launchpad.net/mistral/+bug/1510417 > > -- > Regards! > --- > Lingxian Kong > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Team meeting minutes - 10/12/2015
Hi Lingxian, Yes, your understanding is correct. > * run_functional_tests.sh is just used locally, will not run tests depend on OpenStack. This script was written just for ability to run suite of api tempest tests locally (with turned off auth in Mistral and 'hacked' auth in tempest in our tests), just to check your changes and to find defects or regressions before making a commit. We DO NOT use this script in our gates. > * in our gate tests, all functional tests will run, since OpenStack will be deployed before Mistral installed. Yes, all our functional tests run in gate-mistral-devstack-dsvm. Firstly comes installation of the OpenStack services (specified in the configuration of the gate) using devstack scripts, then comes running of the tests. Regarding usage of Tempest in our tests need to think about it separately, need to investigate can we get rid of it or not according to DefCore requirements. Maybe we can have separate suite of api tempest tests and we can try to move them into tempest repository (or store in a separate folder in our repo) and have tempest-independent scenario tests in our repo. Need to think. On Wed, Oct 14, 2015 at 11:08 AM, Lingxian Kong <anlin.k...@gmail.com> wrote: > Hi, Mistral guys, > > In last meeting, we have discussed deeply about Tempest usage in Mistral > project and the functional testing mechanism, I have the understanding in > terms of functional testing as below, > > * run_functional_tests.sh is just used locally, will not run tests depend > on OpenStack. > * in our gate tests, all functional tests will run, since OpenStack will > be deployed before Mistral installed. > > Am I right? > > What's more, maybe I'm totally wrong about the Tempest usage in Mistral > functional testing and use it for DefCore purpose, I'm afraid Nikolay is > right, we can get rid of it totally, then we don't rely on it for our > testing. Or, we can use test plugin mechanism Tempest already provides(see > http://docs.openstack.org/developer/tempest/plugin.html), but I think we > are not interested in it in short term. > > On Tue, Oct 13, 2015 at 1:06 AM, Renat Akhmerov <rakhme...@mirantis.com> > wrote: > >> Hi, >> >> Thanks for joining team meeting today. >> >> Meeting minutes: >> http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-10-12-16.00.html >> Meeting log: >> http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-10-12-16.00.log.html >> >> See you next Monday at the same time. >> >> Renat Akhmerov >> @ Mirantis Inc. >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > *Regards!* > *---* > *Lingxian Kong* > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] L-3 roadmap discussion
Hello all, Happy to announce that Mistral team is planning to provide L-3 roadmap discussion meeting on Wednesday ( Aug 12 ). Meeting will be in our regular irc channel *#openstack-mistral at 12:00 pm GMT*. Here you can find what we have for L-3 now: https://launchpad.net/mistral/+milestone/liberty-3 If you want to see anything else in Mistral L-3, please, you are welcome to assign these bps/bugs for liberty-3 milestone. All items will be discussed on this meeting and final roadmap will be formed. -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Team meeting minutes
Thanks everyone for coming! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-10-16.03.txt Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-10-16.03.log.html The next meeting will be on Aug 17. You can post your agenda items at https://wiki.openstack.org/wiki/Meetings/MistralAgenda -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?
Boris, thanks for an explanation! I will take a closer look at the cover.sh script. On Fri, Jul 3, 2015 at 12:07 AM, Boris Pavlovic bpavlo...@mirantis.com wrote: Anastasia, because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. This job compares amount of non covered lines (before and after patch). If you just remove code there will be less lines that should be covered so amount of non covered lines will be less or the same (if everything was covered before) Fixing typos in docstrings won't introduce new lines. Btw job allows you to introduce N (few) new lines that are not covered by unit tests that are uncovered in some cases. Best regards, Boris Pavlovic On Thu, Jul 2, 2015 at 10:46 AM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Hi Timur, Generally I think that it is a good idea to have a gate that will check whether new code is covered by unit tests or not. But I am not sure that this gate should be voting (if I understand you correct), because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi all, I suggest to add CI job which will check the unit tests coverage for Sahara repository and will set -1 for commits with new code and without unit tests (if we have some degradation of tests coverage). This job successfully works for Rally project and it helps to organize the right code development process when developers write new unit tests for new functionality. we can just copy this job from Rally and start to use it for Sahara: Coverage control script: https://github.com/openstack/rally/blob/master/tests/ci/cover.sh Configuration file for coverage plugin (to exclude code which shouldn't be affected): https://github.com/openstack/rally/blob/master/.coveragerc Example of job in infra repository: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 I expect that it will help to increase the tests coverage by unit tests. Do we have any objections? -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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 -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?
Hi Timur, Generally I think that it is a good idea to have a gate that will check whether new code is covered by unit tests or not. But I am not sure that this gate should be voting (if I understand you correct), because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi all, I suggest to add CI job which will check the unit tests coverage for Sahara repository and will set -1 for commits with new code and without unit tests (if we have some degradation of tests coverage). This job successfully works for Rally project and it helps to organize the right code development process when developers write new unit tests for new functionality. we can just copy this job from Rally and start to use it for Sahara: Coverage control script: https://github.com/openstack/rally/blob/master/tests/ci/cover.sh Configuration file for coverage plugin (to exclude code which shouldn't be affected): https://github.com/openstack/rally/blob/master/.coveragerc Example of job in infra repository: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 I expect that it will help to increase the tests coverage by unit tests. Do we have any objections? -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Propose Winson Chan m4dcoder for core team
Hello all, As a QA Engineer of Mistral, I also appreciate Winson's contribution to the project, his ideas and I will be glad to see him as a core engineer of Mistral project. On Tue, Apr 7, 2015 at 12:56 PM, Lingxian Kong anlin.k...@gmail.com wrote: Although I have jumpped into Mistral just for a short time, but really appreciate Winson's vision about my patches, and his work is of great value to Mistral. I'm not in the core team of Mistral, but really hope to see Winson as a core member to bring more to Mistral. On Tue, Apr 7, 2015 at 5:08 PM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: It would be good to see Winson as the core contributor in Mistral. +1 for Winson! On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov rakhme...@mirantis.com wrote: +1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing 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 -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing 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] Decoupling Heat integration tests from Heat tree
Hello, As a QA engineer, I like the idea to make integration tests more independent and have an ability to package them and run against any deployed cloud, it will be very useful. But I assume, that creating a separate repository is not needed and it is enough to just collect all functional/integration tests in separate folder like now. Best regards, Anastasia Kuznetsova On Fri, Mar 27, 2015 at 6:18 AM, Angus Salkeld asalk...@mirantis.com wrote: On Fri, Mar 27, 2015 at 6:26 AM, Zane Bitter zbit...@redhat.com wrote: On 26/03/15 10:38, Pavlo Shchelokovskyy wrote: Hi all, following IRC discussion here is a summary of what I propose can be done in this regard, in the order of increased decoupling: 1) make a separate requirements.txt for integration tests and modify the tox job to use it. The code of these tests is pretty much decoupled already, not using any modules from the main heat tree. The actual dependencies are mostly api clients and test framework. Making this happen should decrease the time needed to setup the tox env and thus speed up the test run somewhat. +1 2) provide separate distutils' setup.py/setup.cfg http://setup.py/setup.cfg to ease packaging and installing this test suit to run it against an already deployed cloud (especially scenario tests seem to be valuable in this regard). +1 3) move the integration tests to a separate repo and use it as git submodule in the main tree. The main reasons not to do it as far as I've collected are not being able to provide code change and test in the same (or dependent) commits, and lesser reviewers' attention to a separate repo. -0 I'm not sure what the advantage is here, and there are a bunch of downsides (basically, I agree with Ryan). Unfortunately I missed the IRC discussion, can you elaborate on how decoupling to this degree might help us? I think the overall goal is to make it easier for an operator to run tests against their cloud to make sure everything is working. We should really have a common approach to this so they don't have to do something different for each project. Any opinions from the QA team? Maybe have it as it's own package, then you can install it and run something like: os-functional-tests-run package-name auth args here -A cheers, Zane. What do you think about it? Please share your comments. Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com http://www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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 sublime plugin available
Looks great and it is really helpful) I've already started to play with it and test it. Regards, Anastasia Kuznetsova On Mon, Mar 16, 2015 at 1:19 PM, Renat Akhmerov rakhme...@mirantis.com wrote: Thank you so much! I’m excited and looking forward to play with it ) How about moving (or copying) this code into one of our official repos? “mistral-extra” seems to be the right place since from the very beginning it was intended to be used for various tools and examples. Renat Akhmerov @ Mirantis Inc. On 14 Mar 2015, at 08:26, Lingxian Kong anlin.k...@gmail.com wrote: very cool! 2015-03-14 8:56 GMT+08:00 Dmitri Zimine dzim...@stackstorm.com: Mistral team got an exciting contribution: our good friend and industry veteran GP De Ciantis had built a sublime plugin for Mistral DSL - workbooks, workflows, etc. Check it out, and enjoy writing Mistral workflows! https://github.com/giampierod/mistral-sublime Thanks GP for an excellent contrib! Regards, DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing 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] Changing expression delimiters in Mistral DSL
As for me, I think that % ... % is not an elegant solution and looks
massive because of '%' sign. Also I agree with Renat, that % ... %
reminds HTML/Jinja2 syntax.
I am not sure that similarity with something should be one of the main
criteria, because we don't know who will use Mistral.
I like:
- {1 + $.var} Renat's example
- variant with using some functions (item 2 in Dmitry's list): { yaql:
“1+1+$.my.var 100” } or yaql: 'Hello' + $.name
- my two cents, maybe we can use something like: result: - Hello +
$.name -
Regards,
Anastasia Kuznetsova
On Tue, Feb 17, 2015 at 1:17 PM, Nikolay Makhotkin nmakhot...@mirantis.com
wrote:
Some suggestions from me:
1. y 1 + $.var # (short from yaql).
2. { 1 + $.var } # as for me, looks more elegant than % %. And
visually it is more strong
A also like p7 and p8 suggested by Renat.
On Tue, Feb 17, 2015 at 11:43 AM, Renat Akhmerov rakhme...@mirantis.com
wrote:
One more:
p9: \{1 + $.var} # That’s pretty much what
https://review.openstack.org/#/c/155348/ addresses but it’s not exactly
that. Note that we don’t have to put it in quotes in this case to deal with
YAML {} semantics, it’s just a string
Renat Akhmerov
@ Mirantis Inc.
On 17 Feb 2015, at 13:37, Renat Akhmerov rakhme...@mirantis.com wrote:
Along with % % syntax here are some other alternatives that I checked
for YAML friendliness with my short comments:
p1: ${1 + $.var} # Here it’s bad that $ sign is used for two
different things
p2: ~{1 + $.var} # ~ is easy to miss in a text
p3: ^{1 + $.var} # For someone may be associated with regular
expressions
p4: ?{1 + $.var}
p5: {1 + $.var} # This is kinda crazy
p6: e{1 + $.var} # That looks a pretty interesting option to me, “e”
could mean “expression” here.
p7: yaql{1 + $.var} # This is interesting because it would give a clear
and easy mechanism to plug in other expression languages, “yaql” here is a
used dialect for the following expression
p8: y{1 + $.var} # “y” here is just shortened “yaql
Any ideas and thoughts would be really appreciated!
Renat Akhmerov
@ Mirantis Inc.
On 17 Feb 2015, at 12:53, Renat Akhmerov rakhme...@mirantis.com wrote:
Dmitri,
I agree with all your reasonings and fully support the idea of changing
the syntax now as well as changing system’s API a little bit due to
recently found issues in the current engine design that don’t allow us, for
example, to fully implement ‘with-items’ (although that’s a little bit
different story).
Just a general note about all changes happening now: *Once we release
kilo stable release our API, DSL of version 2 must be 100% stable*. I
was hoping to stabilize it much earlier but the start of production use
revealed a number of things (I think this is normal) which we need to
address, but not later than the end of Kilo.
As far as % % syntax. I see that it would solve a number of problems
(YAML friendliness, type ambiguity) but my only not strong argument is that
it doesn’t look that elegant in YAML as it looks, for example, in ERB
templates. It really reminds me XML/HTML and looks like a bear in a grocery
store (tried to make it close to one old russian saying :) ). So just for
this only reason I’d suggest we think about other alternatives, maybe not
so familiar to Ruby/Chef/Puppet users but looking better with YAML and at
the same time being YAML friendly.
I would be good if we could here more feedback on this, especially from
people who started using Mistral.
Thanks
Renat Akhmerov
@ Mirantis Inc.
On 17 Feb 2015, at 03:06, Dmitri Zimine dzim...@stackstorm.com wrote:
SUMMARY:
We are changing the syntax for inlining YAQL expressions in Mistral YAML
from {1+$.my.var} (or “{1+$.my.var}”) to % 1+$.my.var %
Below I explain the rationale and the criteria for the choice. Comments
and suggestions welcome.
DETAILS:
-
We faced a number of problems with using YAQL expressions in Mistral DSL:
[1] must handle any YAQL, not only the ones started with $; [2] must
preserve types and [3] must comply with YAML. We fixed these problems by
applying Ansible style syntax, requiring quotes around delimiters (e.g.
“{1+$.my.yaql.var}”). However, it lead to unbearable confusion in DSL
readability, in regards to types:
publish:
intvalue1: {1+1}” # Confusing: you expect quotes to be string.
intvalue2: {int(1+1)}” # Even this doestn’ clean the confusion
whatisthis:{$.x + $.y}” # What type would this return?
We got a very strong push back from users in the filed on this syntax.
The crux of the problem is using { } as delimiters YAML. It is plain
wrong to use the reserved character. The clean solution is to find a
delimiter that won’t conflict with YAML.
Criteria for selecting best alternative are:
1) Consistently applies to to all cases of using YAML in DSL
2) Complies with YAML
3) Familiar to target user audience - openstack and devops
We prefer using
Re: [openstack-dev] [mistral] Team meeting minutes 02/16/2015
Hi Lingxian, Feel free to join us in IRC meeting every Monday at 16:00 UTC at #openstack-meeting channel. Regards, Anastasia Kuznetsova On Tue, Feb 17, 2015 at 7:05 PM, Lingxian Kong anlin.k...@gmail.com wrote: hi, Nikolay, Thanks for sending them out. It will be appreciated that there will be reminder before the meeting starts. Regards! 2015-02-17 0:52 GMT+08:00 Nikolay Makhotkin nmakhot...@mirantis.com: Thanks for joining our team meeting today! * Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-02-16-16.00.html * Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-02-16-16.00.log.html The next meeting is scheduled for Feb 23 at 16.00 UTC. -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing 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] Converging discussions on WF context and WF/task/action inputs
Winson, Renat,
I have a few questions, because some of aspects aren't clear to me.
1) How does the end user will pass env variables to workflow?Will you add
one more optional parameter to execution-create command?
mistral execution-create wf wf_input wf_params wf_env
If yes than what is wf_env will be, json file?
2) Retuning to first example:
...
action: std.sql conn_str={$.env.conn_str} query={$.query}
...
$.env - is it a name of environment or it will be a registered syntax to
getting access to values from env ?
3) Can user has a few environments?
On Wed, Dec 24, 2014 at 8:20 AM, Renat Akhmerov rakhme...@mirantis.com
wrote:
Thanks Winson,
Since we discussed all this already I just want to confirm that I fully
support this model, it will significantly help us make much more concise,
readable and maintainable workflows. I spent a lot of time thinking about
it and don’t see any problems with it. Nice job!
However, all additional comments and questions are more than welcomed!
Renat Akhmerov
@ Mirantis Inc.
On 24 Dec 2014, at 04:32, W Chan m4d.co...@gmail.com wrote:
After some online discussions with Renat, the following is a revision of
the proposal to address the following related blueprints.
*
https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment
* https://blueprints.launchpad.net/mistral/+spec/mistral-global-context
*
https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values
* https://blueprints.launchpad.net/mistral/+spec/mistral-runtime-context
Please refer to the following threads for backgrounds.
*
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052643.html
*
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052960.html
*
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052824.html
*Workflow Context Scope*
1. context to workflow is passed to all its subflows and subtasks/actions
(aka children) only explicitly via inputs
2. context are passed by value (copy.deepcopy) to children
3. change to context is passed to parent only when it's explicitly
published at the end of the child execution
4. change to context at the parent (after a publish from a child) is
passed to subsequent children
*Environment Variables*
Solves the problem for quickly passing pre-defined inputs to a WF
execution. In the WF spec, environment variables are referenced as
$.env.var1, $.env.var2, etc. We should implement an API and DB model
where users can pre-defined different environments with their own set of
variables. An environment can be passed either by name from the DB or
adhoc by dict in start_workflow. On workflow execution, a copy of the
environment is saved with the execution object. Action inputs are still
declared explicitly in the WF spec. This does not solve the problem where
common inputs are specified over and over again. So if there are multiple
SQL tasks in the WF, the WF author still needs to supply the conn_str
explicitly for each task. In the example below, let's say we have a SQL
Query Action that takes a connection string and a query statement as
inputs. The WF author can specify that the conn_str input is supplied from
the $.env.conn_str.
*Example:*
# Assume this SqlAction is registered as std.sql in Mistral's Action table.
class SqlAction(object):
def __init__(self, conn_str, query):
...
...
version: 2.0
workflows:
demo:
type: direct
input:
- query
output:
- records
tasks:
query:
action: std.sql conn_str={$.env.conn_str} query={$.query}
publish:
records: $
...
my_adhoc_env = {
conn_str: mysql://admin:secrete@localhost/test
}
...
# adhoc by dict
start_workflow(wf_name, wf_inputs, env=my_adhoc_env)
OR
# lookup by name from DB model
start_workflow(wf_name, wf_inputs, env=my_lab_env)
*Define Default Action Inputs as Environment Variables*
Solves the problem where we're specifying the same inputs to subflows and
subtasks/actions over and over again. On command execution, if action
inputs are not explicitly supplied, then defaults will be lookup from the
environment.
*Example:*
Using the same example from above, the WF author can still supply both
conn_str and query inputs in the WF spec. However, the author also has the
option to supply that as default action inputs. An example environment
structure is below. __actions should be reserved and immutable. Users
can specific one or more default inputs for the sql action as nested dict
under __actions. Recursive YAQL eval should be supported in the env
variables.
version: 2.0
workflows:
demo:
type: direct
input:
- query
output:
- records
tasks:
query:
action: std.sql query={$.query}
publish:
Re: [openstack-dev] [Mistral] Converging discussions on WF context and WF/task/action inputs
Renat,
thanks for response!
One more question:
So that same workflows could be running in different environments
Asking about using a few environments I meant within one workflow. For
example I need to work with two DB and I have two environments: env1 =
{conn_str: ip, user: user, password: passwd} and env2 = {conn_str:
ip2, user: user2, password: passwd2}. Will it be possible to do
something like this:
tasks:
connect_first_db:
action: std.sql conn_str={$.env1.conn_str} query={$.query}
publish:
records: $
connect_second_db:
action: std.sql conn_str={$.env2.conn_str} query={$.query}
publish:
records: $
Thanks,
Anastasia Kuznetsova
On Wed, Dec 24, 2014 at 2:19 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
On 24 Dec 2014, at 14:06, Anastasia Kuznetsova akuznets...@mirantis.com
wrote:
1) How does the end user will pass env variables to workflow?Will you add
one more optional parameter to execution-create command?
mistral execution-create wf wf_input wf_params wf_env
If yes than what is wf_env will be, json file?
Yes. IMO it should be possible to specify either a string (name of a
previously stored environment) or a json file (so called ad-hoc
environment).
2) Retuning to first example:
...
action: std.sql conn_str={$.env.conn_str} query={$.query}
...
$.env - is it a name of environment or it will be a registered syntax to
getting access to values from env ?
So far we agreed that ‘key' should not be a registered key. Environment
(optionally specified) is just another storage of variables going after
workflow context in a lookup chain. So that if somewhere in a wf we have an
expression $.something then this “something” will be first looked in
workflow context and if it doesn’t exist there then looked in the specified
environment.
But if we want to explicitly group a set of variables we can use any
(except for reserved as __actions ) key, for example, “env”.
3) Can user has a few environments?
Yes. That’s one of the goals of introducing a concept of environment. So
that same workflows could be running in different environments (e.g with
different email settings, any kinds of passports etc.).
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Plans to load and performance testing
Dmitry,
Now I see that my comments are not so informative, I will try to describe
environment and scenarios in more details.
1) *1 api 1 engine 1 executor *it means that there were 3 Mistral
processes running on the same box
2) list-workbooks scenario was run when there were no workflow executions
at the same time, I will notice this your comment and I will measure time
in such situation, but I guess that it will take more time, the question is
as far as.
3) 60 % of success means that only 60 % of number of times execution of
scenario 'list-workbooks' were successful, at the moment I have observed
only one type of error:
error connection to Rabbit : Error ConnectionError: ('Connection aborted.',
error(104, 'Connection reset by peer'))
4) we don't know the durability criteria of Mistral and under what load
Mistral will 'die', we want to define the threshold.
P.S. Dmitry, if you have any ideas/scenarios which you want to test, please
share them.
On Sat, Dec 20, 2014 at 9:35 AM, Dmitri Zimine dzim...@stackstorm.com
wrote:
Anastasia, any start is a good start.
* 1 api 1 engine 1 executor, list-workbooks*
what exactly doest it mean: 1) is mistral deployed on 3 boxes with
component per box, or all three are processes on the same box? 2) is
list-workbooks test running while workflow executions going on? How many?
what’s the character of the load 3) when it says 60% success what exactly
does it mean, what kind of failures? 4) what is the durability criteria,
how long do we expect Mistral to withstand the load.
Let’s discuss this in details on the next IRC meeting?
Thanks again for getting this started.
DZ.
On Dec 19, 2014, at 7:44 AM, Anastasia Kuznetsova
akuznets...@mirantis.com wrote:
Boris,
Thanks for feedback!
But I belive that you should put bigger load here:
https://etherpad.openstack.org/p/mistral-rally-testing-results
As I said it is only beginning and I will increase the load and change
its type.
As well concurrency should be at least 2-3 times bigger than times
otherwise it won't generate proper load and you won't collect enough data
for statistical analyze.
As well use rps runner that generates more real life load.
Plus it will be nice to share as well output of rally task report
command.
Thanks for the advice, I will consider it in further testing and reporting.
Answering to your question about using Rally for integration testing, as I
mentioned in our load testing plan published on wiki page, one of our
final goals is to have a Rally gate in one of Mistral repositories, so we
are interested in it and I already prepare first commits to Rally.
Thanks,
Anastasia Kuznetsova
On Fri, Dec 19, 2014 at 4:51 PM, Boris Pavlovic bpavlo...@mirantis.com
wrote:
Anastasia,
Nice work on this. But I belive that you should put bigger load here:
https://etherpad.openstack.org/p/mistral-rally-testing-results
As well concurrency should be at least 2-3 times bigger than times
otherwise it won't generate proper load and you won't collect enough data
for statistical analyze.
As well use rps runner that generates more real life load.
Plus it will be nice to share as well output of rally task report
command.
By the way what do you think about using Rally scenarios (that you
already wrote) for integration testing as well?
Best regards,
Boris Pavlovic
On Fri, Dec 19, 2014 at 2:39 PM, Anastasia Kuznetsova
akuznets...@mirantis.com wrote:
Hello everyone,
I want to announce that Mistral team has started work on load and
performance testing in this release cycle.
Brief information about scope of our work can be found here:
https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing
First results are published here:
https://etherpad.openstack.org/p/mistral-rally-testing-results
Thanks,
Anastasia Kuznetsova
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Plans to load and performance testing
Hello everyone, I want to announce that Mistral team has started work on load and performance testing in this release cycle. Brief information about scope of our work can be found here: https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing First results are published here: https://etherpad.openstack.org/p/mistral-rally-testing-results Thanks, Anastasia Kuznetsova @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] ActionProvider
Winson, Renat, I think that it is a good idea. Moreover, it is relevant, because about a month ago there was a question from one guy in our IRC channel about what if some of other 3rd party systems which provide their own client bindings (in python) want to integrate with Mistral, how it will work. For that moment we just thought about it, but hadn't any blueprints or discussions. Thanks, Anastasia Kuznetsova @ Mirantis Inc. On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Winson, The idea itself makes a lot of sense to me because we’ve had a number of discussions about how we could make action subsystem even more pluggable and flexible. One of the questions that we’d like to solve is to be able to add actions “on the fly” and at the same time stay safe. I think this whole thing is about specific technical details so I would like to see more of them. Generally speaking, you’re right about actions residing in a database, about 3 months ago we made this refactoring and put all actions into db but it may not be 100% necessary. Btw, we already have a concept of action generator that we use to automatically build OpenStack actions so you can take a look at how they work. Long story short… We’ve already made some steps towards being more flexible and have some facilities that could be further improved. Again, the idea is very interesting to me (and not only to me). Please share the details. Thanks Renat Akhmerov @ Mirantis Inc. On 17 Dec 2014, at 13:22, W Chan m4d.co...@gmail.com wrote: Renat, We want to introduce the concept of an ActionProvider to Mistral. We are thinking that with an ActionProvider, a third party system can extend Mistral with it's own action catalog and set of dedicated and specialized action executors. The ActionProvider will return it's own list of actions via an abstract interface. This minimizes the complexity and latency in managing and sync'ing the Action table. In the DSL, we can define provider specific context/configuration separately and apply to all provider specific actions without explicitly passing as inputs. WDYT? Winson ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Plans to load and performance testing
Boris, Thanks for feedback! But I belive that you should put bigger load here: https://etherpad.openstack.org/p/mistral-rally-testing-results As I said it is only beginning and I will increase the load and change its type. As well concurrency should be at least 2-3 times bigger than times otherwise it won't generate proper load and you won't collect enough data for statistical analyze. As well use rps runner that generates more real life load. Plus it will be nice to share as well output of rally task report command. Thanks for the advice, I will consider it in further testing and reporting. Answering to your question about using Rally for integration testing, as I mentioned in our load testing plan published on wiki page, one of our final goals is to have a Rally gate in one of Mistral repositories, so we are interested in it and I already prepare first commits to Rally. Thanks, Anastasia Kuznetsova On Fri, Dec 19, 2014 at 4:51 PM, Boris Pavlovic bpavlo...@mirantis.com wrote: Anastasia, Nice work on this. But I belive that you should put bigger load here: https://etherpad.openstack.org/p/mistral-rally-testing-results As well concurrency should be at least 2-3 times bigger than times otherwise it won't generate proper load and you won't collect enough data for statistical analyze. As well use rps runner that generates more real life load. Plus it will be nice to share as well output of rally task report command. By the way what do you think about using Rally scenarios (that you already wrote) for integration testing as well? Best regards, Boris Pavlovic On Fri, Dec 19, 2014 at 2:39 PM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Hello everyone, I want to announce that Mistral team has started work on load and performance testing in this release cycle. Brief information about scope of our work can be found here: https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing First results are published here: https://etherpad.openstack.org/p/mistral-rally-testing-results Thanks, Anastasia Kuznetsova @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Mistral test infrastructure proposal
(reposting due to lack of subject) Hello, everyone! I am happy to announce that Mistral team started working on test infrastructure. Due to this fact I prepared etherpad https://etherpad.openstack.org/p/MistralTests where I analysed what we have and what we need to do. I would like to get your feedback to start creating appropriate blueprints and implement them. Regards, Anastasia Kuznetsova QA Engineer at Mirantis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral]
Hello, everyone! I am happy to announce that Mistral team started working on test infrastructure. Due to this fact I prepared etherpad https://etherpad.openstack.org/p/MistralTests where I analysed what we have and what we need to do. I would like to get your feedback to start creating appropriate blueprints and implement them. Regards, Anastasia Kuznetsova QA Engineer at Mirantis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [murano] Proposal to add Ruslan Kamaldinov to murano-core team
+1 On Thu, Apr 17, 2014 at 7:11 PM, Stan Lagun sla...@mirantis.com wrote: +1 Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Thu, Apr 17, 2014 at 6:51 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: +1 On Thu, Apr 17, 2014 at 6:01 AM, Dmitry Teselkin dtesel...@mirantis.comwrote: +1 Agree On Thu, Apr 17, 2014 at 4:51 PM, Alexander Tivelkov ativel...@mirantis.com wrote: +1 Totally agree -- Regards, Alexander Tivelkov On Thu, Apr 17, 2014 at 4:37 PM, Timur Sufiev tsuf...@mirantis.comwrote: Guys, Ruslan Kamaldinov has been doing a lot of things for Murano recently (including devstack integration, automation scripts, making Murano more compliant with OpenStack standards and doing many reviews). He's actively participating in our ML discussions as well. I suggest to add him to the core team. Murano folks, please say your +1/-1 word. -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
