| *** jruano has quit IRC | 00:08 | |
| *** xuhaiwei has joined #senlin | 00:33 | |
| *** xuhaiwei has quit IRC | 00:54 | |
| *** xuhaiwei has joined #senlin | 00:55 | |
| *** Qiming has joined #senlin | 00:57 | |
| *** jruano has joined #senlin | 01:03 | |
| openstackgerrit | Merged stackforge/senlin: Updated from global requirements https://review.openstack.org/204305 | 01:09 |
|---|---|---|
| *** jruano has quit IRC | 01:09 | |
| *** jdandrea has quit IRC | 01:11 | |
| openstackgerrit | xu-haiwei proposed stackforge/senlin: Add node module test case part1 https://review.openstack.org/199803 | 01:15 |
| *** jruano has joined #senlin | 01:28 | |
| *** Yanyanhu has joined #senlin | 01:32 | |
| *** jruano has quit IRC | 01:41 | |
| openstackgerrit | xu-haiwei proposed stackforge/python-senlinclient: Parse exception from SDK https://review.openstack.org/204333 | 01:52 |
| openstackgerrit | Merged stackforge/python-senlinclient: Parse exception from SDK https://review.openstack.org/204333 | 01:59 |
| *** jruano has joined #senlin | 02:00 | |
| *** Zhenqi has joined #senlin | 02:05 | |
| *** jruano has quit IRC | 02:13 | |
| openstackgerrit | Yanyan Hu proposed stackforge/senlin: Add test case for policy base module and fix a bug https://review.openstack.org/197894 | 02:15 |
| *** Zhenqi has quit IRC | 02:16 | |
| *** Zhenqi has joined #senlin | 02:16 | |
| *** jruano has joined #senlin | 02:17 | |
| *** jruano has quit IRC | 02:17 | |
| *** Zhenqi has quit IRC | 02:20 | |
| *** Qiming_ has joined #senlin | 02:26 | |
| *** Qiming has quit IRC | 02:30 | |
| *** Tennyson has joined #senlin | 03:15 | |
| *** Qiming_ is now known as Qiming | 03:18 | |
| Qiming | seems the environment revision is working? | 03:18 |
| Yanyanhu | yes :) | 03:22 |
| Qiming | cool | 03:30 |
| Qiming | I'm not feeling comfortable about the object initializations | 03:31 |
| Qiming | sometimes we use None, sometimes we use '' | 03:31 |
| Qiming | we need a convention on this | 03:31 |
| Yanyanhu | hmm, that's a problem | 03:32 |
| Qiming | we don't know if a field/property is not assigned or it has default to '' or set explicitly to '' | 03:32 |
| Qiming | let's think about this | 03:33 |
| Qiming | could be a topic for test cases | 03:33 |
| Qiming | lunch go | 03:33 |
| Yanyanhu | ok | 03:33 |
| *** jruano has joined #senlin | 03:46 | |
| *** jruano has quit IRC | 04:31 | |
| *** hightall has joined #senlin | 04:47 | |
| openstackgerrit | Merged stackforge/senlin: Add node module test case part1 https://review.openstack.org/199803 | 05:17 |
| openstackgerrit | OpenStack Proposal Bot proposed stackforge/senlin: Updated from global requirements https://review.openstack.org/204431 | 05:18 |
| *** Zhenqi has joined #senlin | 05:23 | |
| openstackgerrit | Merged stackforge/senlin: Add test case for policy base module and fix a bug https://review.openstack.org/197894 | 05:24 |
| *** mathspanda has joined #senlin | 05:27 | |
| Yanyanhu | hi, Qiming, I'm trying to work on test case of nova_v2 driver. But before that, I think maybe we should refactor the exception handling in this driver first, something like what you have done for neutron_v2 driver in this patch https://review.openstack.org/#/c/203480/ | 05:38 |
| Qiming | okay | 05:41 |
| Qiming | that's something worth doing I think | 05:41 |
| Yanyanhu | yes | 05:41 |
| Qiming | writing test case is a good chance to revisit the code | 05:43 |
| Yanyanhu | right :) | 05:44 |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Remove some unused dependencies https://review.openstack.org/204441 | 05:54 |
| xuhaiwei | Yanyanhu, will you do the exception handling for nova_v2? | 05:57 |
| Yanyanhu | I can, but if you have had a plan for this, I will work on test case of lb_policy first :) | 05:58 |
| xuhaiwei | Not a specific plan up to now :( | 05:59 |
| Yanyanhu | no problem, I will try to propose a patch for this | 05:59 |
| xuhaiwei | thanks | 05:59 |
| Yanyanhu | welcome :) | 06:00 |
| openstackgerrit | Yanyan Hu proposed stackforge/senlin: Add a new exception type 'ResourceUpdatingFailure' https://review.openstack.org/204443 | 06:05 |
| openstackgerrit | Yanyan Hu proposed stackforge/senlin: Add a new exception type 'ResourceUpdateFailure' https://review.openstack.org/204443 | 06:18 |
| *** mathspanda has quit IRC | 06:29 | |
| *** lixinhui_ has joined #senlin | 06:35 | |
| *** mathspanda has joined #senlin | 06:54 | |
| openstackgerrit | Yanyan Hu proposed stackforge/senlin: Refactor the exception handling in nova_v2 driver https://review.openstack.org/204462 | 07:08 |
| lixinhui_ | I compared the senlin node-create and nova boot, debug only shows limited information about connection between sdk and nova server | 07:10 |
| lixinhui_ | please help me on this | 07:10 |
| lixinhui_ | http://paste.openstack.org/show/398867/ | 07:11 |
| lixinhui_ | but nova boot shows complete communication and message body | 07:11 |
| lixinhui_ | http://paste.openstack.org/show/389934/ | 07:11 |
| * Qiming is in heat meeting | 07:12 | |
| Yanyanhu | hi, lixinhui_ , I think you may not be able to get detail debug information about interaction between sdk and nova when you create senlin node using a nova server profile | 07:19 |
| Yanyanhu | so you want to get the detail information about how sdk talks with nova when senlin node is created? | 07:21 |
| xuhaiwei | Qiming, busy with heat meeting? | 07:41 |
| *** Zhenqi has quit IRC | 07:50 | |
| *** Zhenqi has joined #senlin | 07:51 | |
| Qiming | back | 08:00 |
| xuhaiwei | Qiming, I found the reason why all the update methods doesn't work | 08:03 |
| Qiming | update is not implemented | 08:03 |
| xuhaiwei | that is because openstacksdk client is using PUT method to request, but senlin api is using PATCH | 08:03 |
| Qiming | sdk can choose between patch and put? | 08:04 |
| xuhaiwei | node-update is implemented at least i think | 08:04 |
| xuhaiwei | I am afraid not | 08:04 |
| Qiming | em | 08:05 |
| Qiming | it is there | 08:05 |
| xuhaiwei | https://github.com/stackforge/python-openstacksdk/blob/master/openstack/resource.py#L549 | 08:05 |
| xuhaiwei | this is what they do | 08:05 |
| Qiming | no | 08:05 |
| Qiming | this is create code | 08:06 |
| Qiming | https://github.com/stackforge/python-openstacksdk/blob/master/openstack/resource.py#L236 | 08:06 |
| Qiming | a resource can set patch_update to true | 08:06 |
| xuhaiwei | yes, line 747 | 08:06 |
| xuhaiwei | ohh, so we can change it to true in senlinclient? | 08:07 |
| Qiming | some resources are using PATCH as well | 08:07 |
| Qiming | https://github.com/stackforge/python-openstacksdk/blob/master/openstack/identity/v3/service.py#L29 | 08:07 |
| Qiming | https://github.com/stackforge/python-openstacksdk/blob/master/openstack/identity/v3/domain.py#L29 | 08:07 |
| Qiming | yes we should | 08:08 |
| xuhaiwei | ok | 08:09 |
| *** Tennyson has quit IRC | 08:12 | |
| *** Zhenqi has quit IRC | 08:14 | |
| *** Zhenqi has joined #senlin | 08:14 | |
| openstackgerrit | xu-haiwei proposed stackforge/python-senlinclient: Use PATCH method to update resources https://review.openstack.org/204488 | 08:19 |
| openstackgerrit | xu-haiwei proposed stackforge/python-senlinclient: Use PATCH method to update resources https://review.openstack.org/204488 | 08:35 |
| Qiming | hi, xuhaiwei and Yanyanhu | 08:44 |
| Qiming | do you have a few mins to talk about the exception handling in drivers? | 08:44 |
| Yanyanhu | sure, just want to talk with you about this. | 08:45 |
| Yanyanhu | my firefox is closed for java7 update... | 08:45 |
| xuhaiwei | I am ok | 08:45 |
| Yanyanhu | so may not be able to open the review page | 08:45 |
| Qiming | okay | 08:46 |
| Qiming | so I saw your discussions on the review page | 08:46 |
| Qiming | it's interesting | 08:46 |
| xuhaiwei | but the problem is not easy to resolve imo | 08:46 |
| Qiming | basically, I think Yanyan was duplicating what we have done to another driver | 08:46 |
| Qiming | and the intent was to kill all exceptions internally, avoid sending any information that makes no sense to users | 08:47 |
| Qiming | the current approach might lead to a situation of over kill | 08:48 |
| Qiming | xuhaiwei has some valid concerns that there are cases we need to let users know what happened, it could be just their errors | 08:48 |
| Qiming | it's a trade-off, tough one | 08:48 |
| Qiming | when I was working on a similar driver (cannot recall which one), I was thinking to myself | 08:49 |
| Qiming | how many different error types we will need to deal with? | 08:50 |
| Qiming | no answer | 08:50 |
| xuhaiwei | imo, the exception's name is not important, the important thing is the error code | 08:50 |
| Yanyanhu | yes, actually it's difficult since we can't ensure whether we can get enough information from SDK to help us decide how to classify and handle the exception raised from driver | 08:50 |
| Qiming | so the current approach is to dump the excetions at driver code, and we can move on to do a better job in future | 08:50 |
| Qiming | ideally, we can have a utility function that will do all exception translation | 08:52 |
| xuhaiwei | like what was done in the client side? | 08:52 |
| Qiming | to other services senlin-engine is talking to, senlin-engine is the client | 08:53 |
| Qiming | I am referring that as an "ideal" case because ... there will be special cases | 08:54 |
| Qiming | we just don't know yet | 08:54 |
| Yanyanhu | so Qiming, I think maybe we should include the ex msg into the exception as haiwei sugguested and reserver it for possible usage in future? | 08:55 |
| xuhaiwei | honestly, when I thought about the exception handling problem in senlin for the first time, the most thing I was worring about is we will import 500 error, if we can't handle exceptions like 400 and 404 | 08:55 |
| Qiming | so, how about we copy the client side exception handling code to the server side | 08:55 |
| Yanyanhu | em, this can cover some cases | 08:56 |
| Qiming | we develop the exception handling in a common module and see if we can catch them all | 08:56 |
| Yanyanhu | but just as you said, there are other special cases | 08:56 |
| Qiming | we just don't know | 08:56 |
| Yanyanhu | yes | 08:57 |
| xuhaiwei | that may make things too complicated I am afraid | 08:57 |
| Qiming | if we cannot parse the exception, we check its error code, create a message for users to know, dump the exception in engine for developers to analyze | 08:57 |
| Qiming | there are just too many locations in the drivers subdirectory where we need to handle exceptions | 08:58 |
| xuhaiwei | that's not bad | 08:58 |
| Qiming | do the best we can | 08:58 |
| xuhaiwei | we judge the error message, if it is meaningful to users, we just don't change it | 08:59 |
| Qiming | okay | 08:59 |
| Yanyanhu | you mean status code based judgement? | 08:59 |
| xuhaiwei | yes, status code and error message | 09:00 |
| Qiming | for example, we are manipulating trusts inside the api, the middleware and the engine | 09:00 |
| Yanyanhu | ok, since I'm a little worried that message text based judgement could be too complicated | 09:00 |
| Qiming | we are not supposed to expose those messages to users | 09:00 |
| xuhaiwei | right | 09:00 |
| Qiming | we can start with a 'translate_exception()' function | 09:01 |
| Qiming | if needed later on, we can provide a 'translate_resource_creation_exception_types()' function | 09:02 |
| Qiming | maybe we will never go that far | 09:02 |
| xuhaiwei | so about Yanyanhu's patch, how to handle it? just let the HttpException go up? | 09:05 |
| Yanyanhu | ok, so basically, all exception happened in driver will be translated first. After this translation, some of them will be just logged, and some of them will be converted to internal exception which means http500, and others will be converted to a meaningful exception that sent back to end user | 09:05 |
| Qiming | Yep | 09:05 |
| xuhaiwei | the first step is a little vague | 09:06 |
| xuhaiwei | how to translate it? | 09:06 |
| Qiming | to make the code more robust, maybe we can do this? | 09:07 |
| Yanyanhu | xuhaiwei, may need some text parsing I guess. but still not very clear about it | 09:08 |
| Qiming | copy the client side exception parsing to server repo | 09:08 |
| Yanyanhu | worth to have a try | 09:08 |
| Qiming | text based parsing doesn't sound practical | 09:08 |
| Yanyanhu | but just as xuhaiwei said, could be too complicated | 09:08 |
| Qiming | yes | 09:09 |
| Yanyanhu | Qiming, since I guess what we can get from sdk is just exception msg... | 09:09 |
| xuhaiwei | copy the client side exception parsing especially for the driver exception handling? | 09:09 |
| Yanyanhu | which could include status code and message info | 09:09 |
| xuhaiwei | we can make a test for nova_v2 using the client exception parsing | 09:10 |
| Qiming | Yanyanhu, check this: https://review.openstack.org/#/c/204333/1/senlinclient/common/exc.py | 09:11 |
| Qiming | it is about exception code, record format and message | 09:11 |
| Yanyanhu | ok | 09:12 |
| Yanyanhu | hmmmm | 09:14 |
| Qiming | I'm not sure if this line is good enough: | 09:15 |
| Qiming | except sdk.exc.HttpException as ex: | 09:15 |
| xuhaiwei | in this case, we dont need to translate HttpException in the drivers i think | 09:15 |
| Yanyanhu | 404 from keystone and 404 from nova could have different meaning for enduser... | 09:15 |
| xuhaiwei | we still have error message though | 09:16 |
| Yanyanhu | if we want to translate them correctly, we also need to know the context that the exception happened, e.g. in trust middleware? or in nova.server profile | 09:17 |
| Qiming | it looks like we only handle the HttpException fro SDK | 09:17 |
| Yanyanhu | yes | 09:18 |
| xuhaiwei | Qiming, in openstacksdk the biggest exception is SDKException | 09:18 |
| xuhaiwei | maybe we should catch it first | 09:18 |
| Yanyanhu | sdk doesn't provide enought support for exception I think | 09:19 |
| Yanyanhu | in current stage | 09:19 |
| Qiming | yes, so code at this layer should do 'except Exception as ex': | 09:19 |
| Yanyanhu | based on the code of openstack/exception.py | 09:19 |
| xuhaiwei | SDKException has 9 child exception types | 09:19 |
| Qiming | Then we parse the exception type, in hope it is just a HttpException | 09:20 |
| xuhaiwei | haha | 09:20 |
| Qiming | Anyway, we "parse" or "translate" the exception at the driver layer | 09:20 |
| Yanyanhu | :) | 09:20 |
| Qiming | make them look the same way (the senlin way), then we report certain exception type (subclass of InternalError) | 09:21 |
| xuhaiwei | agree | 09:22 |
| Qiming | the invoker to the driver code will determine whether it worth expose it to the user | 09:22 |
| Yanyanhu | ok, make sense to me | 09:22 |
| Yanyanhu | since we don't have enough support from sdk, maybe the only we to ensure correctness of exception converting is let high level code do it case by case | 09:23 |
| Qiming | When forming the InternalError, we can always provide error code and message | 09:23 |
| Qiming | because we already did a format translation at the lowest layer | 09:23 |
| Qiming | again, we are always doing our best, :) | 09:23 |
| xuhaiwei | things get clear I think | 09:24 |
| Qiming | okay, suppose we have a utility function for exception handling | 09:25 |
| Qiming | we can unify the driver exception handling to something like this: | 09:25 |
| Qiming | try: | 09:26 |
| Qiming | self.conn.do_something() | 09:26 |
| Qiming | except Exception as ex: | 09:26 |
| Qiming | raise exutil.parse(ex) | 09:26 |
| Yanyanhu | looks nice | 09:27 |
| xuhaiwei | yes | 09:27 |
| Qiming | then all these ResourceNotFound, ... exception types will go away | 09:27 |
| xuhaiwei | maybe need them in the upper layer? | 09:28 |
| Yanyanhu | yes, the same question | 09:28 |
| Qiming | let's use an example here: | 09:28 |
| Qiming | say we do a flavor_get | 09:28 |
| Yanyanhu | ok | 09:29 |
| Qiming | there could be a 404, which is so .... normal | 09:29 |
| Qiming | flavor_get is invoked from nova.server profile, before creating/booting a nova server | 09:29 |
| *** hightall has quit IRC | 09:30 | |
| Qiming | server creation is part of a node_create action | 09:30 |
| *** mathspanda has quit IRC | 09:31 | |
| Qiming | the error code is not helpful in this case | 09:31 |
| xuhaiwei | in exutil.parse() we should figure out NotFoundException which is raised by SDK in this case, and then translate it to something senlin style exception in upper layer | 09:31 |
| Qiming | the only useful message is the 'message' from the InternalError (filled in by the exutil.parse() func above) | 09:32 |
| *** Zhenqi has quit IRC | 09:32 | |
| Qiming | we will kill such all exceptions related to flavor_get in the nova server profile | 09:33 |
| Qiming | save the 'message' as status_reason, mark status as FAILED and exit | 09:33 |
| Qiming | there is no user facing exceptions here | 09:33 |
| Yanyanhu | Qiming, understand what you mean about the logic. The problem is what is the output of exutils.parse(ex) | 09:34 |
| xuhaiwei | I think it should be an exception type | 09:35 |
| Yanyanhu | the input is the Exception from sdk(in most cases if we don't have other unexpected exception duing the code execution) | 09:35 |
| Qiming | an InternalError? | 09:35 |
| Yanyanhu | only one exception type? | 09:35 |
| Yanyanhu | or ResourceNotFound, ResourceCreationFailure kind of things? | 09:35 |
| xuhaiwei | yes, a senlin internalerror with error code and message | 09:36 |
| Yanyanhu | if the first one, it means exutil.parse method need to provide the logic for judging and converting exception based on its message | 09:36 |
| Qiming | that is enough | 09:36 |
| Yanyanhu | and also the context | 09:36 |
| Qiming | surely we can map them to more meaningful exception type names as is done at the client side | 09:36 |
| Qiming | http://git.openstack.org/cgit/stackforge/python-senlinclient/tree/senlinclient/common/exc.py#n263 | 09:37 |
| Qiming | context? | 09:37 |
| Qiming | you mean call stack? | 09:37 |
| Yanyanhu | yes, where the exception happened | 09:37 |
| Yanyanhu | right | 09:37 |
| xuhaiwei | Yanyanhu's meaning is we need human work here | 09:37 |
| Yanyanhu | right | 09:37 |
| Yanyanhu | this is what I mean | 09:37 |
| xuhaiwei | though we got error code and message, the method doesn't know the specific exception type | 09:38 |
| Yanyanhu | the exception_parse method in client can provide mapping and parsing, but it can judge the meaning of an exception I think | 09:38 |
| Qiming | could you please check this line: http://git.openstack.org/cgit/stackforge/python-senlinclient/tree/senlinclient/common/exc.py#n263 | 09:39 |
| Yanyanhu | yes, this line can help to make exception converting | 09:39 |
| Qiming | that was an effort to make some conversion for code readability | 09:40 |
| xuhaiwei | only by the code? | 09:40 |
| Yanyanhu | ok, so it's just responsbile for code mapping | 09:40 |
| Yanyanhu | then the output of exutils.parse is SenlinInternalError(code, msg) | 09:41 |
| Yanyanhu | something like this? | 09:41 |
| Qiming | Just SenlinInternalError | 09:41 |
| Yanyanhu | the this internal exception will be caught in profile/policy to decide whether an exception should be generated and send back to end user | 09:41 |
| xuhaiwei | that is not what we desired i am afraid | 09:42 |
| Yanyanhu | then | 09:42 |
| Qiming | the InternalError class has code and msg, that was why we have parse() method | 09:42 |
| Yanyanhu | yes, this makes sense to me | 09:42 |
| xuhaiwei | but I am confused | 09:43 |
| Qiming | ok? | 09:43 |
| xuhaiwei | in upper layer, we catch internalerror and then how to handle it | 09:43 |
| Qiming | case by case, xuhaiwei | 09:44 |
| Yanyanhu | em, this is what I'm thinking | 09:44 |
| xuhaiwei | I mean when implementing the code, I can't see the code and message | 09:44 |
| Qiming | implementing which code? | 09:46 |
| xuhaiwei | the handling code in upper layer | 09:46 |
| Qiming | say we do a flavor_get, flavor_get is invoked from nova.server profile, before creating/booting a nova server, the error code is not that useful in this case, the only useful message is the 'message' from the InternalError, we will kill such all exceptions related to flavor_get in the nova server profile, save the 'message' as status_reason, mark status as FAILED and exit | 09:47 |
| Qiming | we don't need an exception type here | 09:48 |
| Qiming | there is no further exception thrown | 09:48 |
| Yanyanhu | haiwei, I think Qiming means the SenlinInteralError itself will contain the status code | 09:49 |
| Yanyanhu | the upper layer code can get it when capture this SenlinInternalError exception | 09:49 |
| xuhaiwei | ok | 09:49 |
| xuhaiwei | and parse it again? | 09:49 |
| Qiming | the exutils.parse() function will do its best to fill in the 'code', 'message' fields | 09:50 |
| Yanyanhu | and also conatain the message since sometimes the msg should be sent back to user | 09:50 |
| Qiming | for upper layer code, the only thing they know is SenlinInternalError | 09:50 |
| Yanyanhu | xuhaiwei, yes, I think so | 09:50 |
| Qiming | either you check the code, either you use the message | 09:50 |
| Yanyanhu | and the second round parsing is case by case | 09:50 |
| Yanyanhu | e.g. by the profile/policy's logic | 09:50 |
| Qiming | they must already be there, or else why do we do parse()? | 09:50 |
| xuhaiwei | in the upper layer, mapping the exception by error message? | 09:52 |
| xuhaiwei | since the error code can be duplicated | 09:52 |
| Qiming | we may and may not need to map the exception | 09:52 |
| Yanyanhu | xuhaiwei, I think there is no mapping in upper layer, just 'human' exception handling | 09:52 |
| Qiming | it is all up to the location you are receiving the InternalError | 09:53 |
| xuhaiwei | ok | 09:53 |
| xuhaiwei | I think I got it now | 09:53 |
| Yanyanhu | hi, Qiming I think haiwei was asking whether the second round handling is automatic ;) | 09:53 |
| Yanyanhu | based on a fixed mapping | 09:53 |
| Qiming | okay, let's put another example to make this clearer | 09:53 |
| Qiming | take the flavor_get() method as an example | 09:54 |
| Qiming | if we are invoking it during node_creation handling, we don't throw exceptions, we only record status_reason | 09:54 |
| Qiming | suppose we provide a profile-validate command to user | 09:55 |
| Qiming | in that command, we will check if user provided flavor id/name does exists | 09:55 |
| Qiming | we will get an InternalError when invoking flavor_get() | 09:55 |
| Qiming | but we will decide to return a BadRequest or ValidationFailure exception to user | 09:56 |
| * Qiming is wondering whether he is making things clearer or more vague ... | 09:57 | |
| xuhaiwei | it's ok for me up to now | 09:57 |
| Qiming | the point is: we will treat the same error/exception in different ways, depending on the where you are handling it | 09:58 |
| Yanyanhu | profile/os/nova/server.py | 09:58 |
| Yanyanhu | ... | 09:58 |
| Yanyanhu | try: | 09:58 |
| Yanyanhu | ... | 09:58 |
| Yanyanhu | nova_driver.flavor_get(flavor_id) | 09:58 |
| Yanyanhu | ... | 09:58 |
| Yanyanhu | except SenlinInternalError as ex | 09:58 |
| Yanyanhu | LOG.exception(xxx) | 09:58 |
| Yanyanhu | raise SenlinBadRequest() | 09:58 |
| Yanyanhu | code in profile may looks like this? | 09:58 |
| Qiming | yes, if it is in validate() path | 09:59 |
| xuhaiwei | I think so | 09:59 |
| Yanyanhu | yes | 09:59 |
| Yanyanhu | ok, clear about it | 09:59 |
| Qiming | if it is in do_create() path, we will not raise SenlinBadRequest | 09:59 |
| Yanyanhu | yes, since it is in action progress | 10:00 |
| xuhaiwei | yes, sometime, SenlinNotFound maybe | 10:00 |
| Qiming | we have to combine quite some exception types we have today, :) | 10:01 |
| Yanyanhu | yes | 10:01 |
| Yanyanhu | may need to file a bug for this? | 10:02 |
| xuhaiwei | the fewer the better | 10:02 |
| Yanyanhu | or a blueprint? | 10:02 |
| xuhaiwei | already have a bp about the exception handling | 10:02 |
| Qiming | the author of the HTTP error code specs is a genius | 10:02 |
| Yanyanhu | haiwei, seems your scope ;) | 10:02 |
| Yanyanhu | yep | 10:02 |
| Qiming | there are not that many cases to handle | 10:03 |
| xuhaiwei | maybe not one person | 10:03 |
| Qiming | by adding new exception types, we are making our own world complicated | 10:03 |
| Yanyanhu | right | 10:03 |
| xuhaiwei | maybe some people just like the three of us | 10:03 |
| Yanyanhu | yep :) | 10:03 |
| Yanyanhu | heihei | 10:03 |
| Qiming | np | 10:04 |
| Yanyanhu | really need to wc | 10:04 |
| xuhaiwei | haha | 10:04 |
| xuhaiwei | I will write something to the exception handling bp | 10:04 |
| Yanyanhu | ok, cool | 10:06 |
| Yanyanhu | prepare to leave | 10:06 |
| Yanyanhu | I will hold the code of driver and wait for this exception parsing workitem | 10:06 |
| Yanyanhu | code of test case for driver | 10:06 |
| Yanyanhu | will leave, see U guys tomorrow | 10:09 |
| xuhaiwei | see u | 10:11 |
| *** Yanyanhu has quit IRC | 10:13 | |
| Qiming | walking home | 10:19 |
| xuhaiwei | take care | 10:22 |
| *** Qiming has quit IRC | 10:25 | |
| openstackgerrit | xu-haiwei proposed stackforge/python-senlinclient: Fix profile name update error https://review.openstack.org/204538 | 10:31 |
| *** Qiming has joined #senlin | 11:30 | |
| lixinhui_ | huge rainfall | 11:44 |
| lixinhui_ | qiming, are you caught? | 11:45 |
| Qiming | no | 11:45 |
| Qiming | @home | 11:45 |
| lixinhui_ | good to know | 11:46 |
| lixinhui_ | I need your help on nova-api | 11:47 |
| Qiming | ok? | 11:47 |
| lixinhui_ | from the debug out of nova boot, we can see the process to communicate with nova server | 11:47 |
| lixinhui_ | but still do not know how to revise openstacksdk | 11:48 |
| lixinhui_ | to reach same goal | 11:48 |
| lixinhui_ | <lixinhui_> http://paste.openstack.org/show/398867/ | 11:48 |
| lixinhui_ | <lixinhui_> but nova boot shows complete communication and message body | 11:48 |
| lixinhui_ | <lixinhui_> http://paste.openstack.org/show/389934/ | 11:48 |
| Qiming | openstacksdk transport will dump its request and response body | 11:48 |
| Qiming | ah, I see | 11:50 |
| Qiming | :) | 11:50 |
| Qiming | in senlin, there is a concept called action | 11:50 |
| Qiming | all requests, except for some resource list/get requests, are handled by actions | 11:50 |
| Qiming | actions are asynchronously executed by a worker thread inside the senlin-engine | 11:51 |
| lixinhui_ | ... | 11:51 |
| lixinhui_ | senlin log include all the messages? | 11:51 |
| Qiming | yes | 11:51 |
| Qiming | check senlin-engin log | 11:51 |
| Qiming | you won't see them from the command line | 11:52 |
| *** jruano has joined #senlin | 11:53 | |
| lixinhui_ | have you once read the code of openstacksdk? | 11:59 |
| lixinhui_ | key problem seems here | 11:59 |
| lixinhui_ | http://paste.openstack.org/show/399719/ | 12:00 |
| lixinhui_ | do you have any idea which file/files we should change to construct 'server': {}, 'os:scheduler_hints':{} | 12:01 |
| lixinhui_ | seems openstacksdk use resource to new/create new server but no separated construction available for message body | 12:02 |
| Qiming | scheduler_hints is already sent to nova | 12:08 |
| Qiming | you need to do a 'nova show' to see if it is already there | 12:09 |
| lixinhui_ | no | 12:11 |
| lixinhui_ | the hints do not work | 12:11 |
| Qiming | I am not talking about whether it works | 12:12 |
| Qiming | I mean you need to check if it is there | 12:12 |
| lixinhui_ | no, it does not occur when nova show node | 12:12 |
| lixinhui_ | http://paste.openstack.org/show/399784/ | 12:13 |
| lixinhui_ | from nova boot debug information, i feel we should construct { 'server': {}, 'os:scheduler_hints':{} } | 12:14 |
| lixinhui_ | current message is {'server': { ...'meta':{}, 'scheduler_hints':{}..}..} | 12:15 |
| Qiming | is it request or response? | 12:15 |
| lixinhui_ | request | 12:16 |
| Qiming | that means the data is passed to nova | 12:16 |
| lixinhui_ | http://paste.openstack.org/show/399719/ line 6 | 12:17 |
| *** jdandrea has joined #senlin | 12:17 | |
| lixinhui_ | compared to <lixinhui_> http://paste.openstack.org/show/389934/ line 89... | 12:19 |
| Qiming | compare what? | 12:20 |
| lixinhui_ | REQ body between openstacksdk and nova cli | 12:20 |
| lixinhui_ | we should generate nova cli similar REQ body, I think, for scheduler_hints to work | 12:21 |
| Qiming | oh no | 12:22 |
| Qiming | they have changed that interface .... | 12:22 |
| lixinhui_ | we have to reslove this for demo | 12:22 |
| lixinhui_ | placement_policy can be a simple one at this stage | 12:23 |
| *** Qiming has quit IRC | 12:25 | |
| *** Qiming has joined #senlin | 12:26 | |
| Qiming | network broken just now | 12:26 |
| lixinhui_ | oh, okay | 12:26 |
| lixinhui_ | my network often break at home | 12:26 |
| Qiming | it will be passed to nova as-is, sdk won't modify them | 12:26 |
| lixinhui_ | who change the interface | 12:26 |
| lixinhui_ | ... | 12:27 |
| Qiming | nova changed the way scheduler_hints is sent to the server | 12:27 |
| lixinhui_ | syes | 12:27 |
| lixinhui_ | yes | 12:27 |
| Qiming | they are now expecting a 'os:' prefix | 12:27 |
| lixinhui_ | because hints do not belong to server from model pespective | 12:27 |
| Qiming | checking | 12:28 |
| Qiming | http://git.openstack.org/cgit/openstack/python-novaclient/tree/novaclient/v2/servers.py#n459 | 12:30 |
| lixinhui_ | I see, but it does not work if only add OS:before scehduler_hints | 12:33 |
| lixinhui_ | since others should be [server][XX] | 12:33 |
| *** mathspanda has joined #senlin | 12:35 | |
| Qiming | ah yes | 12:44 |
| Qiming | need a change at the sdk side then | 12:44 |
| lixinhui_ | en | 12:48 |
| lixinhui_ | need your help here to understand its straucture | 12:48 |
| lixinhui_ | which file/files we should change | 12:49 |
| lixinhui_ | feel hard to do that | 12:49 |
| lixinhui_ | by check code of compute/v2/server.py and | 12:49 |
| lixinhui_ | resource.py | 12:49 |
| lixinhui_ | I am very hungry now. stomach ache whole day and I did take lunch and dinner, now feel hungry | 12:51 |
| Qiming | need to discuss with Brian and Terry | 12:52 |
| Qiming | :) | 12:52 |
| lixinhui_ | please help this as soon as possible. | 12:52 |
| Qiming | go grab some food then | 12:52 |
| Qiming | sure | 12:52 |
| *** lixinhui_ has quit IRC | 14:04 | |
| *** Qiming_ has joined #senlin | 14:30 | |
| *** Qiming has quit IRC | 14:33 | |
| *** Qiming_ has quit IRC | 14:47 | |
| *** mathspanda has quit IRC | 15:33 | |
| *** jdandrea has left #senlin | 19:18 | |
| openstackgerrit | Merged stackforge/python-senlinclient: Updated from global requirements https://review.openstack.org/204430 | 19:54 |
| openstackgerrit | Merged stackforge/senlin: Add a new exception type 'ResourceUpdateFailure' https://review.openstack.org/204443 | 20:22 |
| *** jruano has quit IRC | 21:15 | |
| *** jruano has joined #senlin | 21:19 | |
| *** Qiming_ has joined #senlin | 23:38 | |
| *** Qiming_ has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!