| *** yizhihui has joined #openstack-smaug | 00:27 | |
| *** yizhihui has quit IRC | 00:35 | |
| *** zhurong has joined #openstack-smaug | 00:36 | |
| *** yizhihui has joined #openstack-smaug | 00:40 | |
| *** LiChunyu has joined #openstack-smaug | 00:58 | |
| *** mingyu has joined #openstack-smaug | 01:18 | |
| *** yamamoto_ has joined #openstack-smaug | 02:14 | |
| *** gouthamr has quit IRC | 02:49 | |
| *** yamamoto_ has quit IRC | 04:23 | |
| *** yinwei_computer has quit IRC | 04:35 | |
| *** yamamoto_ has joined #openstack-smaug | 04:39 | |
| *** yinwei_computer has joined #openstack-smaug | 04:47 | |
| *** yamamoto_ has quit IRC | 04:49 | |
| *** yamamoto_ has joined #openstack-smaug | 05:34 | |
| *** wanghao_ has joined #openstack-smaug | 05:43 | |
| *** mingyu has quit IRC | 05:57 | |
| *** yinwei_lab has joined #openstack-smaug | 06:15 | |
| *** sparkyee has joined #openstack-smaug | 06:18 | |
| *** yuval has joined #openstack-smaug | 06:21 | |
| *** yizhihui has quit IRC | 06:22 | |
| *** yinwei_lab has quit IRC | 06:40 | |
| *** yinwei_lab has joined #openstack-smaug | 06:49 | |
| *** oshidoshi has joined #openstack-smaug | 06:55 | |
| openstackgerrit | chenying proposed openstack/python-smaugclient: Add metadata parameter to checkpoint API https://review.openstack.org/353294 | 07:00 |
|---|---|---|
| *** mingyu has joined #openstack-smaug | 07:03 | |
| *** mingyu has quit IRC | 07:04 | |
| *** mingyu has joined #openstack-smaug | 07:05 | |
| chenying_ | yuval: I plan to write a spec about database bank plugins. I have a question. Where do we save the checkpoint metadata? save these metadata to the same database smaug? Or we need define a new database instance for checkpoint metadata? | 07:14 |
| chenying_ | yuval: What's you oppion about it? | 07:14 |
| chenying_ | yuval:S/smaug/karbor | 07:14 |
| yuval | chenying_: hey, one second :) | 07:20 |
| yuval | chenying_: you speak about split the bank api to metadata api and data api? | 07:24 |
| yuval | chenying_: ? | 07:36 |
| chenying_ | yuval:I am not sure that whether need to split the bank api to metadata api and data api. I speak this scene: admin only use bank to save checkpoint metadata, don't use bank as their backup copy back-end. | 07:39 |
| chenying_ | yuval: yinwei suggest that we could split the bank api to metadata api and data api. yinwei_lab yinwei_computer | 07:40 |
| yinwei_lab | hi | 07:41 |
| yuval | hey yinwei_lab ! | 07:41 |
| yinwei_lab | per our discussion with yuval and saggi | 07:41 |
| yinwei_lab | hey, yuval! | 07:41 |
| yuval | :) | 07:41 |
| yinwei_lab | saggi prefers not split the interfaces | 07:41 |
| chenying_ | hi | 07:42 |
| yinwei_lab | and he thought a basic db based bank could cover 99% sql based database | 07:42 |
| yinwei_lab | if you have irc history, could confirm it | 07:42 |
| yuval | yinwei_lab: I'm on history looking for it | 07:43 |
| yinwei_lab | yuval, thanks | 07:43 |
| yinwei_lab | saggi's argument is that no matter whether user wants db based bank data capability or not, we just provide it to them. So he thought it's not necessary to split the bank interface | 07:45 |
| yinwei_lab | chenying, you want to propose a rst about the db based bank implementation and elaborate mainstream sql based db is compatible with it? | 07:46 |
| yinwei_lab | chengying_ | 07:46 |
| yuval | chenying_: with blobs? | 07:46 |
| yinwei_lab | I guess so | 07:46 |
| yinwei_lab | with blobs to support data persistence | 07:47 |
| chenying_ | Yes | 07:47 |
| yinwei_lab | chenying_: you want to propose a rst about the db based bank implementation and elaborate mainstream sql based db is compatible with it? | 07:47 |
| chenying_ | a basic db based bank could cover 99% sql based database. I think we could introduce the bank_database data base instance like database 'karbor' in project. | 07:48 |
| yinwei_lab | yes | 07:48 |
| chenying_ | we could add a new config endpoint in karbor.conf [bank_database] | 07:48 |
| chenying_ | connection = mysql+pymysql://root:stackdb@10.229.50.225/smaug?charset=utf8 | 07:48 |
| chenying_ | we could use the same database framework. | 07:49 |
| yinwei_lab | the connection part should be db specific, right? | 07:49 |
| chenying_ | yes | 07:49 |
| chenying_ | connection = mysql+pymysql://root:stackdb@10.229.50.225/bank_metadata?charset=utf8 | 07:49 |
| yinwei_lab | the base db class should not show mysql, right? | 07:49 |
| yinwei_lab | :) | 07:49 |
| yuval | database based bank could be non-sql database as well | 07:50 |
| openstackgerrit | gengchc2 proposed openstack/smaug: Replace assertDictEqual() with assertEqual() For smaug https://review.openstack.org/364119 | 07:50 |
| yinwei_lab | non-sql means kv based? | 07:50 |
| yuval | document store (i.e mongodb) | 07:50 |
| yinwei_lab | then we could abstract the swift based bank to a no-sql base bank class | 07:50 |
| yuval | swift is not nosql | 07:51 |
| yuval | swift is an object storage | 07:51 |
| yinwei_lab | difference is? | 07:51 |
| chenying_ | we allow admin config database instance bank_metadata in the same place with 'karbor' database instance. I think it is ok. deploy a new database system is optional. | 07:51 |
| yinwei_lab | I used to take no-sql to kv storage | 07:51 |
| yinwei_lab | chenying_, pls. go ahead to propose the rst. so we can get better about your idea | 07:53 |
| yuval | yinwei_lab: https://en.wikipedia.org/wiki/NoSQL#Types_and_examples_of_NoSQL_databases | 07:53 |
| yuval | yinwei_lab: can be a document store, kv, etc | 07:53 |
| chenying_ | Now we haven't think about no-sql database. because the requirement is only use relationship database. | 07:53 |
| yuval | chenying_: if I understand your original question right, it should be separate configurable database | 07:55 |
| chenying_ | I think the solution about no-sql/K-v database don't have any difference with swift. | 07:55 |
| yuval | chenying_: indexing | 07:55 |
| chenying_ | Swift is olso a storage about k-v. | 07:56 |
| yinwei_lab | through wiki, no-sql means not only sql. and including data structures beyond kv | 07:57 |
| yuval | chenying_: consider mongodb | 07:57 |
| yinwei_lab | The data structures used by NoSQL databases (e.g. key-value, wide column, graph, or document) are different from those used by default in relational databases, making some operations faster in NoSQL. | 07:57 |
| yinwei_lab | :) | 07:57 |
| yinwei_lab | since most no sql doesn't support acid, I always took kv as no sql | 07:58 |
| yinwei_lab | then it seems hard to support no sql in one base class :) | 07:58 |
| yinwei_lab | how about a base bank class about kv storage | 07:58 |
| yinwei_lab | then at least we could cover swift/s3 | 07:59 |
| chenying_ | it should be separate configurable database. Yes, but we also can use karbor database instance to save checkpoint metadata. | 07:59 |
| yinwei_lab | yes, could make it to save cp as well. It only means the instance of bank db is the same with API layer db. Just a special config. | 08:00 |
| yinwei_lab | guys, how about the feature: cross openstack data protection? | 08:02 |
| yuval | yinwei_lab: well? | 08:02 |
| yinwei_lab | shall we arrange a meeting on IRC to discuss this feature? | 08:02 |
| yinwei_lab | yuval, I mean deploy two/N smaugs across separate openstack sites | 08:03 |
| yinwei_lab | it seems we need solve the tenant mapping or unified authentication | 08:03 |
| yuval | yinwei_lab: yes, I understand. What exactly do you want to discuss? | 08:03 |
| yinwei_lab | not sure if there's any other issues | 08:03 |
| yinwei_lab | hmm, to identify the issues and solutions | 08:03 |
| yuval | tenant mapping? | 08:04 |
| yinwei_lab | two separate openstack | 08:04 |
| yinwei_lab | one tenant protect from openstackA and tries to restore in openstackB | 08:04 |
| chenying_ | yinwei_lab: The scene that I want to solve is that : user don't want introduce a new storage as bank back-end. They use karbor one single site. They think checkpoint metadata is just local data like plan resource in karbor database. They also don't use bank as their backup back-end. It is not necessary for them to deploy a new storage (database / swift ..) to save checkpoint metadata. | 08:05 |
| yinwei_lab | how to enable the two tenants in two openstacks to manipulate the common resources? | 08:05 |
| yuval | yinwei_lab: once tenant from site A created a checkpoint in the bank, it is visible and restoreable for any openstack site configured using the same provider | 08:06 |
| yuval | yinwei_lab: the checkpoint is not 'tagged' with the tenant who created it | 08:06 |
| yinwei_lab | then how to solve the tenant isolation? | 08:06 |
| yuval | yinwei_lab: restore should be done on the openstack site doing the actual restore | 08:07 |
| yinwei_lab | I thought it's a bug that we didn't divide checkpoints with tenants | 08:07 |
| yuval | yinwei_lab: I see your point | 08:07 |
| yinwei_lab | yes, we should consider the security issue | 08:07 |
| yuval | yinwei_lab: this issue affects single site as well | 08:08 |
| yinwei_lab | chenying_, I understand your point. Pls. go ahead to propose the rst. | 08:09 |
| yinwei_lab | yuval: why single site has this issue? | 08:09 |
| yinwei_lab | the tenant should always be able to access his own resources | 08:09 |
| yuval | yinwei_lab: tenant A creates a checkpoint, tenant B can 'see' the checkpoint tenant A has created and restore it | 08:10 |
| chenying_ | Why do we introduce bank concept? We think it the scene cross-site restoration, we need a independent storage to save checkpoint metadata(backup record). So we need consider the scene that user only use the api and plug-in mechanism of karbor. They may don't use our cross-site restoration solution. | 08:11 |
| yuval | chenying_: bank is an abstraction, first and foremost | 08:13 |
| yuval | chenying_: it is crucial for cross site | 08:13 |
| yinwei_lab | yuval, that's a bug | 08:13 |
| yinwei_lab | which I used to check with chenying_ | 08:13 |
| yinwei_lab | :) | 08:13 |
| yinwei_lab | we should fire a bug and fix it | 08:13 |
| yuval | chenying_: however, even single site need that abstraction. bank can be swift, hybrid of s3+swift, filesystem, whatever | 08:14 |
| *** mingyu has quit IRC | 08:14 | |
| yinwei_lab | chenying_:what's your point? | 08:14 |
| yinwei_lab | cross site is an invalid case? | 08:14 |
| yuval | chenying_: and having different bank plugins for different providers for single site is great too | 08:15 |
| chenying_ | yuval: having different bank plugins for different providers for single site. yes | 08:16 |
| *** wuqingyong has joined #openstack-smaug | 08:16 | |
| chenying_ | yuval: however, even single site need that abstraction. bank can be swift, hybrid of s3+swift, filesystem, whatever ----because bank is not only used for saving checkpoint metadata, is also for save backup copy. But if in one single site, user have their backup back-end, they only need a place to save backup record. They don't need introduce a new storage system like swift, hybrid of s3+swift, filesystem. | 08:21 |
| chenying_ | in our early design, checkpoint metadata is just a database table back_transation in karbor. we abstract the concept bank including the back_transation record. | 08:26 |
| *** LiChunyu has quit IRC | 08:58 | |
| *** LiChunyu has joined #openstack-smaug | 09:02 | |
| *** yinwei_lab has quit IRC | 09:06 | |
| *** yinwei_lab has joined #openstack-smaug | 09:12 | |
| *** mingyu has joined #openstack-smaug | 09:30 | |
| *** mingyu has quit IRC | 09:34 | |
| *** mingyu has joined #openstack-smaug | 09:39 | |
| *** mingyu has quit IRC | 09:57 | |
| *** mingyu has joined #openstack-smaug | 09:58 | |
| *** yinwei_lab has quit IRC | 09:59 | |
| *** yamamoto_ has quit IRC | 10:02 | |
| *** zhurong has quit IRC | 10:03 | |
| *** yinwei_lab has joined #openstack-smaug | 10:25 | |
| *** LiChunyu has quit IRC | 10:25 | |
| wuqingyong | hi, now I do 'karbor protectable-list-instances OS::Application::Database', how can I pass the type of oracle? | 10:39 |
| wuqingyong | could I use 'karbor protectable-list-instances OS::Application::Database --type oracle' ? | 10:40 |
| yuval | wuqingyong: currently we do not have OS::Application::Database protectable | 10:43 |
| *** yamamoto has joined #openstack-smaug | 10:43 | |
| wuqingyong | yuval:We're doing the protect application. | 10:45 |
| yuval | wuqingyong: you should write a new "protectable plugin" | 10:46 |
| wuqingyong | yuval: yes | 10:46 |
| wuqingyong | you see 'https://etherpad.openstack.org/p/wuqingyong' | 10:46 |
| *** yamamoto has quit IRC | 10:52 | |
| *** yamamoto has joined #openstack-smaug | 11:00 | |
| yuval | wuqingyong: seems like type is a bit confusing | 11:12 |
| yuval | wuqingyong: why have you named your database "OS::Application::Database"? | 11:14 |
| wuqingyong | yuval: we want to protect the application | 11:23 |
| wuqingyong | such as oracle,sybase,db2... | 11:23 |
| yuval | wuqingyong: and you want one protectable for all of them? why not one protectable for each? | 11:24 |
| wuqingyong | yuval: thank you very much | 11:26 |
| *** LiChunyu has joined #openstack-smaug | 11:31 | |
| *** LiChunyu has quit IRC | 11:40 | |
| *** mingyu has quit IRC | 12:09 | |
| *** yamamoto has quit IRC | 12:11 | |
| *** yamamoto has joined #openstack-smaug | 12:13 | |
| *** mingyu has joined #openstack-smaug | 12:13 | |
| *** yamamoto has quit IRC | 12:16 | |
| *** yinwei_lab has quit IRC | 12:22 | |
| *** yamamoto has joined #openstack-smaug | 12:26 | |
| *** wuqingyong has quit IRC | 12:30 | |
| *** zhurong has joined #openstack-smaug | 12:34 | |
| *** mingyu has quit IRC | 12:38 | |
| *** gouthamr has joined #openstack-smaug | 12:51 | |
| *** yamamoto has quit IRC | 12:57 | |
| *** oshidoshi has quit IRC | 13:04 | |
| *** yamamoto has joined #openstack-smaug | 13:26 | |
| *** yamamoto has quit IRC | 13:27 | |
| *** yamamoto has joined #openstack-smaug | 13:30 | |
| *** yamamoto has quit IRC | 13:32 | |
| *** yamamoto has joined #openstack-smaug | 13:33 | |
| *** yamamoto has quit IRC | 13:34 | |
| *** yamamoto has joined #openstack-smaug | 13:34 | |
| *** yamamoto has quit IRC | 13:34 | |
| *** openstackgerrit has quit IRC | 13:49 | |
| *** openstackgerrit has joined #openstack-smaug | 13:49 | |
| *** yuval has quit IRC | 13:56 | |
| *** yamamoto has joined #openstack-smaug | 14:00 | |
| *** mingyu has joined #openstack-smaug | 14:17 | |
| *** yizhihui has joined #openstack-smaug | 14:18 | |
| *** sparkyee has quit IRC | 14:20 | |
| *** zhurong has quit IRC | 14:58 | |
| *** oshidoshi has joined #openstack-smaug | 15:03 | |
| *** yamamoto has quit IRC | 15:10 | |
| *** oshidoshi has quit IRC | 15:46 | |
| *** oshidoshi has joined #openstack-smaug | 15:46 | |
| *** oshidoshi has quit IRC | 15:50 | |
| *** yamamoto has joined #openstack-smaug | 16:11 | |
| *** yamamoto has quit IRC | 16:15 | |
| *** yamamoto has joined #openstack-smaug | 16:46 | |
| *** yamamoto has quit IRC | 16:50 | |
| *** wanghao_ has quit IRC | 17:00 | |
| *** openstackgerrit has quit IRC | 18:18 | |
| *** openstackgerrit has joined #openstack-smaug | 18:18 | |
| *** mingyu has quit IRC | 19:18 | |
| *** mingyu has joined #openstack-smaug | 20:18 | |
| *** mingyu has quit IRC | 20:23 | |
| *** gouthamr has quit IRC | 20:34 | |
| *** gouthamr has joined #openstack-smaug | 21:32 | |
| *** mingyu has joined #openstack-smaug | 21:40 | |
| *** gouthamr_ has joined #openstack-smaug | 21:44 | |
| *** mingyu has quit IRC | 21:45 | |
| *** gouthamr has quit IRC | 21:47 | |
| *** mingyu has joined #openstack-smaug | 22:25 | |
| *** gouthamr_ has quit IRC | 22:53 | |
| *** gouthamr has joined #openstack-smaug | 23:10 | |
| *** gouthamr_ has joined #openstack-smaug | 23:14 | |
| *** gouthamr has quit IRC | 23:14 | |
| *** zhurong has joined #openstack-smaug | 23:48 | |
| *** zhurong has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!