| *** zhurong has quit IRC | 00:04 | |
| *** yizhihui has joined #openstack-smaug | 00:22 | |
| *** zhurong has joined #openstack-smaug | 01:09 | |
| *** zhurong_ has joined #openstack-smaug | 02:19 | |
| *** zhurong has quit IRC | 02:23 | |
| *** zhongjun_ has quit IRC | 02:34 | |
| *** zhurong_ has quit IRC | 02:39 | |
| *** zhurong has joined #openstack-smaug | 02:39 | |
| *** zhongjun_ has joined #openstack-smaug | 02:55 | |
| openstackgerrit | xiangxinyong proposed openstack/smaug: Fix plan parameters verify exception https://review.openstack.org/356198 | 03:11 |
|---|---|---|
| *** zhurong has quit IRC | 03:35 | |
| *** zhurong has joined #openstack-smaug | 03:36 | |
| *** zhurong has quit IRC | 04:14 | |
| *** zhurong has joined #openstack-smaug | 04:16 | |
| *** mingyu has joined #openstack-smaug | 05:44 | |
| *** mingyu has quit IRC | 05:45 | |
| *** mingyu has joined #openstack-smaug | 05:49 | |
| *** yinwei_computer has joined #openstack-smaug | 06:37 | |
| *** yuval has joined #openstack-smaug | 06:43 | |
| yinwei_computer | hi, yuval | 06:52 |
| yuval | yinwei_computer: hey :) | 06:52 |
| *** yinwei_computer has quit IRC | 06:53 | |
| *** yinwei_computer has joined #openstack-smaug | 06:55 | |
| *** yinwei_computer has quit IRC | 06:56 | |
| *** yinwei_computer has joined #openstack-smaug | 06:59 | |
| *** gouthamr has quit IRC | 07:00 | |
| *** mingyu has quit IRC | 07:02 | |
| *** yinwei_computer has joined #openstack-smaug | 07:04 | |
| yinwei_computer | ping yuval | 07:04 |
| yuval | ping yinwei_computer | 07:04 |
| yinwei_computer | sorry, my network seems not stable | 07:05 |
| yinwei_computer | did I miss your answer? | 07:05 |
| yinwei_computer | I just asked is there any conclusion about the bank&db issue? | 07:05 |
| yuval | I didn't get any question | 07:06 |
| yuval | yinwei_computer: saggi has posted https://review.openstack.org/356011 | 07:06 |
| yinwei_computer | thanks, yuval. I will check this patch. | 07:07 |
| yinwei_computer | I see what you guys argued is whether we can replace the object storage based bank to db based bank | 07:08 |
| yinwei_computer | is there any question about this issue? | 07:08 |
| yinwei_computer | yuval, if the problem is some protection plugin will store data in bank, is it possible to divide existed bank interface into two interfaces: md_bank and data_bank? | 07:11 |
| yinwei_computer | and each protection plugin should claim explicitly what banks they rely on in plugin conf. We can have protection plan creation to check the match of system bank and the requirment of the protection plugin. | 07:11 |
| yinwei_computer | we could also have protection plugin initialization to check if the required bank (banks) are loaded in the system. | 07:12 |
| yinwei_computer | pls check if this is feasible when you're available | 07:16 |
| *** mingyu has joined #openstack-smaug | 07:19 | |
| *** mingyu has quit IRC | 07:23 | |
| openstackgerrit | xiangxinyong proposed openstack/smaug-dashboard: Rename Smaug Dashboard to Karbor https://review.openstack.org/356279 | 07:26 |
| openstackgerrit | zengchen proposed openstack/smaug: Support only one time format for time trigger https://review.openstack.org/356284 | 07:31 |
| yuval | yinwei_computer: sorry, I'm back | 07:38 |
| yuval | yinwei_computer: the question was what to do in a single site deployment where you don't want additional components such as swift | 07:39 |
| yuval | yinwei_computer: (considering you don't use a protection plugin that stores the data in the bank) | 07:39 |
| yuval | yinwei_computer: splitting the bank interface is a good idea imo | 07:40 |
| yuval | yinwei_computer: (that's what saggi has in the above patch) | 07:40 |
| saggi | Who is talking about me ?? | 07:41 |
| saggi | :) | 07:41 |
| yinwei_computer | hi, saggi | 07:41 |
| saggi | yinwei_computer: How is it going? It's been a while. We don't see you in meetings anymore. | 07:42 |
| yuval | yinwei_computer: making protection plugins explicitly list the supported banks is problematic. Once a bank plugin interface is implemented, karbor and the protection plugins can rely on it | 07:42 |
| yinwei_computer | sorry, I take leaves last month. I will try to attend meetings on time :) | 07:43 |
| yinwei_computer | sorry yuval, I didn't see the problem to make protection plugins explicitily claim the bank interfaces they rely on. | 07:44 |
| yinwei_computer | could you elaborate it? | 07:44 |
| openstackgerrit | Saggi Mizrahi proposed openstack/smaug: Bank indexing interface https://review.openstack.org/356011 | 07:45 |
| yuval | yinwei_computer: lets say we have swift bank plugin, s3 bank plugin, and a protection plugin that explicitly relies on both | 07:45 |
| yuval | yinwei_computer: tomorrow I release a ceph bank plugin, and you can't use it until you manually tell the protection plugin to rely on it | 07:45 |
| yinwei_computer | hmm, there's some misunderstanding | 07:46 |
| yinwei_computer | I think what protetion plugins relying on are md_bank_interface and data_bank_interface. | 07:46 |
| yinwei_computer | protection plugins should not care about the implementation under md_bank_interface and data_bank_interface; | 07:47 |
| saggi | yinwei_computer: We can't have a way for a bank to not work with a certain bank implementation. | 07:47 |
| yinwei_computer | saggi, I didn't get it. | 07:48 |
| yinwei_computer | is it possible to have ceph as data_bank_plugin and swift as md_bank_plugin? | 07:48 |
| yinwei_computer | imho, it's feasible. | 07:49 |
| saggi | yinwei_computer: Let me just check that I'm understanding everything. You want to split the bank interface to mb_bank_interface and data_bank_interface where one is responsible for the checkpoint md and the other contains blobs. | 07:49 |
| saggi | right? | 07:49 |
| yinwei_computer | and it's also possible that there is only md_bank_plugin | 07:49 |
| yinwei_computer | yes | 07:49 |
| yinwei_computer | one for checkpoint and the other for data | 07:50 |
| saggi | This is where the problem starts. If you have a protection plugin that needs the data bank it will not work. That is problematic. | 07:50 |
| yinwei_computer | why it doesn't work? | 07:50 |
| saggi | We can only consider if having a data implementation is mandatory | 07:50 |
| yinwei_computer | each data bank should comply with the interface, right? | 07:50 |
| saggi | since it depends on the data_bank | 07:50 |
| saggi | So you must define a data_bank | 07:51 |
| saggi | ? | 07:51 |
| yinwei_computer | if it depends on the data_bank, it should claim this in plugin.conf or in its requirement. So plan creation will check its requirment. | 07:52 |
| yinwei_computer | it depends on the data_bank_interface. | 07:52 |
| saggi | If we implement https://review.openstack.org/#/c/355956/ there is no reason why someone can not have a data_bank. | 07:52 |
| yinwei_computer | it only calls the interface | 07:52 |
| *** mingyu has joined #openstack-smaug | 07:53 | |
| saggi | yinwei_computer: Why would anyone not have a data_bank? | 07:54 |
| yinwei_computer | saggi, I think one implementation could both implement md_bank and data_bank | 07:54 |
| saggi | yinwei_computer: obviously, that is what we have now | 07:55 |
| yinwei_computer | or only implement md_bank | 07:55 |
| yinwei_computer | as zhonghua has told that, to adapt more user cases | 07:55 |
| saggi | What is the use case | 07:56 |
| yuval | saggi: as we discussed yesterday, single site with no swift deployment | 07:56 |
| yinwei_computer | afak, most users have already got their backup system, so they could backup data across their own backup system | 07:56 |
| yinwei_computer | smaug will manage the DP over the openstack | 07:57 |
| yinwei_computer | they used to backup volumes/vms manually | 07:57 |
| * saggi is thinking about it | 07:57 | |
| yuval | yinwei_computer: images? | 07:57 |
| *** mingyu has quit IRC | 07:57 | |
| yinwei_computer | same as images | 07:57 |
| yinwei_computer | now, glance backend could be shareable as well | 07:58 |
| yinwei_computer | that's what openstack provided before | 07:58 |
| yinwei_computer | so if these users try to adopt smaug, they will find it's nice to use smaug to manage whole DR life cycle. But they don't rely on smaug to replicate/store data. | 07:59 |
| yinwei_computer | in this way, they would prefer a db based bank (md bank only). And db is the on premise software they already have. | 08:01 |
| saggi | yinwei_computer: The thing that I don't understand is what is the point. You don't *have* to save data in the bank and it doesn't add any overhead to allow that. | 08:01 |
| saggi | yinwei_computer: So the main issue is having a DB as a bank | 08:01 |
| saggi | This causes two issues. 1. We purposefully don't define a schema for the data since old checkpoints should be recoverable from old versions. 2. It's hard to put blobs in a DB. | 08:02 |
| yinwei_computer | I think we should allow a smaug with customized protection plugins to run without data-bank, where those protection plugins don't refer data-bank and the customers don't want to run any data-bank system. | 08:03 |
| saggi | We should remember to start saying Karbor :) | 08:03 |
| yinwei_computer | saggi, sorry, what's data blob in checkpoint? | 08:04 |
| yinwei_computer | I might miss sth. here. | 08:04 |
| saggi | blob - binary large object. An image chunk for example. | 08:04 |
| yuval | yinwei_computer: you could write a 'null' bank plugin | 08:08 |
| saggi | yinwei_computer: MySql, and Postgres have BLOB support. | 08:09 |
| saggi | [1] https://www.postgresql.org/docs/9.1/static/datatype-binary.html | 08:09 |
| saggi | [2] https://dev.mysql.com/doc/refman/5.7/en/blob.html | 08:09 |
| saggi | And if those code paths would not be used very much we can leave them inefficient. | 08:10 |
| saggi | So we can have a full bank where using the data_bank is just not recommended | 08:10 |
| yinwei_computer | But in the case I told before, protection plugin doesn't have such requirement to store image chunk into bank. | 08:11 |
| yinwei_computer | say, they already store image to some file share system. | 08:11 |
| yinwei_computer | so my question is: shall we allow one smaug instance run without data_bank? | 08:12 |
| chenying | divide existed bank interface into two interfaces: md_bank and data_bank. sound it is a good idear. | 08:12 |
| yuval | yinwei_computer: even if we don't, you can write a 'null data bank plugin' | 08:13 |
| saggi | yuval, how would it behave? Would it throw and error or silently do nothing? | 08:14 |
| yuval | saggi: silently do nothing. just an example | 08:14 |
| saggi | The thing I'm worried about is people misconfiguring and have it just not do what it claims to do. | 08:15 |
| saggi | It's hard to avoid that but we can at least try | 08:15 |
| yinwei_computer | if there's a null data bank plugin, plan creation will report error if it finds the provider protection plugin requires data bank plugin but there's only a null one? | 08:15 |
| yinwei_computer | so the requirement is not in conf, but in code | 08:16 |
| yinwei_computer | each protection plugin implements its bank_requirement | 08:16 |
| yinwei_computer | so api layer could check it when plan creation | 08:16 |
| yinwei_computer | actually, we need multiple checking in plan creation to match resources and protection plugins. | 08:17 |
| saggi | yinwei_computer: What is the problem with implementing blobs in with the DB and just have people that don't use it just not use it? | 08:23 |
| saggi | It seems simpler | 08:23 |
| yinwei_computer | but not flexible :( | 08:24 |
| yinwei_computer | what if the user's on premise db doesn't support blob? | 08:24 |
| yinwei_computer | since the md-bank sometimes also needs to be customized | 08:25 |
| yuval | yinwei_computer: in the end of the day, the user is storing a blob somewhere when he backs up an image or a volume | 08:25 |
| yuval | yinwei_computer: it might be swift, ceph, cinder or anything else, but the data will be stored | 08:25 |
| yinwei_computer | yes, they store them with their on premise devices | 08:26 |
| yinwei_computer | they only adopt smaug for dr control | 08:26 |
| yinwei_computer | not data | 08:26 |
| yuval | great, so use protection plugins which don't store data in the bank | 08:26 |
| yuval | but a data bank plugin is a must. and you do have a backend in your deployment, otherwise you had no place for the image/volume backups | 08:27 |
| yinwei_computer | yes, but we need a check | 08:27 |
| yuval | check what/ | 08:27 |
| yuval | ? | 08:27 |
| saggi | yinwei_computer: I think all supported databases all support BLOBS. And if it doesn't you can make a DB\FS hybrid easily. | 08:27 |
| yinwei_computer | what's the point if I don't use it but I must have one? | 08:28 |
| yinwei_computer | have data bank plugin means I need run this backend and I need implement a data bank plugin for it | 08:28 |
| yinwei_computer | what's the point to do it if I don't need it? | 08:28 |
| saggi | But if you are 90% of people and use Swift\FS\MySql\Posgres\Mongo\Couchbase\Sqlite and countless more you *will* have it implemented with zero overhead. | 08:29 |
| saggi | I think it's 99% | 08:29 |
| yinwei_computer | why the overhead is 0? | 08:30 |
| saggi | It doesn't require another service | 08:30 |
| yinwei_computer | we will provide all of those db implementations for data bank interface? | 08:30 |
| saggi | We will not split the bank up. | 08:31 |
| yuval | btw, if we want to split bank into md_bank and data_bank, why not store the md in karbor's db? | 08:31 |
| saggi | This will mean that you don't have to check if the user has a data_bank all around the code | 08:31 |
| yinwei_computer | or customer need develop their own data bank based on the db they are using? | 08:31 |
| saggi | and if the user sees that the bank isn't handling all the blobs it can change the bank or change the protection plugin | 08:31 |
| saggi | yinwei_computer: I don't think we should make all that code for the 0.1% that don't use any of the mainstream databases. | 08:32 |
| yinwei_computer | saggi, the problem is customer need develop their own data bank based on the db they are using, but they don't use the data-bank at all | 08:32 |
| yinwei_computer | why would they put these efforts? | 08:32 |
| yuval | how will the bank plugin know what is data and what is metadata if we don't split the bank? | 08:33 |
| yuval | (what to store in blob and what not to) | 08:33 |
| saggi | yinwei_computer: They will probably not need to develop one since if it's relational it just uses SQL. If it's an object\document store it doesn't matter | 08:33 |
| yinwei_computer | we split bank into 2 interfaces, and thus protection plugins will explicitly call data and md interfaces. The interface will tell them to know this context @yuval | 08:34 |
| saggi | yinwei_computer: I agree, we should add blob specific APIs. | 08:35 |
| saggi | So that the implementation can know if it's indexable or not. | 08:35 |
| yinwei_computer | saggi, I'm not sure if the blob related semantics are the same. But at lease they need test if the database complies with the 'generic' data bank plugin. | 08:36 |
| yinwei_computer | least | 08:36 |
| chenying | I also think data bank interface is optional. Verdor's plugins may use their own solution write the backup data to their backup backend. Like some backup software verdor. they don't need additional data bank interface. | 08:37 |
| yinwei_computer | the point is, customer would say I don't need it, why there's no option to get rid of this. I don't want to put any effort there. | 08:38 |
| saggi | yinwei_computer, chenying: I'm not disagreeing with the assertion that some users don't need to store blobs in the bank. The issue I have that if we make that interface optional we need to add code that checks for it. | 08:38 |
| saggi | And I think that it's less code to implement data_bank for SQL once than to have every plugin writer to remember to check for that interface. | 08:39 |
| yinwei_computer | chenying, saggi's argument is there's one 'generic' data-bank-plugin for most of dbs. my point is even if this is the case, there will be some verification effort, and customers won't put effort on things they don't use. | 08:39 |
| saggi | yinwei_computer: You are talking about certifying databases? | 08:39 |
| saggi | *specific databases | 08:39 |
| chenying | Verdor's plugins is thrie own solution. They may don't consider use a uniform writing backup data interface. | 08:39 |
| yinwei_computer | plugin writer doesn't check it, but claim it in the requirement function. | 08:40 |
| *** yinwei_computer has quit IRC | 08:41 | |
| saggi | TBH I never liked putting blobs in the bank in the first place. But this means that generic plugins can't put *small* blobs in the bank if they want to. This means we can't have any OpenStack reference implementation depend on being able to put blobs in the bank. | 08:41 |
| saggi | It could just be an `recover.sql` file that contains the backup of a db | 08:42 |
| yuval | putting blobs in a bank is very beneficial in cross site protect and restore | 08:43 |
| *** yinwei_computer has joined #openstack-smaug | 08:43 | |
| *** yinwei_computer has quit IRC | 08:44 | |
| saggi | yuval: I think we broke yinwei :) | 08:46 |
| yuval | :(( | 08:46 |
| *** yinwei_computer has joined #openstack-smaug | 08:46 | |
| *** yinwei_computer has quit IRC | 08:47 | |
| *** yinwei_computer has joined #openstack-smaug | 08:51 | |
| yuval | yinwei_computer: welcome back | 08:51 |
| yinwei_computer | always lost | 08:53 |
| yuval | putting blobs in a bank is very beneficial in cross site protect and restore | 08:54 |
| *** yinwei_computer has quit IRC | 08:55 | |
| saggi | yinwei_computer: It seems like to much to prevent any Protection Plugin to be able to add information to the bank that is not in json format. It might just want to backup a configuration file or some data dumps from an external source. | 08:55 |
| saggi | You are talking about use cases where the customer is not and is unwilling to be using MySql\Postgres\Oracle\Swift\NFS | 08:57 |
| *** yinwei_computer has joined #openstack-smaug | 08:57 | |
| saggi | And even for DBs that don't support BLOBS we do need to be able to insert at least small binaries since Protection Plugins might need them. | 08:58 |
| saggi | This can be facilitated with b64 encoded text records | 08:58 |
| *** yinwei_computer has quit IRC | 08:58 | |
| yuval | yinwei lost again | 09:00 |
| *** yinwei_computer has joined #openstack-smaug | 09:01 | |
| saggi | yinwei_computer: It's all your fault | 09:03 |
| saggi | chenying: If yinwei_computer is looking for use tell her that we left for lunch | 09:08 |
| yinwei_computer | ok | 09:08 |
| yinwei_computer | have a nice day | 09:09 |
| *** yinwei_computer has quit IRC | 09:20 | |
| *** yinwei_computer has joined #openstack-smaug | 09:22 | |
| *** yinwei_computer has quit IRC | 09:23 | |
| *** yinwei_computer has joined #openstack-smaug | 09:25 | |
| *** openstack has joined #openstack-smaug | 10:16 | |
| *** yizhihui has quit IRC | 10:16 | |
| *** yamamoto has joined #openstack-smaug | 10:50 | |
| *** yamamoto has quit IRC | 10:56 | |
| *** yamamoto has joined #openstack-smaug | 10:57 | |
| *** yamamoto has quit IRC | 11:02 | |
| *** yamamoto has joined #openstack-smaug | 11:03 | |
| *** yamamoto has quit IRC | 11:07 | |
| *** yamamoto has joined #openstack-smaug | 11:07 | |
| *** yamamoto has quit IRC | 11:09 | |
| *** yamamoto has joined #openstack-smaug | 11:09 | |
| *** yamamoto has quit IRC | 11:40 | |
| *** yamamoto has joined #openstack-smaug | 11:46 | |
| *** gouthamr has joined #openstack-smaug | 12:04 | |
| *** yamamoto has quit IRC | 12:15 | |
| *** yamamoto has joined #openstack-smaug | 12:28 | |
| *** yamamoto has quit IRC | 12:32 | |
| *** yamamoto has joined #openstack-smaug | 12:55 | |
| openstackgerrit | Merged openstack/smaug-dashboard: Fix Protection Plan Creation Failed https://review.openstack.org/355976 | 12:59 |
| *** zhurong has joined #openstack-smaug | 13:05 | |
| *** zhurong has quit IRC | 13:07 | |
| *** zhurong has joined #openstack-smaug | 13:09 | |
| *** yamamoto has quit IRC | 13:29 | |
| *** yamamoto has joined #openstack-smaug | 13:30 | |
| *** saggi has quit IRC | 14:05 | |
| *** saggi has joined #openstack-smaug | 14:08 | |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Reimplement the Protection workflow for new design https://review.openstack.org/348163 | 14:24 |
| *** yamamoto has quit IRC | 14:27 | |
| *** yamamoto has joined #openstack-smaug | 14:29 | |
| *** yamamoto has quit IRC | 14:34 | |
| *** yuval has quit IRC | 14:57 | |
| *** zhurong has quit IRC | 14:59 | |
| *** openstackgerrit has quit IRC | 15:03 | |
| *** openstackgerrit has joined #openstack-smaug | 15:04 | |
| *** yamamoto has joined #openstack-smaug | 15:32 | |
| *** yamamoto has quit IRC | 15:37 | |
| *** saggi has quit IRC | 16:08 | |
| *** yamamoto has joined #openstack-smaug | 17:34 | |
| *** yamamoto has quit IRC | 17:38 | |
| *** gouthamr has quit IRC | 21:04 | |
| *** yamamoto has joined #openstack-smaug | 22:30 | |
| *** gouthamr has joined #openstack-smaug | 23:28 | |
| *** zhurong has joined #openstack-smaug | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!