Re: [openstack-dev] [oslo.messaging]Optimize RPC performance by reusing callback queue
Hi, First of all, the correlation_id is needed for tracking the response for callback queue per client. What you said is the inefficiency of callback queue per request. In any case, callback queue is needed. About oslo_messaging, you can see the correlation_id in the driver of amqp. Br, Tuan/Nokia On Thu, Jun 8, 2017 at 4:29 AM, int32bit wrote: > Hi, > > Currently, I find our RPC client always need create a new callback queue > for every call requests to track the reply belongs, at least in Newton. > That's pretty inefficient and lead to poor performance. I also find some > RPC implementations no need to create a new queue, they track the request > and response by correlation id in message header(rabbitmq well supports, > not sure is it AMQP standard?). The rabbitmq official document provide a > simple demo, see [1]. > > So I am confused that why our oslo.messaging doesn't use this way > to optimize RPC performance. Is it for any consideration or do I miss > some potential cases? > > Thanks for any reply and discussion! > > > [1] https://www.rabbitmq.com/tutorials/tutorial-six-python.html. > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing
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 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 , > 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 > wrote: > >> Hi Doug, >> >> Anyway, thank for the notification. We are really appreciated. >> >> Regards, >> Vitaliy >> >> > 26 мая 2017 г., в 20:54, Doug Hellmann >> написал(а): >> > >> > 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 , >> 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.op >> enstack.org?subject:unsubscribe >
Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing
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 wrote: > Hi Doug, > > Anyway, thank for the notification. We are really appreciated. > > Regards, > Vitaliy > > > 26 мая 2017 г., в 20:54, Doug Hellmann > написал(а): > > > > 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 , > 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 > >>> > >>> > >> > > > > > __ > > OpenStack Development Mailing 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] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring
It is well-written here in OPNFV artifact: http://artifacts.opnfv.org/availability/review/33475/development_overview/index.html Br, Tuan/Nokia On Wed, May 10, 2017 at 3:49 PM, Matt Riedemann wrote: > On 5/9/2017 1:11 PM, Waines, Greg wrote: > >> I am looking for guidance on where to propose some “_VM Heartbeat / >> Health-check Monitoring_” functionality that I would like to contribute >> to openstack. >> >> >> >> Briefly, “_VM Heartbeat / Health-check Monitoring_” >> >> >> · is optionally enabled thru a Nova flavor extra-spec, >> >> · is a service that runs on an OpenStack Compute Node, >> >> · it sends periodic Heartbeat / Health-check Challenge Requests >> to a VM >> over a virtio-serial-device setup between the Compute Node and the VM >> thru QEMU, >> >> · on loss of heartbeat or a failed health check status will >> result in fault event, against the VM, being >> reported to Vitrage thru its data-source API. >> >> >> >> Where should I contribute this functionality ? >> >> · put it ALL in Vitrage ... both the monitoring and the >> data-source reporting ? >> >> · put the monitoring in Nova, and just the data source reporting >> in Vitrage ? >> >> · other ? >> >> >> >> Greg. >> >> >> >> >> >> >> >> >> >> >> >> p.s. other info ... >> >> >> >> Benefits of “VM Heartbeat / Health-check Monitoring” >> >> · monitors health of OS and Applications INSIDE the VM >> >> oi.e. even just a simple Ack of the Heartbeat would validate that >> the OS is running, IO mechanisms (sockets, etc) >> are working and processes are getting scheduled >> >> · health-check status reporting can trigger and report on either >> high-level or detailed application-specific audits within the VM, >> >> · the simple virtio-serial-device interface thru QEMU is UP very >> early in VM life cycle and is virtually _always up_ >> >> oi.e. its available for reporting issues virtually all the time, >> >> o ... compared to reporting issues over Tenant Network to a >> remote VNFManager which relies on Ethernet and IP Networking within the >> VM itself and then any provider network and adjacent routers around the >> compute nodes ... >> >> · uses a simple “Line-Delimited JSON” Format over virtio serial >> device ( http://www.linux-kvm.org/page/Virtio-serial_API ) >> >> osimple to implement protocol inside VM, in pretty much any language >> >> o( although would provide reference implementation ) >> >> · provides more thorough instance monitoring than libvirt’s >> emulated hardware watchdog ( >> https://libvirt.org/formatdomain.html#elementsWatchdog ) >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > How is this different from the watchdog action flavor extra spec / image > property which already exists? > > -- > > 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 > __ OpenStack Development Mailing 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] [openstack][keystonemiddleware][oslo_context]
Hi, I am now trying to refactor the mistral context by using oslo_context. However, it turns out the error in testing of keystone (this test belongs to mistral unittest). What i saw in the error that, the below statement does not return value: auth_url = CONF.keystone_authtoken.auth_uri ( https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py#L48 ) and then keystone client can not authenticate since auth_url is not provided. I did not change anything just refactor the context. Master branch is still going well with this test. Does any one have information about it? Thanks in advanced Br, Tuan/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] [Keystone][Token expiration]
Thanks Dolph,
I now have a pretty clear picture about it.
Br,
Tuan/Nokia
On Mon, Apr 10, 2017 at 2:58 PM, Dolph Mathews
wrote:
> The token itself is still expired, regardless of where it's persisted, if
> at all. Expired tokens are only considered valid when presented as an
> X-Auth-Token to keystonemiddleware.auth_token along with a valid
> X-Service-Token, or when validating an X-Subject-Token against keystone
> directly using either:
>
> HEAD /v3/auth/token?allow_expired
> GET /v3/auth/token?allow_expired
>
> No configuration is required in keystone.conf to enable the feature.
>
> More documentation is available in the release notes [1][2] and in the
> sample configuration file [3] (see [token] allow_expired_window).
>
> [1] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#new-features
> [2] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#upgrade-notes
> [3] https://docs.openstack.org/ocata/config-reference/
> identity/samples/keystone.conf.html
>
> On Mon, Apr 3, 2017 at 7:58 AM lương hữu tuấn
> wrote:
>
>> Hi Dolph,
>>
>> Thanks for reply, it means that from the db point of view, token is
>> expired but it is still passed to other service users in request (token
>> stored in memory?) and keystone allows this expired token? And to make this
>> feature working, we should apply the header of "X-Service-Token" and change
>> of "allow_expired" in keystone.conf.
>>
>> Br,
>>
>> Tuan/Nokia
>>
>> On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews
>> wrote:
>>
>> > does it mean that the token now will live forever
>>
>> No; it behaves as described in the document you linked. If you have any
>> specific security concerns, please raise them appropriately (such as a
>> security bug, if necessary).
>>
>> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn
>> wrote:
>>
>> Hi keystone folks,
>>
>> I have had a chance to take a look to this below patch for allowing the
>> expired token and it was merged in Octaka:
>>
>> https://specs.openstack.org/openstack/keystone-specs/
>> specs/keystone/ocata/allow-expired.html
>>
>> In our project, we also have problem with token expiration when running
>> mistral workflow. I have a concern that if this patch works as it does,
>> does it mean that the token now will live forever ("forever" seems so
>> sloppy, but it seems like the token is no longer expired). In this case, it
>> seems not good for security purpose.
>>
>> Br,
>>
>> Tuan/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
>>
>> --
>> -Dolph
>>
>>
>> __
>> OpenStack Development Mailing 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
>>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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] [Keystone][Token expiration]
Hi Dolph,
Thanks for reply, it means that from the db point of view, token is expired
but it is still passed to other service users in request (token stored in
memory?) and keystone allows this expired token? And to make this feature
working, we should apply the header of "X-Service-Token" and change of
"allow_expired" in keystone.conf.
Br,
Tuan/Nokia
On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews
wrote:
> > does it mean that the token now will live forever
>
> No; it behaves as described in the document you linked. If you have any
> specific security concerns, please raise them appropriately (such as a
> security bug, if necessary).
>
> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn
> wrote:
>
>> Hi keystone folks,
>>
>> I have had a chance to take a look to this below patch for allowing the
>> expired token and it was merged in Octaka:
>>
>> https://specs.openstack.org/openstack/keystone-specs/
>> specs/keystone/ocata/allow-expired.html
>>
>> In our project, we also have problem with token expiration when running
>> mistral workflow. I have a concern that if this patch works as it does,
>> does it mean that the token now will live forever ("forever" seems so
>> sloppy, but it seems like the token is no longer expired). In this case, it
>> seems not good for security purpose.
>>
>> Br,
>>
>> Tuan/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
>>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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] [Keystone][Token expiration]
Hi keystone folks,
I have had a chance to take a look to this below patch for allowing the
expired token and it was merged in Octaka:
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/allow-expired.html
In our project, we also have problem with token expiration when running
mistral workflow. I have a concern that if this patch works as it does,
does it mean that the token now will live forever ("forever" seems so
sloppy, but it seems like the token is no longer expired). In this case, it
seems not good for security purpose.
Br,
Tuan/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
Oh, Thanks Dougal, i am now clear since it is your TripleO use case. So yes, in this case, IMHO, we should keep the _get_client() as before but change it to the classmethod. May be other methods too like _create_client(), etc. We can think this change to be an alternative to the solution of creating extra Minxin classes. Br, Tuan On Tue, Mar 14, 2017 at 11:38 AM, Dougal Matthews wrote: > > > On 14 March 2017 at 10:21, lương hữu tuấn wrote: > >> >> >> On Tue, Mar 14, 2017 at 10:28 AM, Dougal Matthews >> wrote: >> >>> >>> >>> On 13 March 2017 at 09:49, lương hữu tuấn wrote: >>> >>>> >>>> >>>> On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve >>>> wrote: >>>> >>>>> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady 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(). >>>> >>> >> Hi, >> >> It is hard to me to understand what Thomas wants to say but i just >> understood based on what he wrote:). Sorry for my misunderstanding. >> >> >>> I might be wrong, but I think you read that Thomas wants to use >>> functions for actions, not classes. I don't think that is the case. I think >>> he is referring to the get_client method which is also what rbrady is >>> referring to. At the moment multiple inheritance wont work if you want to >>> inherit from NovaAction and KeyStone action because they both provide a >>> "_get_client" method. If they has a unique name "get_keystone_client" and >>> "get_nova_client" then the multiple inheritance wouldn't clash. >>> >>> Sorry Dougal but i do not get your point. Why the get_client could not >> be used through instance since it has context? >> > > In Mistral we have various OpenStack action classes. For example > NovaAction[1] and GlanceAction[2] (and many others in that file). If I want > to write an action that uses either Nova or Glance I can inherit from them, > for example: > > class MyNovaAction(NovaAction): > > def run(self): > > client = self._create_client() > # ... do something with the client and return
Re: [openstack-dev] [mistral] Mistral Custom Actions API Design
On Tue, Mar 14, 2017 at 10:28 AM, Dougal Matthews wrote: > > > On 13 March 2017 at 09:49, lương hữu tuấn wrote: > >> >> >> On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: >> >>> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady 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(). >> > Hi, It is hard to me to understand what Thomas wants to say but i just understood based on what he wrote:). Sorry for my misunderstanding. > I might be wrong, but I think you read that Thomas wants to use functions > for actions, not classes. I don't think that is the case. I think he is > referring to the get_client method which is also what rbrady is referring > to. At the moment multiple inheritance wont work if you want to inherit > from NovaAction and KeyStone action because they both provide a > "_get_client" method. If they has a unique name "get_keystone_client" and > "get_nova_client" then the multiple inheritance wouldn't clash. > > Sorry Dougal but i do not get your point. Why the get_client could not be used through instance since it has context? > Thomas - The difficulty with these methods is that they need to access the > context - the context is going to be added to the action class, and thus > while the get_client methods don't use the instance now, they will soon - > unless we change direction. > > > >> @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.op >>> enstack.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:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Mistral Custom Actions API Design
Hi, Agree with the simplicity that Renat has shown. I would not want to change the base class as well as the way of mistral created up to now. Br, Tuan/Nokia On Mar 14, 2017 6:29 AM, "Renat Akhmerov" wrote: > 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 wrote: > > > > On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: > >> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady 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 > >> >> __
Re: [openstack-dev] [mistral] Mistral Custom Actions API Design
On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: > On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady 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://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
Hi, I did not know about this change before but after reading the whole story, IMHO i myself love the way of keeping it as simple at this moment as you guys i think agreed on. For MixinAction or PolicyMixin, etc. we can develop them later when we have concrete case studies. Br, Tuan/Nokia On Fri, Mar 10, 2017 at 11:16 AM, Renat Akhmerov wrote: > > On 10 Mar 2017, at 15:09, Dougal Matthews wrote: > > On 10 March 2017 at 04:22, Renat Akhmerov > 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 Development Mailing 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
+1 for me. Sorry Michal if you read this thread, I thought that you are a man by calling you Mike :d. Tuan/Nokia On Mar 1, 2017 6:04 PM, "Dougal Matthews" wrote: > > > On 1 March 2017 at 16:47, Renat Akhmerov 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. >> > > +1, I think Michal would be a great addition to the core team. > > >> >> Thanks >> >> [1] http://stackalytics.com/?module=mistral-group&release=oc >> ata&user_id=michal-gershenzon >> >> Renat Akhmerov >> @Nokia >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tacker] Tacker upgrade vnf
Hi Tacker folks, I have my own consideration about vnf upgrade. Please correct me if i am wrong. As i saw that tacker supports the vnf update when vnfd and vnfd_id do not change. What about the situation of upgrading vnf, for instance, i would like to upgrade my vnf which is deployed with one virtual machine to the new version which has a cluster of virtual machine, or new flavor, or new resource model of heat stack. My question is such a this process is called SCALE in tacker? Br, Nokia/Tuan __ OpenStack Development Mailing 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] [yaql] Yaql validating performance
Hi Renat,
In short, it is the expression: output: <% $.data %>
I would like to post the workflow too since it would make more sense to
understand the whole picture(IMHO :)). In this case, it would be that the
data is too big, AFAIK is around 2MB. Therefore i would just wanna know
more information about the performance of YAQL (if we have), i myself do
not judge YAQL in this case.
Br,
Tuan
On Tue, Jan 24, 2017 at 6:09 AM, Renat Akhmerov
wrote:
> While I’m in the loop regarding how this workflow works others may not be.
> Could please just post your expression and data that you use to evaluate
> this expression? And times. Workflow itself has nothing to do with what
> we’re discussing.
>
> Renat Akhmerov
> @Nokia
>
> On 23 Jan 2017, at 21:44, lương hữu tuấn wrote:
>
> Hi guys,
>
> I am provide some information about the result of testing YAQL performance
> on my devstack stable/newton with RAM of 6GB. The workflow i created is
> below:
>
> #
> input:
> - size
> - number_of_handovers
>
> tasks:
> generate_input:
> action: std.javascript
> input:
> context:
> size: <% $.size %>
> script: |
> result = {}
> for(i=0; i < $.size; i++) {
> result["key_" + i] = {
> "alma": "korte"
> }
> }
> return result
> publish:
> data: <% task(generate_input).result %>
> on-success:
> - process
>
> process:
> action: std.echo
> input:
> output: <% $.data %>
> publish:
> data: <% task(process).result %>
> number_of_handovers: <% $.number_of_handovers - 1 %>
> on-success:
> - process: <% $.number_of_handovers > 0 %>
>
> ##
>
> I test with the size is 1 and the number_of_handover is 50. The result
> shows out that time for validating the <% $.data %> is quite long. I do not
> know this time is acceptable but imagine that in our use case, the value of
> $.data could be a large size. Couple of log file is below:
>
> INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-]
> Function evaluate finished in 11262.710 ms
>
> INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-]
> Function evaluate finished in 8146.324 ms
>
> ..
>
> The average value is around 10s each time of valuating.
>
> Br,
>
> Tuan
>
>
> On Mon, Jan 23, 2017 at 11:48 AM, lương hữu tuấn
> wrote:
>
>> Hi Renat,
>>
>> For more details, i will go to check on the CBAM machine and hope it is
>> not deleted yet since we have done it for around a week.
>> Another thing is Jinja2 showed us that it run 2-3 times faster with the
>> same test with YAQL. More information i will also provide it later.
>>
>> Br,
>>
>> Tuan
>>
>> On Mon, Jan 23, 2017 at 8:32 AM, Renat Akhmerov > > wrote:
>>
>>> Tuan,
>>>
>>> I don’t think that Jinja is something that Kirill is responsible for.
>>> It’s just a coincidence that we in Mistral support both YAQL and Jinja. The
>>> latter has been requested by many people so we finally did it.
>>>
>>> As far as performance, could you please provide some numbers? When you
>>> say “takes a lot of time” how much time is it? For what kind of input? Why
>>> do you think it is slow? What are your expectations?Provide as much info as
>>> possible. After that we can ask YAQL authors to comment and help if we
>>> realize that the problem really exists.
>>>
>>> I’m interested in this too since I’m always looking for ways to speed
>>> Mistral up.
>>>
>>> Thanks
>>>
>>> Renat Akhmerov
>>> @Nokia
>>>
>>> On 18 Jan 2017, at 16:25, lương hữu tuấn wrote:
>>>
>>> Hi Kirill,
>>>
>>> Do you have any information related to the performance of Jinja and Yaql
>>> validating. With the big size of input, yaql runs quite so slow in our case
>>> therefore we have plan to switch to jinja.
>>>
>>> Br,
>>>
>>> @Nokia/Tuan
>>>
>>> On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn
>>> wrote:
>>>
>>>> Hi Kirill,
>>>>
>>>> Thank you for you information. I hope we will have more information
>>>> about it. Just keep in touch when you guys in Mi
Re: [openstack-dev] [yaql] Yaql validating performance
Hi guys,
I am provide some information about the result of testing YAQL performance
on my devstack stable/newton with RAM of 6GB. The workflow i created is
below:
#
input:
- size
- number_of_handovers
tasks:
generate_input:
action: std.javascript
input:
context:
size: <% $.size %>
script: |
result = {}
for(i=0; i < $.size; i++) {
result["key_" + i] = {
"alma": "korte"
}
}
return result
publish:
data: <% task(generate_input).result %>
on-success:
- process
process:
action: std.echo
input:
output: <% $.data %>
publish:
data: <% task(process).result %>
number_of_handovers: <% $.number_of_handovers - 1 %>
on-success:
- process: <% $.number_of_handovers > 0 %>
##
I test with the size is 1 and the number_of_handover is 50. The result
shows out that time for validating the <% $.data %> is quite long. I do not
know this time is acceptable but imagine that in our use case, the value of
$.data could be a large size. Couple of log file is below:
INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-] Function
evaluate finished in 11262.710 ms
INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-] Function
evaluate finished in 8146.324 ms
..
The average value is around 10s each time of valuating.
Br,
Tuan
On Mon, Jan 23, 2017 at 11:48 AM, lương hữu tuấn
wrote:
> Hi Renat,
>
> For more details, i will go to check on the CBAM machine and hope it is
> not deleted yet since we have done it for around a week.
> Another thing is Jinja2 showed us that it run 2-3 times faster with the
> same test with YAQL. More information i will also provide it later.
>
> Br,
>
> Tuan
>
> On Mon, Jan 23, 2017 at 8:32 AM, Renat Akhmerov
> wrote:
>
>> Tuan,
>>
>> I don’t think that Jinja is something that Kirill is responsible for.
>> It’s just a coincidence that we in Mistral support both YAQL and Jinja. The
>> latter has been requested by many people so we finally did it.
>>
>> As far as performance, could you please provide some numbers? When you
>> say “takes a lot of time” how much time is it? For what kind of input? Why
>> do you think it is slow? What are your expectations?Provide as much info as
>> possible. After that we can ask YAQL authors to comment and help if we
>> realize that the problem really exists.
>>
>> I’m interested in this too since I’m always looking for ways to speed
>> Mistral up.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 18 Jan 2017, at 16:25, lương hữu tuấn wrote:
>>
>> Hi Kirill,
>>
>> Do you have any information related to the performance of Jinja and Yaql
>> validating. With the big size of input, yaql runs quite so slow in our case
>> therefore we have plan to switch to jinja.
>>
>> Br,
>>
>> @Nokia/Tuan
>>
>> On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn
>> wrote:
>>
>>> Hi Kirill,
>>>
>>> Thank you for you information. I hope we will have more information
>>> about it. Just keep in touch when you guys in Mirantis have some
>>> performance results about Yaql.
>>>
>>> Br,
>>>
>>> @Nokia/Tuan
>>>
>>> On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev
>>> wrote:
>>>
>>>> I think fuel team encountered similar problems, I’d advice asking them
>>>> around. Also Stan (author of yaql) might shed some light on the problem =)
>>>>
>>>> --
>>>> Kirill Zaitsev
>>>> Murano Project Tech Lead
>>>> Software Engineer at
>>>> Mirantis, Inc
>>>>
>>>> On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com)
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We are now using yaql in mistral and what we see that the process of
>>>> validating yaql expression of input takes a lot of time, especially with
>>>> the big size input. Do you guys have any information about performance of
>>>> yaql?
>>>>
>>>> Br,
>>>>
>>>> @Nokia/Tuan
>>>> __
>>>>
>>>> OpenStack Development Mailing List (not for usag
Re: [openstack-dev] [yaql] Yaql validating performance
Hi Renat, For more details, i will go to check on the CBAM machine and hope it is not deleted yet since we have done it for around a week. Another thing is Jinja2 showed us that it run 2-3 times faster with the same test with YAQL. More information i will also provide it later. Br, Tuan On Mon, Jan 23, 2017 at 8:32 AM, Renat Akhmerov wrote: > Tuan, > > I don’t think that Jinja is something that Kirill is responsible for. It’s > just a coincidence that we in Mistral support both YAQL and Jinja. The > latter has been requested by many people so we finally did it. > > As far as performance, could you please provide some numbers? When you say > “takes a lot of time” how much time is it? For what kind of input? Why do > you think it is slow? What are your expectations?Provide as much info as > possible. After that we can ask YAQL authors to comment and help if we > realize that the problem really exists. > > I’m interested in this too since I’m always looking for ways to speed > Mistral up. > > Thanks > > Renat Akhmerov > @Nokia > > On 18 Jan 2017, at 16:25, lương hữu tuấn wrote: > > Hi Kirill, > > Do you have any information related to the performance of Jinja and Yaql > validating. With the big size of input, yaql runs quite so slow in our case > therefore we have plan to switch to jinja. > > Br, > > @Nokia/Tuan > > On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn > wrote: > >> Hi Kirill, >> >> Thank you for you information. I hope we will have more information about >> it. Just keep in touch when you guys in Mirantis have some performance >> results about Yaql. >> >> Br, >> >> @Nokia/Tuan >> >> On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev >> wrote: >> >>> I think fuel team encountered similar problems, I’d advice asking them >>> around. Also Stan (author of yaql) might shed some light on the problem =) >>> >>> -- >>> Kirill Zaitsev >>> Murano Project Tech Lead >>> Software Engineer at >>> Mirantis, Inc >>> >>> On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com) >>> wrote: >>> >>> Hi, >>> >>> We are now using yaql in mistral and what we see that the process of >>> validating yaql expression of input takes a lot of time, especially with >>> the big size input. Do you guys have any information about performance of >>> yaql? >>> >>> Br, >>> >>> @Nokia/Tuan >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.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 > > __ OpenStack Development Mailing 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] [yaql] Yaql validating performance
Hi Kirill, Do you have any information related to the performance of Jinja and Yaql validating. With the big size of input, yaql runs quite so slow in our case therefore we have plan to switch to jinja. Br, @Nokia/Tuan On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn wrote: > Hi Kirill, > > Thank you for you information. I hope we will have more information about > it. Just keep in touch when you guys in Mirantis have some performance > results about Yaql. > > Br, > > @Nokia/Tuan > > On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev > wrote: > >> I think fuel team encountered similar problems, I’d advice asking them >> around. Also Stan (author of yaql) might shed some light on the problem =) >> >> -- >> Kirill Zaitsev >> Murano Project Tech Lead >> Software Engineer at >> Mirantis, Inc >> >> On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com) >> wrote: >> >> Hi, >> >> We are now using yaql in mistral and what we see that the process of >> validating yaql expression of input takes a lot of time, especially with >> the big size input. Do you guys have any information about performance of >> yaql? >> >> Br, >> >> @Nokia/Tuan >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [yaql] Yaql validating performance
Hi Kirill, Thank you for you information. I hope we will have more information about it. Just keep in touch when you guys in Mirantis have some performance results about Yaql. Br, @Nokia/Tuan On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev wrote: > I think fuel team encountered similar problems, I’d advice asking them > around. Also Stan (author of yaql) might shed some light on the problem =) > > -- > Kirill Zaitsev > Murano Project Tech Lead > Software Engineer at > Mirantis, Inc > > On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com) > wrote: > > Hi, > > We are now using yaql in mistral and what we see that the process of > validating yaql expression of input takes a lot of time, especially with > the big size input. Do you guys have any information about performance of > yaql? > > Br, > > @Nokia/Tuan > __ > > OpenStack Development Mailing 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] Yaql validating performance
. On Tue, Jan 17, 2017 at 1:10 PM, lương hữu tuấn wrote: > Hi, > > We are now using yaql in mistral and what we see that the process of > validating yaql expression of input takes a lot of time, especially with > the big size input. Do you guys have any information about performance of > yaql? > > Br, > > @Nokia/Tuan > __ OpenStack Development Mailing 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] Yaql validating performance
Hi, We are now using yaql in mistral and what we see that the process of validating yaql expression of input takes a lot of time, especially with the big size input. Do you guys have any information about performance of yaql? Br, @Nokia/Tuan __ OpenStack Development Mailing 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] [glance][vsphere][datastore]
Hi, I have a problem related to glance when i try to install Openstack Liberty using Fuel MOS8.0 on top of Vsphere: - It had problem of uploading cirros image and i found out that at that time, glance-api was not working. The error is"Datacenter reference can not be None" - Then i checked the source code of "glance_store/_drivers/vmware_ datastore.py" and realized that the"api.VMwareAPISession" has problem. It returned the value of datacenter_reference is None. Does anyone encounter this problem with Vsphere? Br, Tutj __ OpenStack Development Mailing 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] [Fuel][Glance][Vsphere][Datastore]
Hi, I have a problem related to glance when i try to install Openstack Liberty using Fuel MOS8.0 on top of Vsphere: - It had problem of uploading cirros image and i found out that at that time, glance-api was not working. The error is"Datacenter reference can not be None" - Then i checked the source code of "glance_store/_drivers/vmware_ datastore.py" and realized that the"api.VMwareAPISession" has problem. It returned the value of datacenter_reference is None. Does anyone encounter this problem with Vsphere? Br, Tutj __ OpenStack Development Mailing 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] [Fuel][Glance][Vsphere][Datastore]
Hi, I have a problem related to glance when i try to install Openstack Liberty using Fuel MOS8.0 on top of Vsphere: - It had problem of uploading cirros image and i found out that at that time, glance-api was not working. The error is "Datacenter reference can not be None" - Then i checked the source code of "glance_store/_drivers/vmware_datastore.py" and realized that the "api.VMwareAPISession" has problem. It returned the value of datacenter_reference is None. Does anyone encounter this problem with Vsphere? Br, Tutj __ OpenStack Development Mailing 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] [Vitrage] Installation
Hi Alexey, Yeap, it is what i mean. It seems that the connection channel between Zabbix and Vitrage just only through this script. Btw, thanks a lot Br, Tuan On Wed, Oct 5, 2016 at 3:37 PM, Weyl, Alexey (Nokia - IL) < alexey.w...@nokia.com> wrote: > Hi, > > > > When you say notification in Zabbix, do you mean a new trigger in Zabbix? > > > > If yes, then if you have configured the auxiliary Zabbix script > successfully then the script should recognize any trigger raised in zabbix > and send the trigger notification on the oslo bus. > > > > Best Regards, > > Alexey > > > > *From:* lương hữu tuấn [mailto:tuantulu...@gmail.com] > *Sent:* Wednesday, October 05, 2016 4:13 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Vitrage] Installation > > > > Hi, > > > > I have another question based on the getting information of vitrage from > monitoring solution. As i see that we have the default one now is nagios > and with the zabbix, we just have only the script that gets information > from zabbix as below: > > https://github.com/openstack/vitrage/blob/master/vitrage/ > datasources/zabbix/auxiliary/zabbix_vitrage.py > > If yes as above, so all the things like structure of zabbix notification, > what if i create a new notification in zabbix, can vitrage understand it? > > > > Br, > > > > Tutj > > > > On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) < > ifat.a...@nokia.com> wrote: > > Hi Paul, > > > > Please find the installation and configuration instructions here: > https://github.com/openstack/vitrage/blob/master/ > doc/source/installation-and-configuration.rst > > Let us know if you have any other questions, we’ll be happy to help. > > > > Best regards, > > Ifat. > > > > > > *From: *Paul Vaduva > *Reply-To: *"OpenStack Development Mailing List (not for usage questions)" > *Date: *Tuesday, 4 October 2016 at 16:03 > *To: *"openstack-dev@lists.openstack.org" > *Subject: *[openstack-dev] [Vitrage] Installation > > > > Hi everybody, > > > > I am writing you to ask for guidance with the installation of Vitrage. > > I have a deployed opnfv environment based on openstack mitaka release and > I want to ask you how I would go about installing vitrage (with horizon) on > this existing environment > > > > > > *Paul Ionut Vaduva* > > Software Engineer > > Linux Team > > > > *Email* *paul.vad...@enea.com * > > > > *Enea R&D* > > 319 Splaiul Independentei, OB403A > > Bucharest, 060044 > > *Phone* +4021311 43 00 > > *Fax *+402131143 01 > > > > > > www.enea.com > > > > [image: cid:image002.png@01D00576.7D651240] > > This message, including attachments, is CONFIDENTIAL. It may also be > privileged or otherwise protected by law. If you received this email by > mistake please let us know by reply and then delete it from your system; > you should not copy it or disclose its contents to anyone. All messages > sent to and from Enea may be monitored to ensure compliance with internal > policies and to protect our business. Emails are not secure and cannot be > guaranteed to be error free as they can be intercepted, a mended, lost or > destroyed, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message, > which arise as a result of email transmission. Anyone who communicates with > us by email accepts these risks. > > > > > __ > OpenStack Development Mailing 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] [Vitrage] Installation
Hi, I have another question based on the getting information of vitrage from monitoring solution. As i see that we have the default one now is nagios and with the zabbix, we just have only the script that gets information from zabbix as below: https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py If yes as above, so all the things like structure of zabbix notification, what if i create a new notification in zabbix, can vitrage understand it? Br, Tutj On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) < ifat.a...@nokia.com> wrote: > Hi Paul, > > Please find the installation and configuration instructions here: > https://github.com/openstack/vitrage/blob/master/ > doc/source/installation-and-configuration.rst > Let us know if you have any other questions, we’ll be happy to help. > > Best regards, > Ifat. > > > From: Paul Vaduva > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday, 4 October 2016 at 16:03 > To: "openstack-dev@lists.openstack.org" > Subject: [openstack-dev] [Vitrage] Installation > > Hi everybody, > > > > I am writing you to ask for guidance with the installation of Vitrage. > > I have a deployed opnfv environment based on openstack mitaka release and > I want to ask you how I would go about installing vitrage (with horizon) on > this existing environment > > > > > > *Paul Ionut Vaduva* > > Software Engineer > > Linux Team > > > > *Email* *paul.vad...@enea.com * > > > > *Enea R&D* > > 319 Splaiul Independentei, OB403A > > Bucharest, 060044 > > *Phone* +4021311 43 00 > > *Fax *+402131143 01 > > > > > > www.enea.com > > > > [image: cid:image002.png@01D00576.7D651240] > > This message, including attachments, is CONFIDENTIAL. It may also be > privileged or otherwise protected by law. If you received this email by > mistake please let us know by reply and then delete it from your system; > you should not copy it or disclose its contents to anyone. All messages > sent to and from Enea may be monitored to ensure compliance with internal > policies and to protect our business. Emails are not secure and cannot be > guaranteed to be error free as they can be intercepted, a mended, lost or > destroyed, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message, > which arise as a result of email transmission. Anyone who communicates with > us by email accepts these risks. > > > > > __ > OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission
Oh, my bad for the write permission of nova user. That should not be like this. Thanks Jeffrey. Cheers, T On Wed, Aug 24, 2016 at 2:39 PM, Jeffrey Zhang wrote: > On Wed, Aug 24, 2016 at 5:24 PM, lương hữu tuấn > wrote: > > However, with config file as nova.conf or in this case e.g. kolla.conf, > it > > should be kolla:kolla and only owner can write as well, it means 644 > since > > the kolla service is run under the name of kolla user, it is the same > with > > other services in OpenStack. > > there is no kolla.conf file in any containers. > > > > > With the folder, e.g. /etc/kolla or /etc/nova, it should be also > > read/write/executable with kolla user and kolla group since kolla service > > running with kolla user should have permission to get information from > > kolla.conf. > > for the nova.conf, why the nova user need to write/change the nova.conf > file? > > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission
Hi Jeffrey,
You are right with the rootwrap file since it is the root wrapper of the
specific service, e.g. nova. Then we should permit it as root:root and only
the owner can write.
However, with config file as nova.conf or in this case e.g. kolla.conf, it
should be kolla:kolla and only owner can write as well, it means 644 since
the kolla service is run under the name of kolla user, it is the same with
other services in OpenStack.
With the folder, e.g. /etc/kolla or /etc/nova, it should be also
read/write/executable with kolla user and kolla group since kolla service
running with kolla user should have permission to get information from
kolla.conf.
Br,
Tuan
On Wed, Aug 24, 2016 at 3:22 AM, Jeffrey Zhang
wrote:
> Using the same user for running service and the configuration files is
> danger. i.e. the service running user shouldn't be change the
> configuration files.
>
> a simple attack like:
> * a hacker hacked into nova-api container with nova user
> * he can change the /etc/nova/rootwrap.conf file and
> /etc/nova/rootwrap.d file, which he can get much greater authority
> with sudo
> * he also can change the /etc/nova/nova.conf file to use another
> privsep_command.helper_command to get greater authority
> [privsep_entrypoint]
> helper_command=sudo nova-rootwrap /etc/nova/rootwrap.conf
> privsep-helper --config-file /etc/nova/nova.conf
>
> So right rule should be: do not let the service running user have
> write permission to configuration files,
>
> about for the nova.conf file, i think root:root with 644 permission
> or root:nova with 640 should be enough
> for the directory file, root:root with 755 or root:nova with 750
> should be enough.
>
> On Tue, Aug 23, 2016 at 11:11 PM, Steven Dake (stdake)
> wrote:
> >
> >
> >
> >
> >
> > On 8/23/16, 7:05 AM, "Gerard Braad" wrote:
> >
> >>On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn
> wrote:
> >>> I also prefer a dedicated user ("kolla" seems the best choice) as same
> > On Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke
> wrote:
> >>>> In my experience operators prefer a dedicated user (kolla:kolla),
> though I
> >>
> >>kolla:kolla seems more logical and simpler to reason about.
> >>
> >
> > kolla:kolla still works with multi-user approach and permissions 660 on
> /etc/kolla files.
> >
> > Regards
> > -steve
> >
> >>
> >>--
> >>
> >> Gerard Braad | http://gbraad.nl
> >> [ Doing Open Source Matters ]
> >>
> >>__
>
> >>OpenStack Development Mailing 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
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing 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] [kolla] Kolla configuration files owner and permission
I also prefer a dedicated user ("kolla" seems the best choice) as same as
other projects in OpenStack.
Cheers,
Tuan
On Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke wrote:
> In my experience operators prefer a dedicated user (kolla:kolla), though I
> can't see any major problem with your root:kolla approach.
>
>
> On 23/08/16 14:40, Steven Dake (stdake) wrote:
>
>>
>>
>>
>>
>>
>> On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com"
>> wrote:
>>
>> Hi S.Dake,
>>>
>>> Hello Kollish,
>
> I am working on bp ansible-specific-task-become so I need community
> opinion about Kolla configuration files owner and permissions.
>
> For files in "/var/lib/kolla", it's quite clear that the owner should
> be 'root' as currently.
>
> For files in "/etc/kolla": After discussion with S.Dake on IRC, he
> recommends /etc/kolla is owned by root and all files in it is 660
> (writable
> by a group).
>
Just to add a bit of clarity, the rationale for this idea is that a
group of operators could add themselves to the kolla group on all of the
nodes and use their specific ssh keys to operate OpenStack. > This is why
the group concept in unix was invented 50 odd years ago ;)
>>>
>>> I just notice that if the directory has 660, so non-root user cannot
>>> access file in this folder. It seems conflict with group purpose.
>>> Should it be 770 for folders?
>>>
>>
>> Yes 770 for folders 660 for files seeded by the user ids and their ssh
>> keys in the host playbook that is in the review queue. Changes to the host
>> playbook in the review queue should come later for this group based model.
>>
>> The real question is what do operators prefer? Single user (non-root),
>> Multi-user (non-root), or Single user (root).
>>
>> Regards
>> -steve
>>
>>>
>>> Regards
-steve
>>>
>>>
>>> Best regards,
>>>
>>> duonghq
>>> PODC - Fujitsu Vietnam Ltd.
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] IBM SVC creates iSCSI initiator when using FC
Hi, We had problem when using FC for our SAN using IBM SVC in Mitaka. Each time we create an instance booted from volume, we always see another iSCSI port on SVC. All the FC ports were created on backend before. We try the change in Mitaka for setting connection protocol via extra_spec in volume but it seems useless. Does any one encounter this problem? Br, Tuan __ OpenStack Development Mailing 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] [nova] theoretical race between live migration and resource audit?
Hi,
Yes, it is actually a race and we have already faced a negative effect when
using evacuation. Some information of cpu pinning is lost. Imagine that, in
some cases, we do some re-scheduling actions (evacuate, live-migration,
etc.) then immediately do the next actions (delete, resize, etc.) before
the resource_tracker updates in the next period. In this case, it fails.
Actually, it has some negative side in writing tests based on the scenario
described above.
Br,
Tutj
On Fri, Jun 10, 2016 at 10:36 AM, Matthew Booth wrote:
> Yes, this is a race.
>
> However, it's my understanding that this is 'ok'. The resource tracker
> doesn't claim to be 100% accurate at all times, right? Otherwise why would
> it update itself in a period task in the first place. It's my understanding
> that the resource tracker is basically a best effort cache, and that
> scheduling decisions can still fail at the host. The resource tracker will
> fix itself next time it runs via its periodic task.
>
> Matt (not a scheduler person)
>
> On Thu, Jun 9, 2016 at 10:41 PM, Chris Friesen <
> chris.frie...@windriver.com> wrote:
>
>> Hi,
>>
>> I'm wondering if we might have a race between live migration and the
>> resource audit. I've included a few people on the receiver list that have
>> worked directly with this code in the past.
>>
>> In _update_available_resource() we have code that looks like this:
>>
>> instances = objects.InstanceList.get_by_host_and_node()
>> self._update_usage_from_instances()
>> migrations = objects.MigrationList.get_in_progress_by_host_and_node()
>> self._update_usage_from_migrations()
>>
>>
>> In post_live_migration_at_destination() we do this (updating the host and
>> node as well as the task state):
>> instance.host = self.host
>> instance.task_state = None
>> instance.node = node_name
>> instance.save(expected_task_state=task_states.MIGRATING)
>>
>>
>> And in _post_live_migration() we update the migration status to
>> "completed":
>> if migrate_data and migrate_data.get('migration'):
>> migrate_data['migration'].status = 'completed'
>> migrate_data['migration'].save()
>>
>>
>> Both of the latter routines are not serialized by the
>> COMPUTE_RESOURCE_SEMAPHORE, so they can race relative to the code in
>> _update_available_resource().
>>
>>
>> I'm wondering if we can have a situation like this:
>>
>> 1) migration in progress
>> 2) We start running _update_available_resource() on destination, and we
>> call instances = objects.InstanceList.get_by_host_and_node(). This will
>> not return the migration, because it is not yet on the destination host.
>> 3) The migration completes and we call
>> post_live_migration_at_destination(), which sets the host/node/task_state
>> on the instance.
>> 4) In _update_available_resource() on destination, we call migrations =
>> objects.MigrationList.get_in_progress_by_host_and_node(). This will return
>> the migration for the instance in question, but when we run
>> self._update_usage_from_migrations() the uuid will not be in "instances"
>> and so we will use the instance from the newly-queried migration. We will
>> then ignore the instance because it is not in a "migrating" state.
>>
>> Am I imagining things, or is there a race here? If so, the negative
>> effects would be that the resources of the migrating instance would be
>> "lost", allowing a newly-scheduled instance to claim the same resources
>> (PCI devices, pinned CPUs, etc.)
>>
>> Chris
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
>
> Phone: +442070094448 (UK)
>
>
> __
> OpenStack Development Mailing 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] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04
Hi, I got confused here. When a new version of kernel is installed and by checking "uname -r", what i saw that the server is using wily. Why it is not used in this case? Thanks in advanced, Tutj On Sun, May 8, 2016 at 10:45 AM, Steve Kowalik wrote: > On 08/05/16 08:11, lương hữu tuấn wrote: > >> Hi, >> >> @Robert: I was successful to update the kernel without change the image. >> > > But that was Robert's point entirely. Installing the kernel will work > fine, but it does not get you running that kernel -- also like Robert > said, you need to change the image to run a different kernel than what > it has installed. > > -- > Steve > "Stop breathing down my neck!" > "My breathing is merely a simulation." > "So is my neck! Stop it anyway." > - EMH vs EMH, USS Prometheus > > > __ > OpenStack Development Mailing 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] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04
Hi, @Robert: I was successful to update the kernel without change the image. It seems Kolla is quite unstable. Tutj On Sun, May 8, 2016 at 5:43 AM, Hui Kang wrote: > Robert, > Thanks for you reply. Is there any way to change the VM image on the gate? > > BTW, I do see some kolla deploy gate job successes on kernel 3.13 [1]. > Is there any reason kolla needs to check 4.2 on ubuntu 14.04? > > - Hui > > [1] > http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-ubuntu-source/90ff270/console.html#_2016-05-07_12_42_12_253 > > On Sat, May 7, 2016 at 11:14 PM, Robert Collins > wrote: > > That won't get you running the new kernel; for that you need to change > > the image itself. > > > > -Rob > > > > > __ > > OpenStack Development Mailing 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] [Nova] Automatically updating the status of service in Nova
Hi Nova stacker, In the time checking/researching for the multi agent platform in OpenStack Nova, i tried to figure out how the services (nova-compute, nova-scheduler,etc.) update themselves to the Nova db (service table)? What are the terminology behind these mechanism that agents use to update the status of itself into DB? Thanks in advanced, Tutj __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
