--- Log opened vr aug 24 00:00:10 2012 00:02 -!- abaron: has joined #vdsm 00:05 -!- abaron_: has joined #vdsm 00:22 -!- rmatinata: has quit [Ping timeout: 276 seconds] 00:44 -!- granha_bola: has quit [Quit: Leaving] 00:45 -!- aliguori: has quit [Remote host closed the connection] 01:07 -!- apuimedo: has joined #vdsm 01:13 -!- tdfkaSaggi1: has joined #vdsm 01:13 -!- apahim: has quit [Quit: Leaving] 01:15 -!- tdfkaSaggi: has quit [Ping timeout: 246 seconds] 01:17 -!- rmatinata: has joined #vdsm 01:41 -!- abaron: has quit [Ping timeout: 240 seconds] 01:41 -!- abaron_: has quit [Ping timeout: 256 seconds] 01:44 -!- apuimedo: has quit [Quit: apuimedo] 02:05 -!- aliguori: has joined #vdsm 02:20 -!- acathrow: has left #vdsm [] 02:58 -!- aliguori: has quit [Quit: Ex-Chat] 03:00 -!- fsimonce: has quit [Quit: Coyote finally caught me] 03:53 -!- tdfkaSaggi1: has quit [Ping timeout: 260 seconds] 04:06 -!- tdfkaSaggi: has joined #vdsm 05:36 -!- DoSa: has joined #vdsm 06:21 -!- acathrow: has joined #vdsm 06:22 -!- odedr: has joined #vdsm 06:24 -!- ewarszaw: has joined #vdsm 06:39 -!- deepakcs: has joined #vdsm 07:02 -!- Netsplit *.net <-> *.split quits: deepakcs 08:27 -!- deepakcs: has joined #vdsm 08:28 -!- bharata: has joined #vdsm 08:33 -!- apuimedo: has joined #vdsm 09:16 -!- tjikkun_work: has joined #vdsm 09:17 -!- apuimedo: has quit [Ping timeout: 240 seconds] 09:18 -!- aledvink: has joined #vdsm 09:25 -!- fsimonce: has joined #vdsm 09:28 -!- lhornyak: has joined #vdsm 10:59 < deepakcs> fsimonce, Hi, posted v3 on gerrit/6856 addressing your comments. Thanks. 10:59 < fsimonce> deepakcs, what's the change #? 10:59 < deepakcs> fsimonce, http://gerrit.ovirt.org/#/c/6856/ 11:00 < fsimonce> deepakcs, ah sorry yeah I didn't see it :) 11:00 < deepakcs> fsimonce, np :) 11:28 < fsimonce> deepakcs, done, minor issues 11:28 < fsimonce> deepakcs, try to get saggi to review it too 11:29 < deepakcs> fsimonce, saggi is already added as reviewer.. let me ping him and ask 11:29 < fsimonce> deepakcs, he's in boston, write him an email 11:29 < deepakcs> fsimonce, ah ok.. i see him away here 11:30 < fsimonce> deepakcs, add me to the cc so I won't forget 11:30 < deepakcs> fsimonce, Sure. Another Q... do I need to wait till related qemu and libvirt changes are upstream ? 11:31 < deepakcs> fsimonce, or is it ok to merge this patch, since the changes are only effective when someoen uses glsuter domain, otherwise not.. just checking. 11:32 < fsimonce> deepakcs, I think we can try to merge it anyway 11:33 < deepakcs> fsimonce, thanks.. sorry abt the RFC stuff.. forgot to remove it 12:04 < deepakcs> fsimonce, quick q... why does produceVolume return an instance ( of say FileVolume) without calling getVolumeClass ? Ideally that should have been the flow 12:04 < deepakcs> fsimonce, for my glusterVolume case.. produceVolume may not return instance of glusterVolume, as i only override getVolumeClass 12:05 < deepakcs> fsimonce, I was thinking to change produceVolume to return instance based on getVolumeClass, if u agree.. i can do it as part of next patcheset for 6856 ? 12:06 < fsimonce> deepakcs, yes you can try to unify the produceVolume's 12:06 < deepakcs> fsimonce, unify meaning ? 12:19 -!- abaron: has joined #vdsm 12:20 -!- abaron_: has joined #vdsm 12:28 < deepakcs> fsimonce, got it :) will it be ok to unify them as part of this patch .. it seems a bit unrelated, hence the q 12:29 < deepakcs> fsimonce, i can spin another patch if that is preferable. 13:30 -!- rmatinata: has quit [Ping timeout: 248 seconds] 13:32 -!- apahim: has joined #vdsm 13:36 -!- acathrow: has left #vdsm [] 13:39 -!- acathrow: has joined #vdsm 13:42 -!- bharata: has quit [Quit: Leaving] 14:00 -!- ybronhei: has joined #vdsm 14:17 -!- odedr: has quit [Quit: Leaving.] 14:20 -!- odedr: has joined #vdsm 14:21 -!- ewarszaw: has quit [Quit: Konversation terminated!] 14:32 -!- AlbertoSilva: has joined #vdsm 14:34 -!- deepakcs: has quit [Quit: Leaving] 14:42 -!- Netsplit *.net <-> *.split quits: lhornyak, hchiramm__ 14:47 -!- aledvink: has quit [Read error: Operation timed out] 14:49 -!- lhornyak: has joined #vdsm 14:49 -!- hchiramm__: has joined #vdsm 14:53 -!- aliguori: has joined #vdsm 15:44 -!- mohankumar: has joined #vdsm 15:56 -!- rharper: has joined #vdsm 16:05 -!- DoSa: has quit [Quit: Leaving.] 16:21 -!- ybronhei1: has joined #vdsm 16:22 -!- abaron__: has joined #vdsm 16:23 -!- ybronhei: has quit [Ping timeout: 252 seconds] 16:23 -!- abaron: has quit [Ping timeout: 276 seconds] 16:23 -!- abaron_: has quit [Ping timeout: 268 seconds] 16:24 -!- abaron: has joined #vdsm 16:35 -!- abaron_: has joined #vdsm 16:39 -!- abaron: has quit [Ping timeout: 268 seconds] 16:39 -!- abaron__: has quit [Ping timeout: 260 seconds] 16:57 -!- dyasny: has joined #vdsm 17:05 -!- ybronhei1: has quit [Quit: Leaving.] 17:10 -!- apuimedo: has joined #vdsm 17:20 -!- abaron_: has quit [Ping timeout: 252 seconds] 17:25 -!- abaron_: has joined #vdsm 17:28 -!- acathrow: has joined #vdsm 17:30 -!- DoSa: has joined #vdsm 17:37 -!- danken: has joined #vdsm 17:37 -!- mode/#vdsm: by ChanServ 17:40 -!- DoSa: has quit [Quit: Leaving.] 17:45 -!- ybronhei: has joined #vdsm 17:46 -!- ybronhei1: has joined #vdsm 17:46 -!- danken: has quit [Ping timeout: 244 seconds] 17:50 -!- AlbertoS_: has joined #vdsm 17:50 -!- ybronhei: has quit [Ping timeout: 252 seconds] 17:51 -!- danken: has joined #vdsm 17:51 -!- mode/#vdsm: by ChanServ 18:02 -!- lhornyak: has quit [Ping timeout: 260 seconds] 18:09 -!- apuimedo: has quit [Quit: apuimedo] 18:18 -!- AlbertoSilva: has joined #vdsm 18:20 -!- lhornyak: has joined #vdsm 18:21 -!- danken: has quit [Quit: Leaving.] 18:54 -!- apuimedo: has joined #vdsm 18:55 -!- apuimedo: has left #vdsm [] 18:59 -!- AlbertoS_: has joined #vdsm 19:30 -!- mohankumar: has quit [Ping timeout: 245 seconds] 19:34 -!- AlbertoSilva: has joined #vdsm 20:10 -!- ybronhei: has joined #vdsm 20:14 -!- ybronhei1: has quit [Ping timeout: 260 seconds] 20:14 -!- trujillo: has joined #vdsm 20:17 -!- danken: has joined #vdsm 20:17 -!- mode/#vdsm: by ChanServ 20:19 -!- danken1: has joined #vdsm 20:19 -!- mode/#vdsm: by ChanServ 20:22 -!- danken: has quit [Ping timeout: 240 seconds] 20:31 <@danken1> aglitke: may I ask about the dependability of your getAllTasks? could you add some limitation param in the future? 20:31 -!- danken1 is now known as danken 20:32 < aglitke> danken, well... If we want to follow the new rules, we should not add parameters. 20:32 <@danken> I simply would like to take your patch as-is, just wanted to be sure about the "options" in the xmlrpc 20:32 < aglitke> So we have 2 options 20:33 < aglitke> tdfkaSaggi and I disagree here on 'options'. I think the next-gen api should only support bit flags extensions 20:33 < aglitke> he likes the current dict extension 20:33 < aglitke> but about the getAllTasks API options: 20:34 < aglitke> 1) I resubmit with an extra placeholder parameter to be used for tag filtering in the future. 20:34 < aglitke> 2) We add a new api in the future: getAllTasksTag that does server-side filtering 20:36 <@danken> ok.... 20:36 <@danken> btw, why would you limit yourself to bit options? to avoid sematic "sprawl"? 20:37 < aglitke> Exactly. Using an options dict basically opens us up to having a well-defined api initially and then in one year having a bunch of new functionality added in as 'options' extensions, 20:38 < aglitke> If the API is changing that much, then a newer function needs to be added 20:38 < aglitke> otherwise all apis might as well be defined as: apiX(options) 20:39 < aglitke> where options is some undefined set of parameters :) 20:41 <@danken> I'm always tempted to have an API: 20:41 <@danken> syscall(num, pointer). 20:41 < aglitke> :) 20:42 < aglitke> btw, as long as I have your attention, I want to ask you about how to proceed with the libvdsm stuff. 20:42 <@danken> oh well, if we ever need server-side filtering we'll add getAllTasks2. 20:43 < aglitke> getAllTaggedTasks() 20:43 <@danken> aglitke: yeah, my wife took the kids for a walk, I have a few minutes 20:43 <@danken> yeah 20:43 < aglitke> danken, great, 20:43 < aglitke> So I have a pretty large wip patch. 20:43 < aglitke> One thing tdfkaSaggi and I talked about was that changes to the API schema should be accompanied by changes to libvdsm so that it keeps working. 20:44 < aglitke> In that way we can slowly walk the API toward where we want it to be. 20:44 < aglitke> Right now there are many big issues to solve. 20:44 < aglitke> It's not ready to let people use it. 20:44 < aglitke> But I fear that as long as it remains out of tree I am the only one who can work on it. 20:45 < aglitke> But I need help to resolve some pretty fundamental design questions. 20:45 < aglitke> So I am feeling a bit chicken and egg here. 20:45 <@danken> why? 20:46 <@danken> why not have something partial in? 20:46 < aglitke> yeah. 20:46 < aglitke> What are you comfortable with taking in tree? 20:47 < aglitke> For something like this, partial means we generate the whole API but it only partially works. 20:47 < aglitke> :) 20:47 < aglitke> We all need to work together to evolve the schema to make it better and more usable. 20:48 <@danken> yeah, understood 20:48 <@danken> I don't see any problem in having a new, mostly broken, entry point to vdsm 20:48 <@danken> though maybe the Binding work you did should be unwound :-( 20:49 < aglitke> Yeah, I think tdfkaSaggi is working on cleaning up API.py 20:49 <@danken> aglitke: we first and formost need to to get Engine to use it 20:49 <@danken> *try to use it, I mean 20:49 < aglitke> danken, agreed 20:50 < aglitke> I will submit a patch to add what I have. For now, I will ship test code in the vdsm_api dir and it will not get run by default.\ 20:50 <@danken> frankly, as long as you do not break my stable api, I perfectly comfortable that you and saggi commit your sandbox to master 20:51 < aglitke> ok, sounds good. I owe the list a few emails about some fundamental design questions I have regarding the API as well. 20:51 <@danken> I wanted to quote "my". joke ruined. 20:51 < aglitke> heh 20:52 <@danken> aglitke: too bad I do not get to delve into these api deliberations. most of my upstream time is reviews of more minor stuff... 20:53 < aglitke> Yeah. I am hoping to get a few more eyes on it. tdfkaSaggi and I are debating about things like whether to pass around UUIDs or objects. 20:53 <@danken> between client and server? 20:53 < aglitke> ... and whether libvdsm should support all of the current hsm apis or not. 20:54 < aglitke> no. server would pass a uuid and client would construct a local object. 20:54 < aglitke> the choice is: 20:54 <@danken> aglitke: I think you said that we have to support current api - since we cannot revolve the api in one jump 20:54 < aglitke> vdsmVM **vms = host.getVMList() 20:54 < aglitke> vs 20:55 < aglitke> char **vm_uuids = host.getVMList() 20:55 < aglitke> vdsmVM *vm = vdsm_vm_init(uuids[0]) 20:55 < aglitke> danken, Agreed re: API support. 20:56 <@danken> in option 1 the onject creation is hidden inside the funciton call? 20:57 < tdfkaSaggi> I'm here! What are we talking about? 20:57 < aglitke> yes, the client receives the uuid from the server and initializes a VM object locally. It returns that initialized object via the getVMList() function 20:58 < aglitke> tdfkaSaggi, Just talking to danken about the libvdsm stuff. 20:58 < aglitke> getting his perspective 20:58 <@danken> aglitke: you can tell him that we spoke about his poor table manners 20:59 <@danken> bare vm uuid would be useful for what? 21:00 < aglitke> ask tdfkaSaggi :) For VM it is clear. For Volume it is less clear. 21:00 <@danken> aglitke: I mean, if no api call accepts it, 21:00 -!- rmatinata: has joined #vdsm 21:00 < aglitke> tdfkaSaggi, was making an argument about Images and Volumes should not be objects. 21:00 < aglitke> But tbh I don't really understand it. 21:01 <@danken> tdfkaSaggi: yeah, producing the volume object on the fly proved so stable over the years.... 21:01 <@danken> (no, it has not) 21:01 < tdfkaSaggi> danken: The new API does not expose the volumes out. 21:02 <@danken> I wish we've been using a volume object, representing a host's temporal knowledge of storage 21:02 < aglitke> tdfkaSaggi, well, according to the schema it does 21:02 < tdfkaSaggi> aglitke: That is the old API. Exposing the volumes has a lot of issues. 21:02 < aglitke> this is where things get confusing to me. I do not understand why a client cannot hold onto a Volume reference. 21:02 < aglitke> tdfkaSaggi, See above re: supporting the current API though 21:03 < aglitke> We cannot just wholesale jump onto a new API with only unicorns and rainbows. 21:03 < aglitke> We have some baggage. 21:03 < tdfkaSaggi> aglitke: This is why I suggested not having managed storage on day one 21:03 <@danken> aglitke: tdfkaSaggi knows about that baggage. he has bugs to fix about it ;-) 21:04 < tdfkaSaggi> This means we can also not include the task system which is highly inconsistent and can cause a lot of issues when missused. 21:04 < aglitke> Yeah, I wish I understood it because to me, it seems perfectly reasonable to expose Volume and Image objects 21:04 < aglitke> tdfkaSaggi, Ok, so that leaves out most of vdsm then. 21:05 <@danken> tdfkaSaggi: reviewing aglitke's task call made me look at the task system. balhhh 21:05 < aglitke> namespace vdsm {} <-- API: done. 21:05 < tdfkaSaggi> aglitke: We have the networking and VM APIs. 21:05 < tdfkaSaggi> guest agent 21:05 < aglitke> and storageconnectionRefs 21:05 < tdfkaSaggi> and I'm not saying never. I'm just saying add them in 7.1 or 7.2 21:05 < tdfkaSaggi> yes 21:06 < aglitke> How can I ask vdsm to create me a disk image for my vm without using the storage apis? 21:06 <@danken> sorry guys - I've just lost you. 21:06 < tdfkaSaggi> Just not to go on a tangent, the problem with exposing volumes is that it makes the caller responsible with keeping track of the chain\tip. 21:06 < tdfkaSaggi> which is problematic in a clustered multi managed case 21:07 < aglitke> Does engine do that today via the xmlrpc api? 21:07 < tdfkaSaggi> Yea, and this is very complex and doesn't really scale. 21:07 < tdfkaSaggi> For example 21:07 <@danken> tdfkaSaggi: volume is just one point, I think that problem of chains is image's 21:08 < tdfkaSaggi> if you happen to create a sanpshot without the engine knowing. 21:08 < tdfkaSaggi> You broken the image 21:08 < tdfkaSaggi> In the new scheme images are always the tip 21:08 < aglitke> IMO, it's okay if the V1 libvdsm has the same end-user caveats as the current API. 21:08 < aglitke> That's why we introduce better APIs in the future. 21:08 < aglitke> ie. the new image repository system. 21:08 < tdfkaSaggi> aglitke: My problem is keeping support 21:09 < tdfkaSaggi> this requires a huge chunk of code to be maintained longer then we like. 21:09 < aglitke> right, but I've been waiting since I first played with oVirt for this improved storage API :) 21:09 < aglitke> We are all bust. 21:09 < aglitke> busy 21:10 < aglitke> but we need something useful for oVirt 3.2 21:10 < tdfkaSaggi> aglitke: I have some stuff up. 21:10 < tdfkaSaggi> aglitke: And I do think that having clients use that is a big mistake for them 21:11 < aglitke> Also, we want engine to use the new libvdsm without requiring them to rewrite their whole storage management at once. 21:11 < tdfkaSaggi> The ovirt-engine barely manages to make it work. 21:11 < tdfkaSaggi> aglitke: I'm not saying I'll deprecated it the second the new stuff are in. 21:12 < tdfkaSaggi> I'm just saying I don't want the burden of new clients using it 21:12 < aglitke> so, how do I create a disk image for a VM without using the existing storage API? fork()/exec('qemu-img')/chown() ? 21:12 < tdfkaSaggi> Just as an example, delete volume trusts that the ovirt-engine only perform one SPM action at a time. 21:13 < tdfkaSaggi> How do you explain that corruption to a user 21:14 < aglitke> fair point, but what are supposed to do in the meantime? 21:14 < aglitke> libvdsm is DOA is there is no graceful migration path for engine. 21:15 < tdfkaSaggi> aglitke: Don't worry about the engine. 21:15 < tdfkaSaggi> They will mix it up for a while. 21:15 < tdfkaSaggi> And they can use unsupported APIs. 21:16 < aglitke> So who will care about libvdsm in the meantime? It's starting to sound like my rest api all over again :) 21:16 < tdfkaSaggi> I would have no problem giving the current storage APIs to anyone. As long as they promise not to complain about how bad they are and how they corrupted their data. 21:17 < aglitke> ok. I am going to try and expose them. Can you recommend a way for me to create a vm without those apis though? 21:17 -!- danken: has quit [Ping timeout: 264 seconds] 21:17 < tdfkaSaggi> You could just give runVM a direct path 21:17 < aglitke> how do I create the image file? 21:17 < tdfkaSaggi> to files 21:18 < tdfkaSaggi> qemu-img 21:18 < tdfkaSaggi> You can put it on NFS or on a LUN 21:18 < tdfkaSaggi> and connect to that. 21:18 < tdfkaSaggi> NFS is kind of problematic because you don't know where it's mounted 21:19 < aglitke> ok. That is very limiting. 21:19 < tdfkaSaggi> But we could solve that by giving an NFSDrive objects that does that like we do for direct lun. 21:19 < tdfkaSaggi> aglitke: of course you're not going to get something that is very good. 21:20 < tdfkaSaggi> I just think, considering the time frame, that is the best we can give and support. 21:21 < tdfkaSaggi> By the way, the ovirt-engine probably will come out after 7.0. So they could use something a bit more advanced. 21:21 < tdfkaSaggi> RHEV 4.0 21:21 < tdfkaSaggi> Or whatever 21:23 < aglitke> ok. I am going to try and post something we can commit to the tree soon. I want to be able to split up the work on the API to include more than just the two of us if possible, 21:23 < aglitke> tdfkaSaggi, btw, I got IntStr correction working on the client side. 21:24 < tdfkaSaggi> aglitke: If it all compiles, you can expose the storage APIs 21:24 < tdfkaSaggi> We can remove it later. 21:24 < aglitke> it compiles, but it is broken due to the ctor issues we talked about. 21:25 < tdfkaSaggi> aglitke: Yea, I still need to think about that. I all just doesn't click in my head yet. 21:25 < aglitke> eg, not having the spuuid with which to construct volume objects when calling StorageDomain.getVolumes() 21:25 < aglitke> I will take a stab at solving it somehow. 21:26 < tdfkaSaggi> Because some object ctors seem to make sense. Like volume and image. But these kind of objects seem to be better off implemented on top of libvdsm. 21:26 < aglitke> I might introduce 2 new types: ImageUUID and VolumeUUID which actually have all of the required uuid fields. 21:26 < aglitke> and alter the API to return all of the uuids when returning a list of volume uuids 21:26 < tdfkaSaggi> aglitke: Do whatever you can so we can push it in. We can fix everything in due time. It's all autogenerated anyways. 21:26 < aglitke> exactly. 21:27 < aglitke> It will be nice to have it in so we can start evolving the schema 21:27 < tdfkaSaggi> I need to play with things in order to get a better grip on whats right or wrong. 21:27 < tdfkaSaggi> Theory seldomly holds up on it's own. 21:29 < aglitke> indeed 21:43 -!- danken: has joined #vdsm 21:43 -!- mode/#vdsm: by ChanServ 21:58 -!- danken1: has joined #vdsm 21:59 -!- mode/#vdsm: by ChanServ 21:59 -!- danken: has quit [Ping timeout: 240 seconds] 22:50 -!- fsimonce: has quit [Quit: Coyote finally caught me] 23:16 -!- apahim: has quit [Quit: Leaving] 23:17 -!- aliguori: has quit [Remote host closed the connection] 23:36 -!- apuimedo: has joined #vdsm 23:36 -!- danken1: has quit [Quit: Leaving.] 23:42 -!- apuimedo: has quit [Ping timeout: 244 seconds] --- Log closed za aug 25 00:00:11 2012