*** zhongjun___ has joined #openstack-smaug | 02:06 | |
*** zhongjun__ has quit IRC | 02:09 | |
*** zhongjun___ has quit IRC | 03:10 | |
*** zhongjun_ has joined #openstack-smaug | 03:12 | |
*** yinweiishere has quit IRC | 04:04 | |
*** yinweiishere has joined #openstack-smaug | 04:04 | |
*** zhongjun_ has quit IRC | 04:32 | |
*** zhongjun_ has joined #openstack-smaug | 04:32 | |
openstackgerrit | Merged openstack/smaug: Implement Graph pack and unpack https://review.openstack.org/304160 | 05:12 |
---|---|---|
*** zhangshuai has joined #openstack-smaug | 06:09 | |
zhangshuai | i am here | 06:12 |
xiangxinyong | :) | 06:26 |
*** AndroUser has joined #openstack-smaug | 06:28 | |
*** AndroUser is now known as cpz | 06:29 | |
*** CrayZee has quit IRC | 06:36 | |
*** yuval has joined #openstack-smaug | 06:41 | |
*** cpz has quit IRC | 06:48 | |
*** CrayZee has joined #openstack-smaug | 07:04 | |
*** zhangshuai has quit IRC | 07:04 | |
xiangxinyong | yuval: Good morning | 07:56 |
*** gampel has quit IRC | 08:17 | |
yuval | xiangxinyong: hey | 08:18 |
yuval | xiangxinyong: good afternoon :) | 08:19 |
xiangxinyong | yuval: :) | 08:19 |
xiangxinyong | yuval: I have a question about the resources in the checkpoint. could you help me? | 08:21 |
yuval | xiangxinyong: sure, what is it? | 08:21 |
xiangxinyong | when we show the checkpoint details to the users. we will invoke a interface like this. https://etherpad.openstack.org/p/toyuval | 08:22 |
xiangxinyong | yinweiishere told me that in a checkpoint the resources will be shown like a graph | 08:23 |
xiangxinyong | Do you rember the dashboard i show you and eran? | 08:24 |
yuval | yes | 08:24 |
xiangxinyong | at present, we show the resource in a checkpoint like a tree, not a graph | 08:25 |
xiangxinyong | so i want to know about the data structure about the resources in a checkpoint | 08:26 |
yuval | sure, let me explain: | 08:26 |
yuval | first, a few definitions | 08:26 |
xiangxinyong | after this, i could decide how to show the resources in a checkpoint | 08:26 |
yuval | a tree is an undirected graph with no cycles | 08:26 |
xiangxinyong | and decide how to show the resources when the users launch a restore | 08:26 |
yuval | the resources are represented using a directed graph. each node 'depends' (has children' on other nodes | 08:27 |
yuval | this resource graph has no cycles, by our definition | 08:27 |
yinweiishere | hi, guys | 08:28 |
yuval | this means that our resources are represented in what is called a 'rooted tree' | 08:28 |
yuval | hey yinweiishere | 08:28 |
yinweiishere | I think the difference between graph and tree is one node could have multiple parents in our directed graph | 08:29 |
xiangxinyong | oh, the point is no cycles, is it right? | 08:29 |
yinweiishere | but tree doesn't | 08:29 |
yinweiishere | if we show it in the format of tree, node with multiple parents will show multiple times in the tree? | 08:29 |
yuval | yinweiishere: this is correct, I discussed this issue with saggi | 08:30 |
yinweiishere | so i suggest to present a graph instead of a tree in checkpoint | 08:31 |
xiangxinyong | yinweiishere: it should like multiple extent in the python. a class extened multiple parent classes | 08:31 |
yuval | yinweiishere: can you give an example of a graph presentation in webui? | 08:31 |
yuval | (by the way, in a directed tree, it is totally acceptable for a node to have 2 parents) | 08:32 |
yinweiishere | we could refer the presentation of network topology in horizon UI, which gives a good eg. on how to show a dependency graph | 08:32 |
yinweiishere | actually I have sent one picture to xinyong and Eran | 08:32 |
yinweiishere | I could send it to your mailbox. your mailbox is? | 08:33 |
yuval | yuval@brik.org.il | 08:34 |
yinweiishere | done | 08:36 |
xiangxinyong | yinweiishere: this resource graph has no cycles, by our definition | 08:37 |
yinweiishere | sure | 08:37 |
yuval | by the way, multiple parents = not a tree, yinweiishere is correct | 08:37 |
yuval | my bad | 08:37 |
yinweiishere | it has no cycles, check directed path | 08:37 |
yinweiishere | xiangxinyong, are you talking about the picture I shared to you? | 08:38 |
xiangxinyong | yinweiishere: nope | 08:38 |
yinweiishere | ok | 08:38 |
yinweiishere | yes, there's no cycle | 08:38 |
xiangxinyong | yuval and yinweishere, if there's no cycle, i think it is ok by using a resource tree | 08:39 |
yinweiishere | why? | 08:39 |
yuval | yinweiishere: got your mail | 08:40 |
xiangxinyong | like you say: <yinweiishere> if we show it in the format of tree, node with multiple parents will show multiple times in the tree? | 08:40 |
yinweiishere | say, 3 severs depend on the same image. If we show it through tree, this means you have to make 3 nodes for the image | 08:40 |
openstackgerrit | Yuval Brik proposed openstack/smaug: Add croniter as requirement, devstack providersd https://review.openstack.org/305664 | 08:41 |
yinweiishere | but the 3 nodes are actually one resource | 08:41 |
yinweiishere | this looks confusing to me | 08:41 |
yinweiishere | it's not explicit to show what resources we protect | 08:41 |
yinweiishere | yuval, what do you think? | 08:42 |
yuval | yinweiishere: one minute | 08:42 |
yuval | yinweiishere: how would the graph look when we have, say, 100 or 200 servers, all depending on the same image? | 08:44 |
yuval | (btw, please vote for: https://review.openstack.org/305664 , it blocks Smaug's devstack) | 08:45 |
yinweiishere | so there will be 100 or 200 directed paths from server nodes to one image node | 08:45 |
yinweiishere | maybe not pretty in a graph :( | 08:46 |
*** gampel-cell has joined #openstack-smaug | 08:46 | |
yuval | also, what about hirearchy? say, I want to look at a 'closed' project, 'open' it, and view all of its child resources | 08:46 |
gampel-cell | I agree with yuval I think it should be a tree | 08:47 |
xiangxinyong | yinweiishere:yes. the checkpoint resource tree should be like the resource tree when we create a plan | 08:47 |
xiangxinyong | when we create a plan, the dashboard will show a resouce tree, it should be possible to appeat the case "node with multiple parents" | 08:48 |
xiangxinyong | appear the case "node with multiple parents" | 08:49 |
gampel-cell | Including the newly auto dustcover resource s | 08:49 |
openstackgerrit | Yuval Brik proposed openstack/smaug: Add croniter as requirement, devstack providersd https://review.openstack.org/305664 | 08:49 |
yuval | maybe we can split the view into two: a list of concrete resources, and a dependency view, using a tree | 08:50 |
yuval | but I'm not sure about that | 08:50 |
xiangxinyong | yuval:hi, i make a comment into this patch. https://review.openstack.org/#/c/305664 | 08:54 |
xiangxinyong | yuval: please take a look at it. thanks | 08:55 |
yuval | xiangxinyong: thanks. editor is configured for spaces instead of tabs only in python, not bash scripts :\ | 08:56 |
openstackgerrit | Yuval Brik proposed openstack/smaug: Add croniter as requirement, devstack providersd https://review.openstack.org/305664 | 08:56 |
yinweiishere | hmm, so the node with multi parents will appear multi times in a tree? | 08:56 |
yinweiishere | or usually we don't show the dependency and it just looks like a list? | 08:57 |
yinweiishere | yuval, hierachy is a 'has a/many' relationship | 08:57 |
yinweiishere | while depedency is a dependent relationship | 08:58 |
yinweiishere | depends on what we want to show | 08:58 |
openstackgerrit | Yuval Brik proposed openstack/smaug: Add croniter as requirement, devstack providersd https://review.openstack.org/305664 | 08:58 |
yuval | I have to go, I'll be back in an hour. I lean towards a tree view | 09:04 |
openstackgerrit | Merged openstack/smaug: Add croniter as requirement, devstack providersd https://review.openstack.org/305664 | 09:15 |
openstackgerrit | Merged openstack/smaug-dashboard: [Triggers] Submit create view function https://review.openstack.org/303795 | 09:48 |
openstackgerrit | Merged openstack/smaug-dashboard: [Triggers] Submit detail view function https://review.openstack.org/303799 | 09:48 |
openstackgerrit | Merged openstack/smaug-dashboard: [Protection Providers] Submit index view function https://review.openstack.org/303973 | 09:49 |
openstackgerrit | Merged openstack/smaug-dashboard: [Protection Providers] Submit detail view function https://review.openstack.org/303983 | 09:49 |
*** gampel-cell has quit IRC | 09:56 | |
yuval | ping yinweiishere | 10:28 |
yuval | ping xiangxinyong | 10:28 |
openstackgerrit | Yuval Brik proposed openstack/smaug: Fix serialized_meta in SwiftBankPlugin https://review.openstack.org/301427 | 10:43 |
xiangxinyong | yuval: hello | 10:45 |
yuval | xiangxinyong: hey | 10:45 |
xiangxinyong | yuval: :) | 10:47 |
yuval | did you and yinweiishere continued the discussion? | 10:47 |
xiangxinyong | nope | 10:48 |
xiangxinyong | yuval: do you have some ideas? | 10:48 |
yuval | do you think we should use a tree to represent the checkpoint resources? | 10:48 |
xiangxinyong | i think it is ok | 10:48 |
yuval | that means that the same resource can appear multiple times | 10:49 |
xiangxinyong | yeah | 10:49 |
xiangxinyong | the resource will list all the dependency resouces | 10:50 |
xiangxinyong | It will be represent like this. https://review.openstack.org/cat/262264%2C15%2Cdoc/images/available_protectables.svg%5E0 | 10:56 |
xiangxinyong | yuval: maybe we can split the view into two: a list of concrete resources, and a dependency view, using a tree | 11:02 |
xiangxinyong | yuval: could you descript it more? | 11:02 |
*** chenying has joined #openstack-smaug | 11:13 | |
*** chenying_ has quit IRC | 11:14 | |
yuval | xiangxinyong: I'll try to make a mockup and send it to you | 11:32 |
yuval | ping yinweiishere | 11:32 |
xiangxinyong | yuval: thanks very much. | 11:34 |
*** CrayZee has quit IRC | 11:38 | |
xiangxinyong | yuval: do you mean like this. http://www.cnblogs.com/edisonxiang/p/5392651.html | 12:43 |
xiangxinyong | yuval: resources A B C is the selected resources. | 12:43 |
*** xiangxinyong456 has joined #openstack-smaug | 12:46 | |
*** xiangxi3 has joined #openstack-smaug | 12:47 | |
*** xiangxinyong456 has quit IRC | 12:47 | |
*** xiangxinyong456 has joined #openstack-smaug | 12:49 | |
*** xiangxi3 has quit IRC | 12:49 | |
*** xiangxi37 has joined #openstack-smaug | 12:51 | |
*** xiangxinyong456 has quit IRC | 12:51 | |
*** xiangxinyong456 has joined #openstack-smaug | 12:57 | |
*** xiangxi37 has quit IRC | 12:57 | |
*** xiangxinyong456 has quit IRC | 12:57 | |
yuval | xiangxinyong: not sure. it is kind of confusing the same resource twice | 13:05 |
yuval | xiangxinyong: what is your mail address? | 13:29 |
xiangxinyong | yuval: xiangxingyong@qq.com | 13:53 |
xiangxinyong | yuval: thanks | 13:53 |
*** dell has joined #openstack-smaug | 14:54 | |
*** dell is now known as chenzeng | 14:54 | |
chenzeng | yuval:are you there? | 14:55 |
yuval | chenzeng: yes | 14:55 |
chenzeng | yuval:great. | 14:55 |
chenzeng | yuval:gampel gives me a comment about using db directly in the Operation Engine. | 14:56 |
yuval | chenzeng: yes | 14:56 |
chenzeng | yubal:according to the original design, we can use DB in the Operation Engine. | 14:57 |
chenzeng | i don't know why can't use DB directly. | 14:59 |
chenzeng | if can not use, how to access db? | 14:59 |
chenzeng | what is your opinion? | 14:59 |
yuval | I'm about to head off, so I'll try to summarize: consider we have 3 types of services - api, protection, and operationengine. Each of these services can be separate, and each service should only access or change objects under its responsibility. we want to minimize the places where we use the db directly, and use api wrappers over it | 15:01 |
chenzeng | so, you agree with gampel, do you? | 15:03 |
chenzeng | but, at right moment. we don't have a wraper or service offering the api of db. | 15:05 |
yuval | I spoke with him, and I think we can let this patch pass and change it to use the api latter | 15:06 |
chenzeng | do we need to access db like nova which have a conductor service? | 15:06 |
yuval | No need to hold this one off | 15:06 |
yuval | I really need to go, otherwise I'll miss my ride | 15:06 |
chenzeng | ok. | 15:07 |
chenzeng | thankd. | 15:07 |
chenzeng | thanks. | 15:07 |
yuval | thank you :) | 15:07 |
yuval | see you | 15:07 |
*** yuval has quit IRC | 15:07 | |
*** chenzeng has quit IRC | 15:28 | |
openstackgerrit | chenying proposed openstack/python-smaugclient: Remove the project_id in the url of smaugclient resource https://review.openstack.org/305943 | 15:38 |
openstackgerrit | chenying proposed openstack/smaug: Add name property to protectable instances model https://review.openstack.org/302086 | 17:02 |
*** gampel has joined #openstack-smaug | 17:16 | |
openstackgerrit | chenying proposed openstack/smaug: Add show protectables instance endpoint https://review.openstack.org/302144 | 17:27 |
openstackgerrit | chenying proposed openstack/smaug: Add a field parameters to resource plans https://review.openstack.org/302730 | 17:31 |
openstackgerrit | chenying proposed openstack/smaug: The versioned object and db operation of operation_log https://review.openstack.org/304212 | 17:41 |
openstackgerrit | chenying proposed openstack/smaug: The RESTAPI of resource operation_logs https://review.openstack.org/304567 | 17:47 |
*** chenying_ has joined #openstack-smaug | 20:16 | |
*** chenying has quit IRC | 20:19 | |
*** gampel has quit IRC | 20:46 | |
*** gampel1 has joined #openstack-smaug | 20:46 | |
*** gampel1 has quit IRC | 20:49 | |
*** gampel has joined #openstack-smaug | 20:49 | |
*** gampel has quit IRC | 21:03 | |
*** c00281451_ has quit IRC | 21:34 | |
*** c00281451_ has joined #openstack-smaug | 21:35 | |
*** chenying has joined #openstack-smaug | 21:52 | |
*** chenying_ has quit IRC | 21:55 | |
*** yinweiishere has quit IRC | 21:58 | |
*** yinweiishere has joined #openstack-smaug | 21:59 | |
*** yuval has joined #openstack-smaug | 22:15 | |
*** chenying has quit IRC | 22:29 | |
*** chenying has joined #openstack-smaug | 22:30 | |
*** chenying_ has joined #openstack-smaug | 22:58 | |
*** chenying has quit IRC | 23:02 | |
*** yuval has quit IRC | 23:44 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!