| openstackgerrit | chenying proposed openstack/smaug: Add name property to protectable instances model https://review.openstack.org/302086 | 03:22 |
|---|---|---|
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement restoration https://review.openstack.org/303277 | 03:24 |
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement restoration https://review.openstack.org/303277 | 03:26 |
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement Cinder Restoration https://review.openstack.org/303277 | 03:34 |
| *** gampel has quit IRC | 06:00 | |
| *** gampel has joined #openstack-smaug | 06:15 | |
| *** CrayZee has quit IRC | 06:21 | |
| *** CrayZee has joined #openstack-smaug | 06:24 | |
| *** yuval has joined #openstack-smaug | 06:36 | |
| openstackgerrit | chenying proposed openstack/smaug: Add show protectables instance endpoint https://review.openstack.org/302144 | 06:43 |
| openstackgerrit | chenying proposed openstack/smaug: Add a field parameters to resource plans https://review.openstack.org/302730 | 06:53 |
| *** saggi has joined #openstack-smaug | 07:02 | |
| saggi | hi everyone | 07:03 |
| xiangxinyong | hello saggi | 07:18 |
| xiangxinyong | good morning | 07:19 |
| saggi | xiangxinyong: good morning! | 07:25 |
| xiangxinyong | saggi:^-^ | 07:26 |
| xiangxinyong | saggi: please take a look at this two link. | 07:28 |
| xiangxinyong | https://etherpad.openstack.org/p/createplannew | 07:28 |
| xiangxinyong | https://etherpad.openstack.org/p/restorecheckpointnew | 07:28 |
| xiangxinyong | These two links are about the create plan and restore from checkpoint interface. | 07:29 |
| xiangxinyong | do you agree? | 07:29 |
| *** yinwei_computer has joined #openstack-smaug | 07:30 | |
| yuval | yinwei_computer: ping | 07:30 |
| yinwei_computer | ping yuval | 07:30 |
| yuval | hey :) | 07:30 |
| yuval | how are you? | 07:30 |
| yinwei_computer | doing good | 07:30 |
| yinwei_computer | thanks | 07:30 |
| yinwei_computer | how about you? | 07:30 |
| yinwei_computer | I saw you committed a patch for grah test | 07:30 |
| yinwei_computer | graph | 07:31 |
| yuval | very well | 07:31 |
| yuval | yes | 07:31 |
| yinwei_computer | have saggi aligned his graph de/serialization with you? | 07:31 |
| yuval | I'm almost done with the graph de/serializtion | 07:32 |
| yinwei_computer | wow | 07:32 |
| yuval | :) | 07:32 |
| yinwei_computer | awesome work | 07:32 |
| yuval | do you have a couple of minutes to speak about the protection flow? | 07:32 |
| yuval | https://github.com/openstack/smaug/blob/master/doc/source/specs/protection-service/protection-service.rst | 07:33 |
| yinwei_computer | sure | 07:33 |
| yinwei_computer | actually I also have another issue to check with you | 07:33 |
| yinwei_computer | but we could see this one first | 07:33 |
| yuval | what is it? | 07:33 |
| yuval | ok | 07:33 |
| yinwei_computer | so what's up with this design doc? | 07:34 |
| yinwei_computer | yuval? | 07:35 |
| yuval | After reading this document, I'm not sure I understand what is SyncCheckpointStatusTask is and what is its role. From what I figured, every task returned by a resource (i.e Cinder plugin protect) returns a task/flow which is finished when the protect itself is complete. Considering this, why are the "status_getters" neccesary? | 07:35 |
| yinwei_computer | sure, take cinder as eg | 07:36 |
| yinwei_computer | protect() in cinder volume means cinder.backup, which is async | 07:36 |
| yinwei_computer | that's what we do in the protection task flow. | 07:37 |
| yinwei_computer | after it's executed, we're not sure if the backup has been succeeded and thus not sure whether the checkpoint is available now | 07:37 |
| yinwei_computer | here, available means ready to be restored from | 07:37 |
| yinwei_computer | that's why we need a task to synchronize each backup's status and thus update the whole checkpoint's status | 07:38 |
| yuval | Why isn't it the protection plugin job to poll the status and complete the task only when the actual protection is complete and available? | 07:38 |
| yinwei_computer | you mean poll inside the task? | 07:39 |
| yinwei_computer | this comes to the parallelism of the task flow | 07:39 |
| yuval | I mean that we don't care whether the protection plugin is sync/async. We leave it to the protection plugin to decide | 07:39 |
| yinwei_computer | yes, that's why we have each protection plugin to implement get_status | 07:40 |
| yuval | how does it affect parallelism? | 07:40 |
| yinwei_computer | say we have 1 server attached with 1 volume | 07:42 |
| yinwei_computer | if we have volume to be polled as available and then to execute server protect, the latency is latency_volume_backup + latency_server_backup | 07:43 |
| yinwei_computer | in fact, the two could be triggered at the same time in protection | 07:43 |
| yinwei_computer | of course, if there's dependency, user could implement it in the sync mode | 07:43 |
| yinwei_computer | it depends on the implementation | 07:44 |
| yuval | ok, consider this: | 07:44 |
| yinwei_computer | if it's sync mode, the SyncCheckpointStatusTask would finish quickly with one poll round | 07:44 |
| yuval | vm can perform its operation in parallel to the cinder protect. consider the VM protection plugin return a task called "VM finish protect". But also, creates another task, named "VM actual protect" and link it to the "VM finish protect". "VM actual protect" doesn't depend on cinder at all. "VM finish protect" depends on both "VM actual protect" and the cinder protect | 07:47 |
| yuval | VM finish protect | 07:48 |
| yuval | / \ | 07:48 |
| yuval | cinder protect VM actual protect | 07:48 |
| yuval | therefore, when "VM finish protect" completes, we are certain that "cinder protect" and "VM actual protect" have finished (and may happen in parallel), but we don't need to check any status | 07:49 |
| yuval | "VM finish protect" can be a no-op, but that depends on the protection plugin | 07:50 |
| yuval | what do you think? | 07:50 |
| yinwei_computer | yes, that's why we use heat in restore | 07:51 |
| yinwei_computer | where heat actually add a 'attachment' resource between server and volume | 07:51 |
| yinwei_computer | but in protection, we think current resource graph is ok. | 07:52 |
| yinwei_computer | you point will introduce complexity of server protection plugin, right? it has to take care of parallelism, which task graph should does already | 07:52 |
| yuval | this can actually work for restore as well: | 07:53 |
| yuval | VM main task (attach volume) | 07:53 |
| yuval | / \ | 07:53 |
| yuval | cinder restore VM restore | 07:54 |
| yinwei_computer | hmm, restore doesn't need do so | 07:54 |
| yuval | because of heat? | 07:54 |
| yinwei_computer | heat will do this work | 07:54 |
| yinwei_computer | yes | 07:54 |
| yuval | well, VM main task can just return the heat resource, then | 07:54 |
| yuval | why would that introduce a complexity for the server plugin? | 07:55 |
| yinwei_computer | in your case, protection plugin need check if its child task is sync/async. If it's sync, it needs add another task in addition to its own protection task. And, it needs organize the task flow by itself | 07:56 |
| yinwei_computer | the generic task stack is organized according to resource graph, but for your case, the protection plugin should customize its own task stack: it should know only push attachement task into task stack and before this link the server task to attachement task. | 07:58 |
| yuval | protection plugin doesn't need to know if its child task is sync/async. protection plugin needs to return a task (which might have floating task which it depends upon), and that task will happen after all of its dependencies have been resolved | 07:58 |
| chenying_ | ping gampel | 07:58 |
| yinwei_computer | the generic task stack is organized according to resource graph, but for your case, the protection plugin should customize its own task stack: it should know only push attachement task into task stack and before this link the server task to attachement task. | 07:58 |
| chenying_ | Hi yuval Is eran there? | 07:59 |
| yuval | chenying_: he will be back in a few minutes | 07:59 |
| yuval | chenying_: I'll tell him you looked for him | 08:00 |
| chenying_ | Ok thanks. | 08:00 |
| openstackgerrit | chenying proposed openstack/smaug: Add a field parameters to resource plans https://review.openstack.org/302730 | 08:01 |
| yuval | yinwei_computer: the protection plugin will not customize the stack. It must return a task. When this task is complete, the resource protect/restore is complete. For parallelism, this task can depend on other custom task by the protection plugin. | 08:02 |
| yinwei_computer | how can it retrieve the task it to depend on? | 08:02 |
| yinwei_computer | it has to operate task stack | 08:03 |
| yuval | it can return a flow, instead of a single task | 08:04 |
| yinwei_computer | btw, I don't prefer a synchronous task which sounds waste of thread resources. Pls. check this patch:https://review.openstack.org/#/c/303355/1 | 08:04 |
| yuval | and taskflow can handle when you add a flow to another flow | 08:04 |
| yuval | Can you view Google docs? | 08:04 |
| yinwei_computer | actually, we'd better not have plugin to operate much on task flow | 08:04 |
| yuval | https://docs.google.com/presentation/d/1vkgGdyYSrKTRbjUWWiz8IqDrd3sAJr25PRtXht93A8I | 08:04 |
| yinwei_computer | sure, I know that task flow feature | 08:05 |
| yinwei_computer | but flow doesn't solve your case | 08:06 |
| yinwei_computer | flow1: attachement->server; flow1->volume | 08:06 |
| yinwei_computer | it becomes serial now | 08:06 |
| yuval | can you please take a look at the google docs I sent? | 08:07 |
| yinwei_computer | sorry, I couldn't get it from huawei network | 08:08 |
| yinwei_computer | you could send text to my huawei mail box yinwei3@huawei.com | 08:08 |
| yuval | not even pdf? | 08:08 |
| yinwei_computer | The website is denied.You have no privilege to access "Personal Network Storage" category. | 08:09 |
| yinwei_computer | pdf is ok | 08:09 |
| yinwei_computer | pdf as attachment in mail | 08:09 |
| yuval | sent | 08:10 |
| yinwei_computer | btw, what do you think about this bug? | 08:10 |
| yinwei_computer | https://bugs.launchpad.net/smaug/+bug/1566793 | 08:11 |
| openstack | Launchpad bug 1566793 in Smaug "authenticate in protection service client" [Undecided,New] | 08:11 |
| yuval | yep, we must handle this one | 08:12 |
| yuval | regarding your example with flow1: | 08:13 |
| yinwei_computer | i saw your pdf, | 08:14 |
| yinwei_computer | I do appreciate to have attachment node between server and volume. But I'm not sure whether we need attachment every joinment | 08:14 |
| yinwei_computer | what does attachment between vm to image mean? | 08:15 |
| yuval | it works the other way around. first [volume_flow: protect_volume] is created. then [server] flow is created, and linked with 1) volume_flow 2) actual server protect | 08:15 |
| yuval | the attachment node is an example. It can be "create HeadResource" for the record | 08:16 |
| yinwei_computer | I'm not sure if I get this | 08:16 |
| yuval | the most important thing is, that once the main task returns, the resource is fully backed up / restored | 08:16 |
| yinwei_computer | hmm | 08:17 |
| yinwei_computer | most openstack api is async | 08:17 |
| yinwei_computer | the point here is sync mode is not efficient | 08:17 |
| yinwei_computer | you have each thread polling and wait there | 08:17 |
| yuval | I'm saying, a protection plugin should manage its sync/async nature | 08:17 |
| yinwei_computer | sure | 08:17 |
| yinwei_computer | no problem | 08:17 |
| yuval | it can be a greenthread | 08:18 |
| yinwei_computer | if it's sync, then get status always return static mode:available or error | 08:18 |
| yuval | I understand | 08:18 |
| yinwei_computer | if it's async, then get status always poll all resources of this kind resource type | 08:18 |
| yinwei_computer | generally, it's a trade off between sync/asyn and simplicity of protection plugin implementation | 08:20 |
| yinwei_computer | if sync is the benefit of your task flow organization, then protection plugin must know more about task flow context. | 08:20 |
| yuval | not sure I understand what it must know more about the taskflow context | 08:21 |
| yinwei_computer | At the beginning of protection plugin design, we want to mask most of task flow details from protection plugin | 08:22 |
| yinwei_computer | if you check current cinder/nova/image protection plugin, they only implement functions | 08:22 |
| yinwei_computer | they don't care dependency | 08:22 |
| yinwei_computer | since resource graph framework will take care of it | 08:22 |
| yinwei_computer | if we don't achieve consensus here, we could check it with gampel | 08:24 |
| yinwei_computer | my point here are: 1. it's not necessary to have protection plugin to implement a sync mode task; 2. we don't want to expose too much task flow details to protection plugin, that's why we optimized the base protection plugin and thus move task stack work to graph walker listener. | 08:25 |
| yinwei_computer | the principle is to have the framework take more and have protection plugin to take less. | 08:26 |
| yuval | I see. What I was worried about, is that we poll the statuses every time. Consider we have 1000 resources to protect - that's wasteful. By the way, not give each protection plugin a callback to call when it finished, and let it update the status in the SyncCheckpointTask ? | 08:28 |
| yuval | *why not give...\ | 08:28 |
| yinwei_computer | each plugin will only have 1 thread to poll all on-going resources of its kind | 08:29 |
| yuval | yes, but SyncCheckpointTask loops over all the status getters | 08:30 |
| yinwei_computer | and once the resource has reached static status:available, error, error deleting, their status will be persisted in bank | 08:30 |
| yinwei_computer | and for static status resources, SyncCheckpointTask won't poll in the next round | 08:31 |
| yinwei_computer | it's very simple memory optimization | 08:31 |
| yuval | brb | 08:33 |
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement Cinder Restoration https://review.openstack.org/303277 | 08:39 |
| openstackgerrit | chenying proposed openstack/smaug: Add checkpoint id to the response of the checkpoint POST action https://review.openstack.org/303971 | 08:53 |
| openstackgerrit | xiangxinyong proposed openstack/smaug-dashboard: [Protection Providers] Submit index view function https://review.openstack.org/303973 | 08:56 |
| openstackgerrit | xiangxinyong proposed openstack/smaug-dashboard: [Protection Providers] Submit index view function https://review.openstack.org/303973 | 09:04 |
| yuval | yinwei_computer: hi | 09:16 |
| openstackgerrit | wangliuan proposed openstack/smaug: Implement the protection flow https://review.openstack.org/281011 | 09:18 |
| openstackgerrit | xiangxinyong proposed openstack/smaug-dashboard: [Protection Providers] Submit detail view function https://review.openstack.org/303983 | 09:21 |
| chenying_ | gampel:ping | 09:27 |
| gampel | I am in DF IRC weekly i will contact you latter | 09:32 |
| chenying_ | OK Thanks. | 09:33 |
| *** yinweiishere has joined #openstack-smaug | 09:37 | |
| openstackgerrit | chenying proposed openstack/smaug: Add checkpoint id to the response of the checkpoint POST action https://review.openstack.org/303971 | 09:55 |
| openstackgerrit | wangliuan proposed openstack/smaug: Implement the workflow https://review.openstack.org/285149 | 11:13 |
| xiangxinyong | Hi eran | 11:18 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement restart of Operation Engine service https://review.openstack.org/304048 | 11:21 |
| xiangxinyong | https://review.openstack.org/#/c/301543/ | 11:27 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement restart of Operation Engine service https://review.openstack.org/304048 | 11:32 |
| xiangxinyong | hi saggi | 11:37 |
| *** zhonghua-lee has quit IRC | 11:45 | |
| *** zhonghua-lee has joined #openstack-smaug | 11:46 | |
| chenzeng | ping yinwei | 12:01 |
| *** xiangxinyong has quit IRC | 12:04 | |
| *** xiangxinyong has joined #openstack-smaug | 12:06 | |
| saggi | xiangxinyong: hey | 12:30 |
| saggi | xiangxinyong: How are you | 12:30 |
| xiangxinyong | fine.Thanks | 12:30 |
| xiangxinyong | saggi:sorry to trouble you. | 12:30 |
| saggi | xiangxinyong: np | 12:31 |
| xiangxinyong | I got a problem when i want to show a resouce tree in a plan. | 12:32 |
| xiangxinyong | could you help me? | 12:32 |
| xiangxinyong | https://etherpad.openstack.org/p/tosaggi | 12:34 |
| xiangxinyong | please take a look at the above link. | 12:34 |
| * saggi is looking at the link | 12:35 | |
| xiangxinyong | This is the interface of showing a plan | 12:36 |
| saggi | ok | 12:37 |
| saggi | .... | 12:37 |
| xiangxinyong | i have no idea how to show a resource tree in the plan detail page. | 12:37 |
| saggi | oh | 12:38 |
| xiangxinyong | because i could not find the dependency relateion in this json | 12:38 |
| xiangxinyong | because i could not find the dependency relation in this json | 12:38 |
| xiangxinyong | saggi: What do you think about that? | 12:39 |
| saggi | xiangxinyong: I understand the problem. | 12:39 |
| saggi | If you just want to show them in relation to each other it's simple. | 12:40 |
| saggi | The problem is parent relationships. | 12:40 |
| xiangxinyong | yeah | 12:40 |
| * saggi is thinking about it | 12:40 | |
| *** xiangxinyong456 has joined #openstack-smaug | 12:41 | |
| saggi | You can start looking for them from the roots. But that's an expensive action. | 12:42 |
| xiangxinyong456 | yeah, it seems like it is.the only way | 12:43 |
| * saggi is thinking some more... | 12:43 | |
| xiangxinyong456 | firstly, i will list the all resources | 12:43 |
| xiangxinyong456 | and then it will choose the resources in the plan | 12:44 |
| saggi | Technically the only issue is with adding new resources. Any other flow doesn't really care about parent resoruces. | 12:44 |
| saggi | xiangxinyong456: Listing all the resources is expensive. | 12:44 |
| xiangxinyong456 | yeah, it is more expensive | 12:45 |
| saggi | What I would suggest is displaying them all the resources as a list in the same level all as root entities. | 12:47 |
| saggi | If the user wants to modify or deselect they can. | 12:47 |
| saggi | The can also expand those to check for auto-detected dependencies. | 12:47 |
| saggi | For adding a new resource, you could open a new dialog with the root and let the user look for the resource they want to add, if it an entity that is already selected is returned it is marked as checked. | 12:47 |
| saggi | xiangxinyong456: What do you think? | 12:48 |
| *** xiangxi38 has joined #openstack-smaug | 12:49 | |
| saggi | ping yinwei_computer yinweiishere | 12:51 |
| *** xiangxinyong456 has quit IRC | 12:51 | |
| xiangxi38 | saggi, you means we can list all the resources in the plan in the same level | 12:52 |
| xiangxi38 | ? | 12:52 |
| saggi | Yes | 12:52 |
| saggi | But for adding new resources we open a dialog with just the project. | 12:52 |
| saggi | Similar to how you have a zip file and you add a new file to it | 12:53 |
| saggi | xiangxi38: how is that idea? | 12:53 |
| saggi | And why are you changing nicknames every minute :) | 12:53 |
| xiangxi38 | sorry, i am using mobile | 12:54 |
| xiangxi38 | saggi: so we don't need a resource tree when we show a plan detail info | 12:56 |
| saggi | Paritally, we still want to allow the user to expand the flat list to see what is autodetected. | 12:56 |
| xiangxi38 | you means the users could expand the resource | 12:59 |
| xiangxi38 | only dependent resources ? | 12:59 |
| xiangxi38 | or users could expand the dependent resources? | 13:00 |
| saggi | It could keep expending to investigate | 13:02 |
| saggi | But it should't be able to add items this way | 13:03 |
| saggi | Only through the dialog. So we always use the canonical view. | 13:03 |
| xiangxi38 | saggi: i think we should show the whole resource tree when the users update the plan. | 13:05 |
| xiangxi38 | and let the resources to select and disselect | 13:05 |
| saggi | But it's an expensive action to look for a resource. And it might even have been deleted. | 13:06 |
| xiangxi38 | yeah. understood | 13:06 |
| saggi | Although most of the time it will just be under project. | 13:06 |
| saggi | But if it's not looking for it would be very hard. | 13:07 |
| xiangxi38 | i means when we show the plan detail, we only show the users choosed resources | 13:07 |
| saggi | Yes, and when adding new resources we show the whole tree | 13:08 |
| xiangxi38 | and when we show the update plan dialog, | 13:08 |
| xiangxi38 | we could show the whole tree | 13:09 |
| saggi | Yes, but unexpended. | 13:09 |
| saggi | But if we stumble to a selected resource we show it's selected. | 13:09 |
| xiangxi38 | saggi: i think the users have 3 different operations. | 13:12 |
| xiangxi38 | create a plan | 13:12 |
| xiangxi38 | update a plan | 13:12 |
| xiangxi38 | show a plan detail | 13:12 |
| xiangxi38 | we may need 3 pages to show them. | 13:13 |
| xiangxi38 | what do you think about it? | 13:14 |
| saggi | Create and update are similar IMHO | 13:14 |
| saggi | You create an empty plan | 13:14 |
| saggi | then start updating it | 13:15 |
| xiangxi38 | yeah, do you think we need a edit button on every plan? | 13:16 |
| xiangxi38 | in our fisrt version? | 13:18 |
| xiangxi38 | or we only need the create plan and plan detail | 13:19 |
| xiangxi38 | i think the users should not modify the plan in the plan detail page. | 13:20 |
| saggi | After you create it will just automatically put you and edit mode | 13:20 |
| saggi | But it will be edit | 13:20 |
| saggi | That way you reuse it | 13:20 |
| saggi | So you create and decide the pland name and bank and the rest of the globals | 13:21 |
| saggi | then they ui will create and empty plan | 13:21 |
| saggi | then it will move to edit mode automatically | 13:21 |
| saggi | So the user feels like it's a smooth experience | 13:21 |
| xiangxi38 | saggi: understood. | 13:24 |
| xiangxi38 | saggi: but specify the plan name, providers and resources.,they are together | 13:25 |
| saggi | You create a plan with an empty resource list | 13:25 |
| saggi | and then edit. So after the user edits it will update the resource list | 13:26 |
| saggi | testing brown files | 13:27 |
| xiangxi38 | saggi: oh, so when the plan created, where could the plan be edited | 13:31 |
| saggi | The edit page :) | 13:31 |
| saggi | Which you will automatically be redirected after creation | 13:32 |
| xiangxi38 | oh. | 13:34 |
| xiangxi38 | so we don't need to the resource tree in the plan detail | 13:34 |
| xiangxi38 | do you agree? | 13:35 |
| saggi | yes, we don't need the full tree. Just to be able check autodetection.\ | 13:37 |
| xiangxi38 | ok | 13:38 |
| xiangxi38 | and when we resit | 13:40 |
| xiangxi38 | and when we restore from checkpoint, | 13:41 |
| xiangxi38 | do you think we still need to show the resources and autodetect? | 13:42 |
| saggi | No, for restore there is no autodetection | 13:44 |
| saggi | for restore you have all the information. | 13:44 |
| saggi | The checkpoints contains the full tree | 13:45 |
| xiangxi38 | I understand the checkpoint only contains the selected resources | 13:46 |
| xiangxi38 | am i wrong? | 13:47 |
| saggi | No the checkpoint contains all the resources that were backed up | 13:48 |
| saggi | There is no autodiscovery for restore. There is nothing to discover. | 13:48 |
| xiangxi38 | so when we restore from checkpoint, | 13:52 |
| xiangxi38 | we only just show a resource table, and let the users to edit the resource parameters | 13:53 |
| xiangxi38 | is it right? | 13:54 |
| saggi | You have full tree in the checkpoint | 13:55 |
| xiangxi38 | ok, the checkpoint has the all backup resources, and the checkpoint will record these backup resources's relationship? | 13:57 |
| saggi | yes | 14:04 |
| saggi | xiangxi38: Do you have any more issues? | 14:06 |
| xiangxi38 | no. | 14:06 |
| saggi | great :) | 14:06 |
| xiangxi38 | thanks saggi | 14:06 |
| saggi | np | 14:06 |
| xiangxi38 | your answer is really help me a lot | 14:07 |
| openstackgerrit | Yuval Brik proposed openstack/smaug: Implement Graph pack and unpack https://review.openstack.org/304160 | 14:27 |
| *** xiangxi38 has quit IRC | 14:33 | |
| *** xiangxinyong456 has joined #openstack-smaug | 14:34 | |
| *** xiangxi15 has joined #openstack-smaug | 14:42 | |
| *** xiangxinyong456 has quit IRC | 14:42 | |
| *** xiangxi15 has quit IRC | 14:53 | |
| *** xiangxinyong456 has joined #openstack-smaug | 14:54 | |
| chenying_ | Hi saggi | 14:57 |
| chenying_ | saggi: ping | 14:57 |
| saggi | chenying hi | 15:05 |
| saggi | how are you? | 15:05 |
| *** yuval has quit IRC | 15:05 | |
| chenying_ | Hi saggi In previous irc meeting we talked about CI, automatic tests on gerrit. It should be added to smaug. | 15:07 |
| chenying_ | Do you have any reference implementation or links about the CI? | 15:08 |
| *** xiangxinyong456 has quit IRC | 15:16 | |
| *** openstackgerrit has quit IRC | 15:18 | |
| *** openstackgerrit has joined #openstack-smaug | 15:18 | |
| *** xiangxinyong456 has joined #openstack-smaug | 15:19 | |
| *** xiangxinyong456 has quit IRC | 15:20 | |
| saggi | Not really, gampel should have some | 15:21 |
| chenying_ | Could you ask gampel to give some reference about the CI? | 15:36 |
| openstackgerrit | Merged openstack/smaug: Fix Provider RPC client and server do not match https://review.openstack.org/302679 | 15:45 |
| openstackgerrit | Merged openstack/smaug-dashboard: Init api tests for smaug-dashboard https://review.openstack.org/302587 | 15:51 |
| openstackgerrit | chenying proposed openstack/smaug: The versioned object and db operation of operation_log https://review.openstack.org/304212 | 16:21 |
| *** xiangxinyong has quit IRC | 19:25 | |
| *** x00350071 has joined #openstack-smaug | 19:26 | |
| *** openstackgerrit has quit IRC | 20:05 | |
| *** openstackgerrit has joined #openstack-smaug | 20:27 | |
| *** openstackgerrit has quit IRC | 20:41 | |
| *** openstackgerrit has joined #openstack-smaug | 20:55 | |
| *** saggi has quit IRC | 23:26 | |
| *** gampel has quit IRC | 23:26 | |
| *** saggi has joined #openstack-smaug | 23:40 | |
| *** gampel has joined #openstack-smaug | 23:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!