Re: [Engine-devel] Bridgeless Networks api design
- Original Message - > From: "Itamar Heim" > To: "Yaniv Kaul" > Cc: engine-devel@ovirt.org > Sent: Sunday, March 18, 2012 2:31:45 PM > Subject: Re: [Engine-devel] Bridgeless Networks api design > > On 03/18/2012 11:27 AM, Yaniv Kaul wrote: > > On 03/18/2012 10:43 AM, Michael Pasternak wrote: > >> On 03/18/2012 10:21 AM, Itamar Heim wrote: > >>> On 03/18/2012 09:33 AM, Michael Pasternak wrote: > the question is Management/Migration/Storage/Display can be > non-bridged?, if so, > true|false makes sense. > >>> bridge is an implementation detail at host level, hence the > >>> discussion is about abstracting it from users. > >>> a VM network doesn't have to have bridge at host level, for > >>> networks > >>> using VMFex or SR-IOV > >> > >> Management|Migration|Storage|Display|VM > >> > >> > >> what do you say about having it as another /designation/ type? > >> > > > > Not sure I understand: Management can be bridge-less, Migration can > > be > > bridge-less, Storage can be bridge-less, Display can be > > bridge-less, VM > > is the only that perhaps today cannot be bridge-less, so I do think > > that > > 'true|false' makes some sense. However, I'd > > generalize it to 'attachment' as I believe we'll have other types > > in the > > future (Macvtap, SRIOV and friends), so something like > > bridge|sriov|macvtap|... > > Y. > > > > attachment would be at physical host level and could vary from host > to host. > this is about intended allowed usages of the logical network across > the > system we should probably have a set of, so called, "usages" and not a single one. It should give enough flexibility for future usages with an easy upgrade. something like: management,display,VM or: management display VM > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 11:27 AM, Yaniv Kaul wrote: On 03/18/2012 10:43 AM, Michael Pasternak wrote: On 03/18/2012 10:21 AM, Itamar Heim wrote: On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV Management|Migration|Storage|Display|VM what do you say about having it as another /designation/ type? Not sure I understand: Management can be bridge-less, Migration can be bridge-less, Storage can be bridge-less, Display can be bridge-less, VM is the only that perhaps today cannot be bridge-less, so I do think that 'true|false' makes some sense. However, I'd generalize it to 'attachment' as I believe we'll have other types in the future (Macvtap, SRIOV and friends), so something like bridge|sriov|macvtap|... Y. attachment would be at physical host level and could vary from host to host. this is about intended allowed usages of the logical network across the system ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Use java.util.Collection where possible?
- Original Message - > From: "Danny Rankevich" > To: "Asaf Shakarchi" > Cc: "engine-devel" > Sent: Thursday, March 15, 2012 7:52:47 PM > Subject: Re: [Engine-devel] Use java.util.Collection where possible? > > I ran deRPC with Collection in the parameters AND return type, and > everything works ok. > why should there be a problem? the concrete type is serialized in the > payload... Yes it works, but again, IIRC gwt compiler, while generating js has to take into account all possible variants of the Collection in the compilation unit, including all the classes impl Collection and Serializable interface in the class path. So that will cause the permutations to be much larger, it also affects compile time and the app size. > > - Original Message - > > From: "Asaf Shakarchi" > > To: "Danny Rankevich" > > Cc: "engine-devel" , "Yair Zaslavsky" > > > > Sent: Wednesday, March 14, 2012 1:19:18 PM > > Subject: Re: [Engine-devel] Use java.util.Collection where > > possible? > > > > Danny are you sure? > > IIRC GWT RPC Oracle wont be able to pick the right implementation > > and will generate code for any possible concrete impl, > > > > > > Asaf. > > - Original Message - > > > From: "Danny Rankevich" > > > To: "Yair Zaslavsky" > > > Cc: "engine-devel" > > > Sent: Wednesday, March 14, 2012 12:58:35 PM > > > Subject: Re: [Engine-devel] Use java.util.Collection where > > > possible? > > > > > > BWT I did some checks on the GWT RPC that we use (deRPC) and > > > there > > > shouldn't be any problems using Collection interface (or any > > > interface) in the generic api service. > > > > > > - Original Message - > > > > From: "Allon Mureinik" > > > > To: "Yair Zaslavsky" > > > > Cc: "engine-devel" > > > > Sent: Sunday, March 4, 2012 6:57:24 PM > > > > Subject: Re: [Engine-devel] Use java.util.Collection where > > > > possible? > > > > > > > > My two cents: > > > > > > > > There are two meanings of subtyping Collection (or any other > > > > interface, for that matter) - additional logic and specific > > > > implementation. > > > > I think wherever possible, we should use the interface that > > > > infers > > > > as > > > > much logic as possible (e.g., java.util.List for ordering, > > > > java.util.Set for uniquness, java.util.SortedSet for natural > > > > ordering, etc.), without inferring any specific implementation > > > > (e.g., ArrayList, HashSet, etc.). > > > > > > > > The flipside of this notion is that it's a mistake to use an > > > > overly > > > > specific class/interface - when your parameter type is > > > > ArrayList, > > > > you implicitly tell the user the *order* of his objects matter, > > > > and > > > > that it matters to your internal algorithm to be able to do > > > > get(i) > > > > as an O(1) operation. > > > > > > > > Bottom line, now that I'm done with CS 101: > > > > +1, but be careful not use interfaces that are too low. > > > > Most methods that now receive an ArrayList will still compile > > > > if > > > > you > > > > change the parameter type to Collection, but make sure that you > > > > don't implicitly assume some ordering, e.g. > > > > > > > > -Allon > > > > > > > > - Original Message - > > > > > From: "Yair Zaslavsky" > > > > > To: "engine-devel" > > > > > Sent: Thursday, March 1, 2012 5:18:03 PM > > > > > Subject: [Engine-devel] Use java.util.Collection where > > > > > possible? > > > > > > > > > > Hi, > > > > > I see that in some places in engine-core we use > > > > > Java.Util.List, > > > > > or > > > > > even > > > > > Java.Util.ArrayList as types of method arguments, while in > > > > > the > > > > > method > > > > > code we do nothing besides iterating over the collection. > > > > > I then found all kinds of usages like this: > > > > > > > > > > x.foo(new ArrayList(myMap.values())); > > > > > > > > > > As you can see need to instantiate a new ArrayList in order > > > > > to > > > > > use > > > > > the > > > > > values of the map in method foo. > > > > > Do you see any reason why not change the argument type (at > > > > > method > > > > > signature) to Collection in such places, where possible? > > > > > > > > > > Yair > > > > > > > > > > ___ > > > > > Engine-devel mailing list > > > > > Engine-devel@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > ___ > > > > Engine-devel mailing list > > > > Engine-devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > ___ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel ma
Re: [Engine-devel] Bridgeless Networks api design
- Original Message - > From: "Itamar Heim" > To: "Michael Pasternak" > Cc: engine-devel@ovirt.org > Sent: Sunday, March 18, 2012 10:39:48 AM > Subject: Re: [Engine-devel] Bridgeless Networks api design > > On 03/18/2012 10:43 AM, Michael Pasternak wrote: > > On 03/18/2012 10:21 AM, Itamar Heim wrote: > >> On 03/18/2012 09:33 AM, Michael Pasternak wrote: > >>> the question is Management/Migration/Storage/Display can be > >>> non-bridged?, if so, > >>> true|false makes sense. > >> > >> bridge is an implementation detail at host level, hence the > >> discussion is about abstracting it from users. > >> a VM network doesn't have to have bridge at host level, for > >> networks using VMFex or SR-IOV > > > > > >Management|Migration|Storage|Display|VM > > > > > > what do you say about having it as another /designation/ type? > > > > it==VM? > the above looks ok to me. > (I really hope for a better element name than designation though) Consider using "purpose" instead of "designation". > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - > From: "Omer Frenkel" > To: "Oved Ourfalli" > Cc: engine-devel@ovirt.org > Sent: Sunday, March 18, 2012 11:27:33 AM > Subject: Re: [Engine-devel] Disk Permissions Feature > > > > - Original Message - > > From: "Oved Ourfalli" > > To: "Itamar Heim" > > Cc: engine-devel@ovirt.org, "Omer Frenkel" > > Sent: Sunday, March 18, 2012 11:09:54 AM > > Subject: Re: [Engine-devel] Disk Permissions Feature > > > > > > > > - Original Message - > > > From: "Itamar Heim" > > > To: "Omer Frenkel" > > > Cc: engine-devel@ovirt.org > > > Sent: Thursday, March 15, 2012 5:46:07 PM > > > Subject: Re: [Engine-devel] Disk Permissions Feature > > > > > > On 03/15/2012 05:34 PM, Omer Frenkel wrote: > > > >>> > > 1. "Create disk - requires permissions on the Storage > > > >>> > > Domain, > > > >>> > > (can't > > > >>> > > assume Quota is sufficient to permit user creating the > > > >>> > > disk > > > >>> > > on the > > > >>> > > Storage Domain, as Quota might be disabled)" > > > >>> > > > > > >>> > > I'd also specify create disk for regular disks is at > > > >>> > > storage domain > > > >>> > > level?, while direct lun disks require system level > > > >>> > > permission of > > > >>> > > add disk. > > > >>> > > > > > >>> > > so, if quota is disabled, how important is it to > > > >>> > > prevent > > > >>> > > creation > > > >>> > > of > > > >>> > > disks (other than direct lun ones, which would require > > > >>> > > a > > > >>> > > permission > > > >>> > > similar to storage domain creation)? > > > >>> > > > > > >>> > > if this is added, it has to be implicitly added / not > > > >>> > > needed if > > > >>> > > user has > > > >>> > > quota (i.e., having a quota should be similar to having > > > >>> > > a > > > >>> > > permission as > > > >>> > > far as the check goes). > > > >>> > > > > > >> > > > > >> > We should look into it, how complicate is it to validate if > > > >> > user has > > > >> > either quota or permission, and allow creating a disk on a > > > >> > SD > > > >> > if > > > >> > either > > > >> > exists. > > > > this might be confusing to the user as he can disable the > > > > quota, > > > > then stuff would stop working. > > > > > > > > > > we can't require both quota and permissions from user on storage > > > domains > > > - that's cumbersome. > > > question is if we can limit the need for permissions to disks > > > only > > > to > > > places where they are needed (shared, direct, floating)? > > +1 on that. > > I also think it is only relevant on attaching a disk to a VM, as > > the > > other use-cases are simpler: > > 1. Attach disk to VM - would require having permissions on the disk > > (whether it is shared, direct lun or floating) > > 2. Add disk to VM - would only require quota (if enforced). > > 3. Create disk (i.e., floating/shared disk) - would only require > > quota (if enforced). > > and if not enforced? anyone can create as much disks as he like? > we thought of requiring permissions if quota is disabled, > but i think its confusing to the user as he plays with You are right. Need to think this through... Also, we need to get a better understanding on the use-cases for floating/shared disk... who is supposed to create them, and who to attach... > > > > > ___ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 10:43 AM, Michael Pasternak wrote: On 03/18/2012 10:21 AM, Itamar Heim wrote: On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV Management|Migration|Storage|Display|VM what do you say about having it as another /designation/ type? Not sure I understand: Management can be bridge-less, Migration can be bridge-less, Storage can be bridge-less, Display can be bridge-less, VM is the only that perhaps today cannot be bridge-less, so I do think that 'true|false' makes some sense. However, I'd generalize it to 'attachment' as I believe we'll have other types in the future (Macvtap, SRIOV and friends), so something like bridge|sriov|macvtap|... Y. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - > From: "Oved Ourfalli" > To: "Itamar Heim" > Cc: engine-devel@ovirt.org, "Omer Frenkel" > Sent: Sunday, March 18, 2012 11:09:54 AM > Subject: Re: [Engine-devel] Disk Permissions Feature > > > > - Original Message - > > From: "Itamar Heim" > > To: "Omer Frenkel" > > Cc: engine-devel@ovirt.org > > Sent: Thursday, March 15, 2012 5:46:07 PM > > Subject: Re: [Engine-devel] Disk Permissions Feature > > > > On 03/15/2012 05:34 PM, Omer Frenkel wrote: > > >>> > > 1. "Create disk - requires permissions on the Storage > > >>> > > Domain, > > >>> > > (can't > > >>> > > assume Quota is sufficient to permit user creating the > > >>> > > disk > > >>> > > on the > > >>> > > Storage Domain, as Quota might be disabled)" > > >>> > > > > >>> > > I'd also specify create disk for regular disks is at > > >>> > > storage domain > > >>> > > level?, while direct lun disks require system level > > >>> > > permission of > > >>> > > add disk. > > >>> > > > > >>> > > so, if quota is disabled, how important is it to prevent > > >>> > > creation > > >>> > > of > > >>> > > disks (other than direct lun ones, which would require a > > >>> > > permission > > >>> > > similar to storage domain creation)? > > >>> > > > > >>> > > if this is added, it has to be implicitly added / not > > >>> > > needed if > > >>> > > user has > > >>> > > quota (i.e., having a quota should be similar to having a > > >>> > > permission as > > >>> > > far as the check goes). > > >>> > > > > >> > > > >> > We should look into it, how complicate is it to validate if > > >> > user has > > >> > either quota or permission, and allow creating a disk on a SD > > >> > if > > >> > either > > >> > exists. > > > this might be confusing to the user as he can disable the quota, > > > then stuff would stop working. > > > > > > > we can't require both quota and permissions from user on storage > > domains > > - that's cumbersome. > > question is if we can limit the need for permissions to disks only > > to > > places where they are needed (shared, direct, floating)? > +1 on that. > I also think it is only relevant on attaching a disk to a VM, as the > other use-cases are simpler: > 1. Attach disk to VM - would require having permissions on the disk > (whether it is shared, direct lun or floating) > 2. Add disk to VM - would only require quota (if enforced). > 3. Create disk (i.e., floating/shared disk) - would only require > quota (if enforced). and if not enforced? anyone can create as much disks as he like? we thought of requiring permissions if quota is disabled, but i think its confusing to the user as he plays with > > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 10:43 AM, Michael Pasternak wrote: On 03/18/2012 10:21 AM, Itamar Heim wrote: On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV Management|Migration|Storage|Display|VM what do you say about having it as another /designation/ type? it==VM? the above looks ok to me. (I really hope for a better element name than designation though) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - > From: "Itamar Heim" > To: "Omer Frenkel" > Cc: engine-devel@ovirt.org > Sent: Thursday, March 15, 2012 5:46:07 PM > Subject: Re: [Engine-devel] Disk Permissions Feature > > On 03/15/2012 05:34 PM, Omer Frenkel wrote: > >>> > > 1. "Create disk - requires permissions on the Storage > >>> > > Domain, > >>> > > (can't > >>> > > assume Quota is sufficient to permit user creating the disk > >>> > > on the > >>> > > Storage Domain, as Quota might be disabled)" > >>> > > > >>> > > I'd also specify create disk for regular disks is at > >>> > > storage domain > >>> > > level?, while direct lun disks require system level > >>> > > permission of > >>> > > add disk. > >>> > > > >>> > > so, if quota is disabled, how important is it to prevent > >>> > > creation > >>> > > of > >>> > > disks (other than direct lun ones, which would require a > >>> > > permission > >>> > > similar to storage domain creation)? > >>> > > > >>> > > if this is added, it has to be implicitly added / not > >>> > > needed if > >>> > > user has > >>> > > quota (i.e., having a quota should be similar to having a > >>> > > permission as > >>> > > far as the check goes). > >>> > > > >> > > >> > We should look into it, how complicate is it to validate if > >> > user has > >> > either quota or permission, and allow creating a disk on a SD > >> > if > >> > either > >> > exists. > > this might be confusing to the user as he can disable the quota, > > then stuff would stop working. > > > > we can't require both quota and permissions from user on storage > domains > - that's cumbersome. > question is if we can limit the need for permissions to disks only to > places where they are needed (shared, direct, floating)? +1 on that. I also think it is only relevant on attaching a disk to a VM, as the other use-cases are simpler: 1. Attach disk to VM - would require having permissions on the disk (whether it is shared, direct lun or floating) 2. Add disk to VM - would only require quota (if enforced). 3. Create disk (i.e., floating/shared disk) - would only require quota (if enforced). > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-shell problem on F16 and nightly builds
this is known issue, new rpms/tarballs will be available in release repo today, also you can get them from http://lists.ovirt.org/pipermail/users/2012-March/001176.html thanks. -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 10:39 AM, Itamar Heim wrote: > On 03/18/2012 10:43 AM, Michael Pasternak wrote: >> On 03/18/2012 10:21 AM, Itamar Heim wrote: >>> On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. >>> >>> bridge is an implementation detail at host level, hence the discussion is >>> about abstracting it from users. >>> a VM network doesn't have to have bridge at host level, for networks using >>> VMFex or SR-IOV >> >> >>Management|Migration|Storage|Display|VM >> >> >> what do you say about having it as another /designation/ type? >> > > it==VM? > the above looks ok to me. > (I really hope for a better element name than designation though) I'd avoid using /type/ as type usually applies on single variant, /assignment/ maybe? nothing batter comes to my mind -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 10:21 AM, Itamar Heim wrote: > On 03/18/2012 09:33 AM, Michael Pasternak wrote: >> the question is Management/Migration/Storage/Display can be non-bridged?, if >> so, >> true|false makes sense. > > bridge is an implementation detail at host level, hence the discussion is > about abstracting it from users. > a VM network doesn't have to have bridge at host level, for networks using > VMFex or SR-IOV Management|Migration|Storage|Display|VM what do you say about having it as another /designation/ type? -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 09:33 AM, Michael Pasternak wrote: the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Bridgeless Networks api design
On 03/15/2012 03:58 PM, Itamar Heim wrote: > On 03/15/2012 12:53 PM, Michael Pasternak wrote: >> >> Hi, >> >> First of all i would like to understand the exact meaning of the vm_network, >> from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise >> bridgeless", >> >> if so, why not calling network propertytrue|false? > > bridge vs. bridgeless is an implementation detail. some network models could > run without a bridge as well for VMs (though not currently supported). > so the optimization is to not use a bridge for networks that can't run VMs, > but the reverse logic does not apply. > >> >> from the other hand i understand that this is only current implementation >> and it >> may change in a future, >> >> anyway addingtrue|false property to >> entity in api >> (as was suggested) doesn't sound good cause vm_network sounds as a network >> type, but then >> the question is Management/Migration/Storage/Display should be also >> network's types? and if single >> network can be used for the Management|Migration|Storage|Display >> simultaneously? if the answer is >> yes, network modelling probably should look like: >> >> >>true|false >>Management/Migration/Storage/Display >> >> >> or >> >> >>true|false >>Management|Migration|Storage|Display >> > > that bridged should be replaced with something saying VM_Network (better name > needed). the question is Management/Migration/Storage/Display can be non-bridged?, if so, true|false makes sense. > btw, I wonder if a private network (only for one vm) is also a type, or just > a private case of a vm network. true by itself doesn't provide much info and to complete the picture will require true VM having only VM also not enough cause it may sound that this network will be used only for vms and not a single vm. > > and that type/designation can have more than one of course. > (and that migration/storage networks are still not supported). i know, looking forward to take in account all future features. > >> >> your thoughts? >> >> [1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
