| *** zhurong has joined #openstack-smaug | 01:16 | |
| *** zhonghua-lee has joined #openstack-smaug | 01:20 | |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint basic function https://review.openstack.org/328807 | 01:23 |
|---|---|---|
| *** chenhuayi has joined #openstack-smaug | 01:27 | |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint js function https://review.openstack.org/328810 | 01:32 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: implement checkpoint detail page https://review.openstack.org/328812 | 01:42 |
| *** chenpengzi has joined #openstack-smaug | 01:58 | |
| *** zhangshuai has joined #openstack-smaug | 02:13 | |
| *** zhangshuai has quit IRC | 02:16 | |
| *** zhangshuai has joined #openstack-smaug | 02:25 | |
| *** chenhuayi_ has joined #openstack-smaug | 02:31 | |
| *** zhangshuai has quit IRC | 02:33 | |
| *** chenhuayi has quit IRC | 02:34 | |
| *** chenhuayi_ has quit IRC | 02:35 | |
| *** zhurong has quit IRC | 02:35 | |
| *** zhangshuai has joined #openstack-smaug | 02:37 | |
| *** chenpengzi has quit IRC | 02:44 | |
| *** chenpengzi has joined #openstack-smaug | 02:47 | |
| *** zhurong has joined #openstack-smaug | 02:48 | |
| *** chenpengzi has quit IRC | 02:56 | |
| *** chenpengzi has joined #openstack-smaug | 02:56 | |
| *** zhurong has quit IRC | 02:58 | |
| *** chenpengzi has quit IRC | 02:59 | |
| *** zhurong has joined #openstack-smaug | 02:59 | |
| openstackgerrit | Merged openstack/smaug-dashboard: Remove unused POT file https://review.openstack.org/326848 | 03:10 |
| openstackgerrit | Merged openstack/smaug: Updated from global requirements https://review.openstack.org/325470 | 03:12 |
| openstackgerrit | Merged openstack/smaug: Add fullstack tests of the resource protectables RESTAPI https://review.openstack.org/323166 | 03:13 |
| *** zhangshuai has quit IRC | 03:49 | |
| *** zhangshuai has joined #openstack-smaug | 03:52 | |
| *** zhangshuai has quit IRC | 04:05 | |
| *** zhangshuai has joined #openstack-smaug | 04:21 | |
| *** zhangshuai_ has joined #openstack-smaug | 04:31 | |
| *** zhangshuai has quit IRC | 04:33 | |
| *** zhangshuai_ has quit IRC | 04:35 | |
| *** zhangshuai_ has joined #openstack-smaug | 04:40 | |
| *** zhangshuai_ has quit IRC | 04:45 | |
| *** zhangshuai_ has joined #openstack-smaug | 04:45 | |
| *** yuval has joined #openstack-smaug | 04:56 | |
| yuval | Hello everybody | 04:57 |
| yuval | ping chenying__ | 05:46 |
| *** gsagie has joined #openstack-smaug | 05:57 | |
| gsagie | chenying__ : just so you know, if you want to start working on Dragonflow we will always accept you! | 06:07 |
| gsagie | For us, you are the missing Dragon | 06:08 |
| *** gampel has joined #openstack-smaug | 06:15 | |
| gsagie | yuval: same for you.. | 06:16 |
| gsagie | we have 2 Dragon spots | 06:17 |
| chenying__ | Hi | 06:19 |
| chenying__ | Hi <yuval> <gsagie> How are you? | 06:19 |
| yuval | hey chenying__ | 06:27 |
| yuval | how are you? | 06:27 |
| chenying__ | Fine | 06:27 |
| yuval | would you mind if I'll make some minor English corrections to your patch? | 06:28 |
| chenying__ | I have addressed you comment. If you want, you could update the usage example in this patch.https://review.openstack.org/#/c/327730/ I will abandon my patch. | 06:28 |
| yuval | chenying__: no need for you to abandon the patch | 06:30 |
| yuval | chenying__: just minor english corrections | 06:30 |
| chenying__ | Ok You could update the patch. | 06:30 |
| yuval | thanks :) | 06:31 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Add a usage example for smaug https://review.openstack.org/328712 | 06:32 |
| openstackgerrit | Merged openstack/smaug-dashboard: make breadcrumb consistent with horizon https://review.openstack.org/328737 | 06:33 |
| yuval | chenying__: btw, I saw you passed the cinder delete patch. I thought we said the actual deletion of checkpoints is done by the garbage collector | 06:34 |
| chenying__ | actual deletion of checkpoints is done by the garbage collector is not included in that patch. I think a new patch should be submitted. | 06:34 |
| gsagie | chenying__: in Dragonflow no one will send english corrections of your patches, just saying! | 06:39 |
| chenying__ | gsagie :Ok, I see. | 06:45 |
| gsagie | chenying__: just kidding :) yuval always tells me how you are very good contributor and i am trying to get some good patches to Dragonflow as well :) | 06:46 |
| chenying__ | :) | 06:48 |
| *** zhangshuai_ has quit IRC | 06:53 | |
| *** gsagie has left #openstack-smaug | 06:56 | |
| *** zengchen has quit IRC | 07:03 | |
| *** c00281451 has joined #openstack-smaug | 07:04 | |
| yinwei_computer | yuval, sorry, I didn't get why checkpoints are deleted by GC | 07:25 |
| yuval | consider one protection service restoring from a checkpoint, while another deletes | 07:26 |
| yuval | for example | 07:26 |
| yinwei_computer | I recalled the initial design for GC is to collect only those zombie checkpoints | 07:26 |
| yuval | what is a zombie checkpoint? | 07:26 |
| yuval | (does it look for brains to eat? :) ) | 07:27 |
| yinwei_computer | for your case, the checkpoint is not allowed to be deleted while it's restoring | 07:27 |
| yinwei_computer | that's why we put restore status in checkpoint, same as cinder backup | 07:27 |
| yuval | didn't we already agree that we don't put a restore status in the checkpoint? | 07:28 |
| yinwei_computer | but even we have restore to maintain this status, we still need API service to do some status checking | 07:28 |
| yinwei_computer | you could refer the lease design doc | 07:29 |
| yuval | I know it, can't see how it is related | 07:29 |
| yinwei_computer | where we described which case should be handled by API status checking, while which are handled by lease timedout and GC | 07:29 |
| yuval | yinwei_computer: wait a second. regarding the 'protecting' status in checkpoint - do we agree that such status should not exist? | 07:34 |
| yinwei_computer | no | 07:35 |
| yinwei_computer | why | 07:35 |
| yuval | 1. because checkpoints are immutable | 07:35 |
| yinwei_computer | protecting is valid, I agree to move restore status somewhere else. | 07:35 |
| yinwei_computer | checkpoints are immutable only when it becomes available | 07:35 |
| yuval | 2. what if two restores happen from the same checkpoint? who decides when to turn the status back to 'available'? | 07:35 |
| yinwei_computer | protecting, not restoring | 07:36 |
| yinwei_computer | the status is protecting->available->deleting->deleted | 07:36 |
| yuval | I meant 'restoring', my bad | 07:36 |
| yinwei_computer | ok | 07:36 |
| yinwei_computer | np | 07:36 |
| yinwei_computer | we're on the same page then | 07:37 |
| yuval | yinwei_computer: wait a second. regarding the 'restoring' status in checkpoint - do we agree that such status should not exist? | 07:37 |
| yuval | (sorry for that) | 07:37 |
| yinwei_computer | yes, I agree to move restoring to restore object | 07:37 |
| yinwei_computer | that's ok. | 07:37 |
| yuval | great | 07:37 |
| yuval | so, how do we prevent deletion of a checkpoint that is currently restoring? | 07:37 |
| yinwei_computer | zombie checkpoints are those protecting checkpoints which actually hang | 07:38 |
| yinwei_computer | yes, that checking work could be done by API | 07:38 |
| yinwei_computer | and we can make decision in frontend request handling | 07:38 |
| yinwei_computer | I don't see the point to have GC check all checkpoints in background | 07:39 |
| yuval | what if a restore hangs? that no one can delete the checkpoint? | 07:39 |
| yuval | *then no one | 07:39 |
| yinwei_computer | then it looks to me that we need lease for restore as well. | 07:39 |
| yuval | Ok, I understand you | 07:40 |
| yinwei_computer | only maintain status in checkpoint seems much simpler :( | 07:40 |
| yuval | but it doesn't work well for multiple concurrent restores | 07:41 |
| yinwei_computer | hmm, how does cinder backup work? | 07:41 |
| yinwei_computer | which looks to me the same :) | 07:42 |
| yinwei_computer | np | 07:43 |
| yinwei_computer | we could have restore to keep lease on checkpoint as well | 07:44 |
| yinwei_computer | so the lease becomes to reference instead of 0/1 | 07:44 |
| *** yamamoto_ has joined #openstack-smaug | 07:44 | |
| yinwei_computer | and delete checkpoint rpc will fail if the lease reference is non zero. | 07:44 |
| yinwei_computer | GC will check checkpoint lease existence to update zombie protecting checkpoints to error status and thus delete them; while GC will also verify zombie restoring restores lease reference on checkpoint, and thus update restore status to error and recycle restores. | 07:48 |
| yinwei_computer | how about this? | 07:48 |
| yinwei_computer | GC only check zombie checkpoint and restore, and recycle them. | 07:49 |
| yinwei_computer | delete checkpoint validity is maintained both by checkpoint status and lease references. | 07:49 |
| yinwei_computer | yuval? | 07:49 |
| yinwei_computer | what do you think, chenying__ | 07:50 |
| * yuval reading | 07:50 | |
| *** saggi1 has joined #openstack-smaug | 07:52 | |
| yuval | yinwei_computer: cinder backup has a 'restoring' status, so I'm not sure it is a good example | 07:53 |
| yuval | yinwei_computer: the plus of marking the checkpoint as 'deleted' and delete later using GC, is that delete is immediate, and the cleanup is done later | 07:54 |
| yuval | if restore takes a lease - this inherently means there will be only 1 concurrent restore, which takes us back to the simpler approach of setting 'protecting' status in the checkpoint | 07:55 |
| chenying__ | I have missed lots of discussion. | 07:57 |
| yinwei_computer | yuval, each restore takes one lease | 07:58 |
| yinwei_computer | to check if the checkpoint is deleatable, we check the lease dir is empty or not | 07:59 |
| yinwei_computer | even if one restore is on-going, the lease dir is not empty, and the lease reference on the checkpoint is not none | 07:59 |
| yinwei_computer | wait for a moment, let me see how to map this to current lease mechanism | 08:01 |
| *** c00281451 is now known as zengchen | 08:07 | |
| chenying__ | yuval Do we realy need actual deletion of checkpoints? If we delete checkpoint, we can not get the protection history log? | 08:07 |
| yuval | chenying__: didn't understand you | 08:11 |
| yuval | yinwei_computer: deleting the checkpoint can immediately turn the checkpoint status to 'deleting'. the GC will run immediately or periodically (doesn't really matter for now). it will check if there is a restore lease for this checkpoint. once there is not, it will perform the actual deletion of the checkpoiint | 08:13 |
| saggi1 | chenying__: We can leave the index file, but this might end up clogging up the object store. We might just want to put history in the local database. | 08:15 |
| chenying__ | I mean the index file or the checkpoint records. | 08:16 |
| saggi1 | if we keep it in the bank it's the checkpoint index file if we only keep the db records than the record. | 08:19 |
| openstackgerrit | Merged openstack/smaug: Add list function to scheduled operation log https://review.openstack.org/323648 | 08:31 |
| chenying__ | Saggi What about the operation_log API? Can we record the protection action log to operation_log db. Now we only can get the protection history log from the checkpoint data. | 08:33 |
| zengchen | hi, guys, please review thses two patches, thanks! https://review.openstack.org/323722, https://review.openstack.org/309898 | 08:33 |
| *** zhangshuai has joined #openstack-smaug | 08:41 | |
| openstackgerrit | zhangshuai proposed openstack/smaug-dashboard: create protection plan js function https://review.openstack.org/328765 | 09:08 |
| openstackgerrit | zhangshuai proposed openstack/smaug-dashboard: implement protection plan detail page https://review.openstack.org/328766 | 09:13 |
| yinwei_computer | yuval, I mean we can have protection service+API service to accept or refuse delete as the first layer. If they find the checkpoint is delete-able, then go ahead delete it. Otherwise, just refuse it. | 09:26 |
| yinwei_computer | The case for the checkpoint NOT delete-able, it could be protecting, reference>0 (restoring). | 09:27 |
| yinwei_computer | what GC does is to check those NOT delete-able checkpoints and verify if thery're actually not delete-able. It will correct the status of checkpoint and restore. | 09:28 |
| yinwei_computer | Not sure if we will have GC to recycle those error restores and checkpoints. Or we only have GC correct their status and leave user to decide delete them or not. | 09:29 |
| yinwei_computer | say, user tries to delete checkpoint at t1, but actually it is protecting or udner restoring. Shall we just refuse delete? or we need persist the delete 'intent' and wait to delete the checkpoint until all references gone (GC to recycle it)? | 09:33 |
| yinwei_computer | per my understanding, I prefer option 1. Just refuse it to tell it's under use. Have a try next time. We will correct wrong status(if there's any) and allow you to delete next time. Here we use GC to correct status. | 09:34 |
| yinwei_computer | saggi1 and yuval: pls. check the nova protection plugin and list checkpoints patch | 09:35 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix default provider config for fullstack https://review.openstack.org/328927 | 09:46 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint basic function https://review.openstack.org/328807 | 09:54 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint js function https://review.openstack.org/328810 | 09:55 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: implement checkpoint detail page https://review.openstack.org/328812 | 09:57 |
| *** zhangshuai_ has joined #openstack-smaug | 10:00 | |
| *** zhangshuai has quit IRC | 10:00 | |
| *** zhurong has quit IRC | 10:03 | |
| *** zhangshuai_ has quit IRC | 10:06 | |
| *** zhangshuai_ has joined #openstack-smaug | 10:06 | |
| *** zhangshuai_ has quit IRC | 10:11 | |
| *** yamamoto_ has quit IRC | 10:19 | |
| *** yinwei_computer has quit IRC | 10:20 | |
| *** yinwei_computer has joined #openstack-smaug | 10:21 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix default provider config for fullstack https://review.openstack.org/328927 | 10:32 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: devstackgaterc for controlling fullstack config https://review.openstack.org/328941 | 10:47 |
| chenying__ | hi yuval | 11:01 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: devstackgaterc for controlling fullstack config https://review.openstack.org/328941 | 11:27 |
| yuval | chenying__: hey | 11:27 |
| chenying__ | I note that you configure the config of swift_client in your patch. Does it work? | 11:29 |
| yuval | chenying__: nope | 11:30 |
| yuval | chenying__: on it | 11:30 |
| *** yamamoto has joined #openstack-smaug | 11:33 | |
| *** zhurong has joined #openstack-smaug | 11:36 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix default provider config for fullstack https://review.openstack.org/328927 | 11:38 |
| chenying__ | I plan to configure swift_client in devstack\plugin.sh. If it work, I need't submit the patch. | 11:38 |
| yuval | chenying__: I didn't understand | 11:40 |
| chenying__ | I plan to configure swift_client like this. | 11:41 |
| chenying__ | echo "Configuring Swift Client" | 11:41 |
| chenying__ | # Configure Swift Client | 11:42 |
| chenying__ | iniset $SMAUG_PROVIDER_CONF swift_client swift_auth_url | 11:42 |
| chenying__ | ${KEYSTONE_AUTH_PROTOCOL}://${KEYSTONE_AUTH_HOST}:5000/v2.0/ | 11:42 |
| chenying__ | iniset $SMAUG_PROVIDER_CONF swift_client swift_auth_version 2 | 11:42 |
| chenying__ | iniset $SMAUG_PROVIDER_CONF swift_client swift_user $admin_user | 11:42 |
| chenying__ | iniset $SMAUG_PROVIDER_CONF swift_client swift_key $SERVICE_PASSWORD | 11:42 |
| chenying__ | iniset $SMAUG_PROVIDER_CONF swift_client swift_tenant_name $admin_user | 11:42 |
| yuval | great, I was about to do the same | 11:43 |
| *** yamamoto has quit IRC | 11:44 | |
| yuval | chenying__: you can submit that if you like. I suggest that you wait for the fullstack to pass successfully on https://review.openstack.org/328927 , I will then abandon it | 11:45 |
| chenying__ | Ok I will submit it soon. | 11:47 |
| yuval | just note that the swift_user is 'swift', the password is 'secretservice' and the tenant name is 'service' | 11:49 |
| yuval | chenying__: these are the configuration currently set in the patch I've submitted. If fullstack passes, you should use them | 11:50 |
| yuval | chenying__: could you review my docs patch: https://review.openstack.org/327730 ? | 11:51 |
| chenying__ | I reviewed it yestoday. I think it is good. It can be merged. | 11:53 |
| *** yamamoto has joined #openstack-smaug | 11:53 | |
| yuval | chenying__: and this one https://review.openstack.org/328941 | 11:55 |
| chenying__ | yuval The defaut password of swift in jenkins devstack is secretservice? Where these vaules come from? | 12:06 |
| chenying__ | If these config are fixed values, I think your patch is better. | 12:07 |
| *** yamamoto has quit IRC | 12:13 | |
| zengchen | yuval:could you please review thses two patches at your free time, they are important for operation engine. thanks! https://review.openstack.org/323722, https://review.openstack.org/309898. | 12:16 |
| chenying__ | ping saggi1 | 12:17 |
| chenying__ | I note that these is a comment about the mission of smaug in the big-tent patch. Have you seen it? | 12:19 |
| chenying__ | But I don't think the description is fine. | 12:22 |
| saggi1 | chenying__: I'll fix the description | 12:26 |
| openstackgerrit | chenying proposed openstack/smaug: Add Swift client configuration for provider config https://review.openstack.org/328982 | 12:28 |
| yuval | chenying__: credentials I gave you didn't pass | 12:30 |
| chenying__ | swift_user $admin_user swift_key $SERVICE_PASSWORD swift_tenant_name $admin_user Have you test these values? | 12:31 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint basic function https://review.openstack.org/328807 | 12:33 |
| chenying__ | could you help me do a test about the patch? The network is slow. Installing a devstack need several hours here. | 12:35 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: restore checkpoint js function https://review.openstack.org/328810 | 12:35 |
| chenying__ | https://review.openstack.org/328982 | 12:35 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: docs: update mission statement, diagram, toc https://review.openstack.org/327730 | 12:38 |
| yuval | chenying__: it depends on the credentials of devstack-gate | 12:38 |
| yuval | chenying__: see openstack-infra/devstack-gate | 12:39 |
| yuval | devstack-vm-gate.sh | 12:39 |
| openstackgerrit | chenpengzi proposed openstack/smaug-dashboard: implement checkpoint detail page https://review.openstack.org/328812 | 12:40 |
| yuval | chenying__: (btw, try to mention me when you message, so I could see the notification) | 12:41 |
| chenying__ | yuval: I configure the swift client using keystone Auth values. | 12:41 |
| yuval | chenying__: are you sure these are the keystone values for the gate's devstack? | 12:42 |
| yuval | (look here for example: http://logs.openstack.org/27/328927/3/check/gate-smaug-dsvm-fullstack-nv/0ee34c8/logs/devstack-early.txt.gz ) | 12:42 |
| chenying__ | yuval : Yes. You can see the function configure_auth_token_middleware in the file devstack\lib\keystone. | 12:44 |
| chenying__ | yuval. But we also need do a test about it. | 12:45 |
| *** yamamoto has joined #openstack-smaug | 12:46 | |
| *** yamamoto has quit IRC | 12:47 | |
| yuval | chenying__: patch failed | 12:53 |
| *** yamamoto has joined #openstack-smaug | 12:56 | |
| *** yamamoto has quit IRC | 12:57 | |
| *** yamamoto has joined #openstack-smaug | 13:13 | |
| *** yamamoto has quit IRC | 13:16 | |
| *** yamamoto has joined #openstack-smaug | 13:28 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix default provider config for fullstack https://review.openstack.org/328927 | 13:29 |
| *** yamamoto has quit IRC | 13:31 | |
| *** yamamoto has joined #openstack-smaug | 13:32 | |
| *** yamamoto has quit IRC | 13:48 | |
| *** gsagie has joined #openstack-smaug | 13:50 | |
| gsagie | zengchen!!! | 13:50 |
| *** yamamoto has joined #openstack-smaug | 13:54 | |
| *** yamamoto has quit IRC | 14:24 | |
| *** zhurong has quit IRC | 14:25 | |
| *** yamamoto has joined #openstack-smaug | 14:25 | |
| *** yamamoto has quit IRC | 14:28 | |
| *** yamamoto has joined #openstack-smaug | 14:32 | |
| *** yamamoto has quit IRC | 14:35 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Fix default provider config for fullstack https://review.openstack.org/328927 | 14:40 |
| *** yamamoto has joined #openstack-smaug | 14:49 | |
| *** yamamoto has quit IRC | 14:53 | |
| *** yuval has quit IRC | 14:55 | |
| *** yamamoto has joined #openstack-smaug | 14:56 | |
| *** yamamoto has quit IRC | 15:05 | |
| *** yamamoto has joined #openstack-smaug | 15:07 | |
| *** yamamoto has quit IRC | 15:10 | |
| *** yamamoto has joined #openstack-smaug | 15:12 | |
| *** yamamoto has quit IRC | 15:17 | |
| *** xiangxinyong has quit IRC | 15:46 | |
| *** xiangxinyong has joined #openstack-smaug | 15:46 | |
| *** saggi1 has quit IRC | 16:07 | |
| *** smcginnis has quit IRC | 16:58 | |
| *** smcginnis has joined #openstack-smaug | 16:58 | |
| *** saggi has joined #openstack-smaug | 17:19 | |
| *** saggi has quit IRC | 17:26 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/smaug-dashboard: Updated from global requirements https://review.openstack.org/323032 | 21:56 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!